本記事について

Azureインフラエンジニアの視点でAKSを学ぶ

私は普段AzureのIaaSやネットワークを主に扱っているのですが、AKSに手を出すにあたり困惑することが多くありました。
この記事ではAKSのインフラ（主にネットワーク）を構築しながら確認した内容を記録しておきます。

以下の3点について整理していきます。本記事は1の内容にフォーカスしています。

AKSとAzureリソース
AKSのネットワーク構成
インフラ観点のトラブルシューティング用Tips

AKSとAzureリソース

Azure環境の設計をする際にはサブスクリプションが決まった後、まずはリソースグループの構成を定義して、
それぞれのリソースグループにどのようなリソースを構築するかを決めていきます。
例えば仮想マシンを実行するシステムを設計する際にはネットワーク等の共通インフラリソースを管理するリソースグループと
仮想マシンリソースを管理するリソースグループを分けるかもしれません。
また、仮想マシンも複数のサブシステムに分かれる場合はサブシステムごとにリソースグループを分けることもあるでしょう。

加えて、仮想マシンを構築すると仮想マシンリソースだけではなく、ネットワークインターフェースや、
OSディスク、データディスク、場合によってはパブリックIPアドレスや拡張機能といったリソースも作成されます。
また、前提として仮想マシンを利用するにはVNetがあることが前提となっています。
設計の段階でリソースを把握しておくことでランニングコストの算出など全体像を理解できます。

AKSにおいても同様に事前に構築されるリソースについて把握しておきたいというのがこの記事のモチベーションです。
特にAKSでは仮想マシン等に比べると複雑なリソース構造になりますので、しっかり把握してAKSを構築できるようにしておきたいと思います。
AKSの基本的な構成や一般的なシナリオで想定されるリソース構成を確認していきます。

AKSの基本アーキテクチャとAKSリソースの管理

基本アーキテクチャ

まず、Azureに限定せずKubernetesそのものの基本的なアーキテクチャを見ると、大きくコントロールプレーンとノードから構成されています。
コントロールプレーンではAPIサーバなどのクラスター自体を管理する複数のコンポーネントが実行され、
ノードではユーザーのアプリケーションが実行されるという構造です。
Kubernete | Kubernetesのコンポーネント

AKSではどうなるかというと、コントロールプレーンがAzureによるマネージドで提供され、ユーザーは原則としてノードのみを管理するという構造になります。
ネイティブなKubernetesに比べてコントロールプレーンを管理しなくてよいのがパブリッククラウドでKubernetesを扱う大きなメリットの1つではないでしょうか。
MS Learn | AKSの中心概念

また、最近ではAKS Automaticというノード部分についてもAzureによる推奨構成で事前に設定されたAKSのモードもプレビューで出てきています。
ノードのスケーリング管理や監視、セキュリティなどが推奨構成で展開できるというものですが、本記事では触れません。

AKSリソースの基本

AKSリソースではAKSクラスターそのものを示すリソースに加えてノードリソースグループと呼ばれる
AKSにより管理されるマネージドのリソースグループが作成されます。
名前の通りノードを実行するために必要なAzureリソースが作成されるリソースグループになります。

デフォルトではという以下の名前で自動的に作成され、AKSクラスターリソースのプロパティ画面から確認できます。

MC_"AKSのリソースグループ名"_"AKSクラスター名"_"リージョン名"

また、このリソースグループやリソースに対してユーザーが直接変更を加えることはサポートされず、
AKS（Kubernetes）に対する操作により間接的に変更を加えます。
なお、AKSクラスターリソースを削除することで自動的にこのリソースグループも削除されます。

では実際にAKSを構築して作成されるリソースを見ていきましょう。

AKSリソース

Azureポータルからデプロイした基本構成

まずはAzureポータルから最小構成をデプロイした際に構築されるAzureリソースを確認してみます。

構築手順

Azureポータルで構築する際の設定をタブごとに確認して設定していきます。

作成されたリソース

以上の設定で構築をおこなうと、AKSクラスター以外にノードリソースグループが作成され、ノードリソースグループには以下のリソースが作成されました。

上から順に作成されたリソースを見ていきます。

