AKS のクラスター構成について

Microsoft Azure
スポンサーリンク

AKS クラスターのアーキテクチャ

AKS クラスターは次のように Azure が管理するコントロール プレーンと、ユーザー側のリソースとして管理される部分に分かれます。実際に Pod などを配置する AKS ノードとして利用されるコンピューティング リソースは、複数の VM インスタンスで構成されます。

コントロール プレーン

AKS のコントロール プレーンには次のようなものが含まれます。一般的に Kubernetes のマスター ノードで稼働するようなコンポーネントですが、これらは Microsoft Azure のデータセンター内で自動的に冗長化やバックアップを管理してくれます。

  • kube-apiserver
  • kube-scheduler
  • etcd
  • kube-controller-manager

これらのコントロール プレーンには直接アクセスすることはできないので、Azure CLI や ARM API などを経由して AKS リソースをアップデートするといった管理方法となります。

AKS ノード

こちらはユーザーのサブスクリプション上に VM や VMSS リソースとして作成されます。これら AKS ノードは AKS クラスター作成時に自動で作成されるマネージドな仮想ネットワークか、事前に作成しておいたユーザー管理の仮想ネットワークに配置できます。

ノード プールについて

ノード プールは複数の AKS ノードをまとめたグループです。ノード プール内のインスタンスは VM サイズや利用するイメージなどが全て統一されています。ノード プールは用途によって 2 つの種類があります

  • システム ノード プール
  • ユーザー ノード プール

ノードプールの種類

システム ノード プール

システム ノード プールは AKS のシステム Pod (CoreDNS や CSI ドライバーなど) が稼働するノードとなります。内部的にはラベルとして kubernetes.azure.com/mode: system が付与されており、システム Pod はこのラベルを持つノードで優先的実行されるように設定されています。

システム ノード プールは次のような制限があります。

  • OS は Linux である必要がある
  • AKS クラスター内で最低でも 1 つ以上のシステム ノード プールを含める必要がある
  • システム ノード プールには最低でも 1 台以上のノードを含める必要がある

上述の内容から、AKS クラスターには最低でもシステム ノードが 1 台以上存在している必要があります。必ずしも常時稼働している必要がありませんが、電源を停止しても 1 台以上のノードは残しておかなければいけません。

また、リソース キャパシティの設計としては次の推奨事項を意識する必要があります。

  • VM サイズは、少なくとも 2 つの vCPU と 4 GB のメモリのがある SKU を利用する (B シリーズ以外)
  • 本番環境でのシステム ノード プールは 3 台以上のノードを利用する

ユーザー ノード プール

対してユーザー ノード プールには上述のような明確な制限はありません。OS としても Linux と Windows の 2 つから選択できます。システム ノード プールであってもユーザーのアプリケーション Pod を動かすことはできますが、システム Pod が稼働する環境に余計な影響を与えないために分離しておくのが理想です。

ユーザー ノード プールはノード数を 0 台とすることもできるため、オートスケーリングなどで利用していない時のリソースに対する課金を削減できます。

システム ノード プールとユーザー ノード プールの切り替え

ユーザー ノード プールからシステム ノード プールへの切り替えは自由に行えます。

逆にシステム ノード プールからユーザー ノード プールへの切り替えは、システム ノード プールの制限事項があるため、他に利用できるシステム ノード プールが 1 つ以上ある場合にのみ行えます。

Azure Kubernetes Service (AKS) でシステム ノード プールを使用する – 既存のクラスターのシステムおよびユーザー ノード プールを更新する

AKS ノードの OS とコンテナー ランタイム

AKS ノードでは、前述のようにノード プールの種類によって利用できる OS が異なります。そして、OS の種類と利用する Kubernetes バージョンによってコンテナー ランタイムの種類が変わります。

OS 種類Kubernetes バージョンコンテナー ランタイム (CRI)
Linux1.18 までDocker
Linux1.19 以降containerd
Windows全てDocker
Windows1.20 以降contaierd (プレビュー)

AKS クラスターのバージョンとサポート

AKS では、クラスター単位もしくはノード プール単位で利用する Kubernetes のバージョンを指定できます。作成時だけでなく、アップグレードを行う際にもクラスター全体か、ノード プール単位かを選択して適用できます。

AKS ノードのイメージ バージョンは Microsoft が管理更新するものとなっているので、イメージの更新が必要な場合には自動で展開がされます。更新のスケジュールと内容は、AKS のリリース ノートから確認できます。

Releases · Azure/AKS (github.com)

AKS でサポートされるバージョンは、Kubernetes のアップストリームと同じように最新に近いものが規定されています。完全に Kubernetes のアップストリームと一致したタイミングではなく、AKS の開発に準じたものとなっているため、Kubernetes のマイナー バージョンなどは少し遅れている場合があります。

AKS でサポートされているのは、AKS で提供されている最新のマイナー バージョン N と、その 2 つ前にあたる N-2 までを含む 3 つのマイナー バージョンが対象となります。

また、各マイナー バージョンでそれぞれ 2 つのパッチ バージョンがサポート対象となっています。そのため、6 バージョンがサポート対象となっていると考えてもらって構いません。この他にプレビューとして最新の開発バージョンや、直近までサポートしていたバージョンもしばらくは利用できます。

Azure Kubernetes Service でサポートされている Kubernetes のバージョン – Azure Kubernetes Service | Microsoft Docs

なお、AKS で利用できるバージョンは、次のようなコマンドで確認できます。

az aks get-versions --location <Region> --output table

現時点では次のようになっていました。KubernetesVersion にプレビューを含めた利用可能なバージョンが表示されます。Upgrades は対象のバージョンからアップグレード可能なバージョンを示しています。

$ az aks get-versions --location japaneast --output table
KubernetesVersion    Upgrades
-------------------  -------------------------
1.23.3(preview)      None available
1.22.6               1.23.3(preview)
1.22.4               1.22.6, 1.23.3(preview)
1.21.9               1.22.4, 1.22.6
1.21.7               1.21.9, 1.22.4, 1.22.6
1.20.15              1.21.7, 1.21.9
1.20.13              1.20.15, 1.21.7, 1.21.9
1.19.13              1.20.13, 1.20.15
1.19.11              1.19.13, 1.20.13, 1.20.15

AKS クラスターのリソース構成

まずは AKS クラスターを作成してみます。

az group create -n rg-k8slab0221 -l japaneast
az aks create -g rg-k8slab0221 -n aks-k8slab0221 --generate-ssh-keys

AKS クラスターを作成すると、AKS クラスター リソースの他にもう 1 つ別のリソース グループが作成されます。既定では “MC_” から始まる名前となっており、このリソース グループの中には AKS クラスターを構成するリソースが自動的に作成されています。

$ az aks show -g rg-k8slab0221 -n aks-k8slab0221 --query nodeResourceGroup
"MC_rg-k8slab0221_aks-k8slab0221_japaneast"

このリソース グループには AKS クラスターのマネージド ID が割り当てられており、AKS クラスターからシステム的に操作できるように構成されます。

このため、ロード バランサーや VMSS リソースを変更したり、追加したりできるようになっています。もしも別途作成しておいたパブリック IP アドレスを利用するなど、AKS クラスターから操作する必要があるリソースを別途用意する場合には、このように AKS クラスターのマネージド ID を使って適切な権限を割り当てておく必要があります。

コメント

タイトルとURLをコピーしました