仮想マシンスケールセット
AKSクラスターを作成する際に指定したシステムノードプール（必須）に対応する仮想マシンスケールセットです。
なお、ユーザーノードプールも追加で作成すると別で仮想マシンスケールセットが作成されます。
NSG
ノードプールの仮想マシンスケールセットがデプロイされている仮想ネットワークのサブネットに紐づけられています。
既定の状態ではNSGはデフォルトルールのみが登録されています。
マネージドID
ノードプールに対応したマネージドIDです。
AKSではクラスターリソースでもシステムマネージドIDを有効化することができますが、こちらはノードプール用のものです。
使い分けは以下のドキュメントに解説がありますが、Azure Container Repository（ACR）からイメージをプルする際の認証に使用するものです。
MS Learn | AKSで使用されるマネージドIDの概要
仮想ネットワーク
ノードプールがデプロイされている仮想ネットワークです。
デフォルトではアドレス空間は"10.224.0.0/12"が割り当てられ、"aks-subnet"が"10.224.0.0/16"で作成されています。
パブリックIPアドレス
ロードバランサーに紐づけられたパブリックIPアドレスです。
ノードプールがAzure外部にアクセスする際のIPアドレスになります。
ロードバランサー
外部ロードバランサー（Standard SKU）が作成されます。
これは送信規則を利用してノードプールが外部へアクセスするために利用されるとともに、
KubernetesのLoadBalancerサービスを構築した際にも利用されます。
※LoadBalancerサービスの詳細は別記事で触れます。

ノードプールの追加

ついでに構築した環境にユーザーノードプールを作成するとどうなるかも確認しておきましょう。
ノードリソースグループを見ると仮想マシンスケールセットが追加されていることがわかります。

BYO VNetを利用したパブリッククラスター

ネットワーク環境は既存の環境があり、それを利用したいというケースはよくあると思います。
ということで次は既存VNetにAKSクラスターをデプロイした場合のAzureリソースを確認してみます。
と言っても単に既存VNet内にデプロイするだけではAzureリソースはVNetが不要になるのみです。
ここでは既存VNetにインターネットアクセスのためのAzure FirewallやNVA、NATゲートウェイなどが展開されていることを想定して、
既存VNetのNATゲートウェイを利用したインターネットアクセスの構成（外部ロードバランサーなし）を試してみます。

構築手順

先ほどの手順で見た通り外部ロードバランサーをAzureポータルからのデプロイでは外すことができません。
そのためAzure CLIを利用してデプロイしていきます。
Azure CLIでデプロイする際に既設のNATゲートウェイを利用するようにオプションを設定します。

az aks create `
--name "aks-public-01" `
--resource-group "rg-aks-public-01" `
--enable-managed-identity `
--generate-ssh-keys `
--network-plugin azure `
--network-plugin-mode overlay `
--service-cidr "172.17.0.0/20" `
--dns-service-ip "172.17.0.10" `
--outbound-type userAssignedNATGateway `
--vnet-subnet-id "<サブネットのリソースID>" `
--node-count 1 `
--os-sku Ubuntu `
--node-vm-size Standard_D2pls_v6

作成されたリソース

Azureポータルからデプロイした時との差異として仮想ネットワークはもちろん、外部ロードバランサー（と外部ロードバランサーのPIP）がなくなっていることが確認できます。
インターネットアクセスにNATゲートウェイを利用するよう設定したことで外部ロードバランサーが作成されなくなりました。

ただし、ロードバランサーはクラスターへのインバウンド通信でも利用されます。
実際にKubernetesのLoadBalancerサービスをデプロイするとロードバランサーが作成されます。

kubectlコマンドでLoadBalancerサービスをデプロイした後のリソースグループ

BYO VNetを利用したプライベートクラスター

最後に、コントロールプレーンへのアクセスをプライベートネットワークに閉じたプライベートクラスター構成を試してみます。
こちらも既存のVNetを利用する前提で構築していきます。

構築手順

こちらもAzure CLIを利用してデプロイしていきます。
プライベートクラスターを有効化するオプションを指定しています。

az aks create `
--name "aks-private-01" `
--resource-group "rg-aks-private-01" `
--enable-managed-identity `
--enable-private-cluster `
--private-dns-zone system `
--disable-public-fqdn `
--generate-ssh-keys `
--network-plugin azure `
--network-plugin-mode overlay `
--service-cidr "172.17.0.0/20" `
--dns-service-ip "172.17.0.10" `
--outbound-type userAssignedNATGateway `
--vnet-subnet-id "<サブネットのリソースID>" `
--node-count 1 `
--os-sku Ubuntu `
--node-vm-size Standard_D2pls_v6

作成されたリソース

先ほどの例に比べて、コントロールプレーンのAPIサーバへのアクセスがプライベート化されたことで、APIサーバのプライベートエンドポイントと
ネットワークインターフェース、プライベートエンドポイントの名前解決のためのプライベートDNSゾーンが作成されていることがわかります。

まとめ

本記事ではAKSを構築した際に自動で作成されるノードリソースグループのリソースについて確認してきました。
既定のネットワーク構成ではインターネットアクセスに外部ロードバランサーが使用されることや、ノードプールごとに仮想マシンスケールセットが作成される様子などが確認できました。
また、BYO VNetのシナリオではユーザーが事前に用意した環境でAKSを実行したり、またプライベートクラスターのシナリオでは
一般的なAzureサービスと同様のプライベートエンドポイントの仕組みが使われていることが確認できました。
次回は今回構築したプライベートクラスターを中心にネットワーク構成を確認したいと思います。