Azure Kubernetes サービス (AKS) で Azure CNI ネットワークを構成する

[アーティクル]
03/06/2023

既定では、AKS クラスターでは kubenet を使って、仮想ネットワークとサブネットが作成されます。 kubenet を使用すると、ノードでは仮想ネットワークサブネットから IP アドレスが取得されます。その後、ノードにネットワークアドレス変換 (NAT) が構成されて、ポッドはノードの IP の背後に "隠ぺいされた" IP アドレスを受け取ります。この方法では、ポッド用にネットワーク空間で予約する必要がある IP アドレスの数が減ります。

Azure Container Networking Interface (CNI) では、すべてのポッドにサブネットから IP アドレスが割り当てられ、すべてのポッドに直接アクセスできます。 AKS クラスターと同じ仮想ネットワーク内のシステムでは、ポッドの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。 AKS クラスター仮想ネットワークの外部にあるシステムでは、ノードの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。これらの IP アドレスは、ネットワーク空間全体で一意である必要があり、事前に計画する必要があります。各ノードには、サポートされるポッドの最大数に対する構成パラメーターがあります。ノードごとにそれと同じ数の IP アドレスが、そのノードに対して事前に予約されます。この方法では詳細な計画が必要であり、多くの場合、IP アドレスが不足するか、アプリケーション需要の拡大に伴い、より大きなサブネットでのクラスターの再構築が必要になります。

この記事では、Azure CNI ネットワークを使用して、AKS クラスター用の仮想ネットワークサブネットを作成して使用する方法を示します。ネットワークのオプションと考慮事項について詳しくは、Kubernetes および AKS のネットワークの概念に関する記事をご覧ください。

前提条件

AKS クラスターの仮想ネットワークでは、送信インターネット接続を許可する必要があります。
AKS クラスターでは、Kubernetes サービスのアドレス範囲、ポッドアドレス範囲、またはクラスターの仮想ネットワークアドレス範囲に 169.254.0.0/16、172.30.0.0/16、172.31.0.0/16、192.0.2.0/24 を使用することはできません。
AKS クラスターで使用されるクラスター ID には、少なくとも、ご利用の仮想ネットワーク内のサブネットに対するネットワーク共同作成者のアクセス許可が必要です。組み込みのネットワークの共同作成者ロールを使用する代わりに、カスタムロールを定義する場合は、次のアクセス許可が必要です。
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
- Microsoft.Authorization/roleAssignments/write
AKS ノードプールに割り当てられたサブネットを委任されたサブネットにすることはできません。
AKS では、そのサブネットにネットワークセキュリティグループ (NSG) 適用されることはなく、そのサブネットに関連付けられている NSG に変更が加えられることもありません。独自のサブネットを指定し、そのサブネットに関連付けられている NSG を追加する場合は、NSG のセキュリティ規則で、ノードの CIDR 範囲内のトラフィックが許可されていることを確認する必要があります。詳しくは、「ネットワークセキュリティグループ」を参照してください。

クラスターの IP アドレス指定を計画する

Azure CNI ネットワークを使用して構成されたクラスターには、追加の計画が必要です。仮想ネットワークとそのサブネットのサイズは、実行する予定のポッドの数とクラスターのノードの数に対応できる必要があります。

ポッドとクラスターのノードの IP アドレスは、仮想ネットワーク内の指定されたサブネットから割り当てられます。各ノードは、プライマリ IP アドレスで構成されます。既定では、ノードでスケジュールされたポッドに割り当てられている Azure CNI によって 30 の追加の IP アドレスが事前に構成されています。クラスターをスケールアウトすると、サブネットの IP アドレスを使用して各ノードが同様に構成されます。ノードごとの最大ポッド数も表示できます。

重要

必要な IP アドレス数では、アップグレードとスケーリング操作も考慮する必要があります。固定数のノードのみをサポートするように IP アドレスを範囲設定した場合、ご使用のクラスターをアップグレードしたり、スケーリングしたりすることはできません。

ご使用の AKS クラスターをアップグレードする場合、新しいノードはそのクラスターにデプロイされます。サービスやワークロードは新しいノードで実行され、古いノードはクラスターから削除されます。このローリングアップグレードの手順では、IP アドレスが最低で追加で 1 ブロック利用可能になっている必要があります。その場合、ノードのカウントは n + 1 になります。
- この考慮事項は、Windows Server ノードプールを使用する場合に特に重要です。 AKS の Windows Server ノードでは、Windows の更新プログラムを自動的に適用するのではなく、ノードプール上でアップグレードを実行します。このアップグレードでは、最新の Window Server 2019 ベースノードイメージとセキュリティパッチを使用して新しいノードをデプロイします。 Windows Server ノードプールのアップグレードの詳細については、AKS でのノードプールのアップグレードに関するページを参照してください。
AKS クラスターをスケーリングする場合、新しいノードはそのクラスターにデプロイされます。サービスとワークロードは新しいノードで実行開始されます。クラスターでサポートするノードやポッド数をどのようにスケーリングするかを考慮して、使用する IP アドレスの範囲を考慮する必要があります。アップグレード操作用に、ノードを追加で 1 つ含める必要もあります。その場合、ノードのカウントは n + number-of-additional-scaled-nodes-you-anticipate + 1 になります。

ノードで最大数のポッドを実行し、定期的にポッドを破棄およびデプロイする場合、ノードごとに追加の IP アドレスをいくつか用意することも考慮する必要もあります。新しいサービスをデプロイし、アドレスを取得する場合、サービスを削除して IP アドレスを解放するために数秒かかります。これらの追加の IP アドレスでは、それらが考慮されています。

AKS クラスターの IP アドレス計画は、仮想ネットワーク、ノードとポッドの 1 つ以上のサブネット、および Kubernetes サービスのアドレス範囲で構成されます。

アドレス範囲/Azure リソース	制限とサイズ変更
仮想ネットワーク	Azure の仮想ネットワークは、/8 と同じサイズが可能ですが、構成される IP アドレスの個数は 65,536 に制限されています。アドレス空間を構成する前に、他の仮想ネットワーク内のサービスとの通信を含め、ネットワークのすべてのニーズを考慮に入れてください。たとえば、大きすぎるアドレス空間を構成すると、ネットワーク内の他のアドレス空間と重複する問題が発生する可能性があります。
Subnet	クラスターにプロビジョニングされている可能性のあるノード、ポッド、すべての Kubernetes、および Azure のリソースを収容するのに十分な大きさである必要があります。たとえば、内部に Azure Load Balancer をデプロイする場合は、そのフロントエンド IP は、パブリック IP ではなく、クラスターサブネットから割り当てられています。サブネットのサイズでは、アップグレード操作や将来のスケーリングのニーズも考慮する必要があります。アップグレード操作のための追加のノードを含む、"最小" サブネットサイズを計算するには: `(number of nodes + 1) + ((number of nodes + 1) * maximum pods per node that you configure)` 50 ノードのクラスターの例: `(51) + (51 * 30 (default)) = 1,581` (/21 以上) 追加の 10 ノードをスケールアップするためのプロビジョニングも含む 50 ノードのクラスターの例: `(61) + (61 * 30 (default)) = 1,891` (/21 以上) クラスターを作成するときにノードごとの最大ポッド数を指定しないと、ノードごとの最大ポッド数は 30 に設定されます。必要な最小 IP アドレス数はその値に基づきます。別の最大値に基づいて最小 IP アドレス要件を計算する場合、how to configure the maximum number of pods per node (ノードごとの最大ポッド数の構成方法) を参照して、クラスターをデプロイするときにこの値を設定します。
Kubernetes サービスのアドレス範囲	この範囲は、この仮想ネットワーク上にある、またはそれに接続されているネットワーク要素で使用しないでください。サービスのアドレスの CIDR は、/12 より小さくする必要があります。この範囲は、さまざまな AKS クラスター間で再利用できます。
Kubernetes DNS サービスの IP アドレス	クラスターサービス検索で使用される、Kubernetes サービスのアドレス範囲内の IP アドレス。アドレス範囲内の最初の IP アドレスは使用しないでください。サブネット範囲の最初のアドレスは、kubernetes.default.svc.cluster.local アドレスに使用されます。
Docker ブリッジアドレス	Docker ブリッジのネットワークアドレスは、すべての Docker インストールに存在する既定の docker0 ブリッジのネットワークアドレスを表します。 docker0 ブリッジが AKS クラスターやポッド自体で使用されることはありませんが、AKS クラスター内での docker build などのシナリオを引き続きサポートするには、このアドレスを設定する必要があります。 Docker ブリッジのネットワークアドレスの CIDR を選択する必要があります。そうしないと、他の CIDR と競合するおそれのあるサブネットが Docker によって自動的に選択されます。選択するアドレス空間がネットワーク上の残りの CIDR と競合してはなりません。これには、クラスターのサービス CIDR とポッド CIDR が含まれます。既定値は 172.17.0.1/16 です。この範囲は、さまざまな AKS クラスター間で再利用できます。

ノードごとの最大ポッド数

AKS クラスターのノードごとの最大ポッド数は 250 です。ノードごとの "既定" の最大ポッド数は、kubenet ネットワークと Azure CNI ネットワークで、またクラスターのデプロイ方法によって異なります。

デプロイ方法	kubenet の既定値	Azure CNI の既定値	デプロイ時に構成可能
Azure CLI	110	30	はい (最大 250)
Resource Manager テンプレート	110	30	はい (最大 250)
ポータル	110	110 ([ノードプール] タブで構成可能)	はい (最大 250)

最大値の構成 - 新しいクラスター

ノードごとの最大ポッド数を構成できるのは、クラスターのデプロイ時、または新しいノードプールを追加するときです。ノードあたりの最大ポッド数の値は 250 まで設定できます。

新しいノードプールを作成するときに maxPods を指定しない場合は、Azure CNI の既定値 30 を受け取ります。

ノードあたりの最大ポッドの最小値は、クラスターの正常性にとって重要なシステムポッド用の領域を保証するために適用されます。ノードごとの最大ポッドに対して設定できる最小値は、各ノードプールの構成に最低 30 個のポッド用の領域がある場合に限り、10 です。たとえば、ノードあたりの最大ポッドを 10 以上に設定するには、個々のノードプールに少なくとも 3 つのノードが必要です。この要件は、新しく作成された各ノードプールにも適用されます。したがって、ノードあたりの最大ポッドとして 10 が定義されている場合は、追加された以降の各ノードプールには少なくとも 3 つのノードが必要です。

ネットワーク	最小値	最大値
Azure CNI	10	250
Kubenet	10	250

Note

上記の表の最小値は、AKS サービスによって厳密に強制されます。示されている最小値より小さい maxPods 値を設定することはできません。そうすると、クラスターが起動できなくなることがあります。

Azure CLI:az aks create コマンドを使用して、クラスターをデプロイするときに --max-pods 引数を指定します。最大値は 250 です。
Resource Manager テンプレート:Resource Manager テンプレートを使用してクラスターをデプロイするときに、ManagedClusterAgentPoolProfile オブジェクトに maxPods プロパティを指定します。最大値は 250 です。
Azure portal: クラスターの作成時または新しいノードプールの追加時に、ノードプールの設定の Max pods per node フィールドを変更します。

最大値の構成 - 既存のクラスター

新しいノードプールを作成するときに、ノードごとの maxPod 設定を定義することができます。既存のクラスターでノードごとの maxPod の設定値を増やす必要がある場合は、新しく必要な maxPod カウントで新しいノードプールを追加します。ポッドを新しいプールに移行した後、古いプールを削除します。クラスター内の使用していないプールを削除するには、システムノードプールのドキュメントの定義に従ってノードプールモードを設定していることをご確認ください。

展開のパラメーター

AKS クラスターを作成するときに、Azure CNI ネットワーク用に以下のパラメーターを構成できます。

仮想ネットワーク:Kubernetes クラスターをデプロイする仮想ネットワーク。クラスターに新しい仮想ネットワークを作成する場合は、 [新規作成] を選択し、 [仮想ネットワークの作成] セクションの手順に従います。既存の仮想ネットワークを選択する場合は、その場所と Azure サブスクリプションが Kubernetes クラスターと同じであることを確認します。 Azure 仮想ネットワークの制限とクォータについては、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。

サブネット:クラスターをデプロイする仮想ネットワーク内のサブネット。クラスターの仮想ネットワークに新しいサブネットを作成する場合は、 [新規作成] を選択し、 [サブネットの作成] セクションの手順に従います。ハイブリッド接続する場合、ご使用の環境のその他の仮想ネットワークのアドレス範囲と重複しないようにする必要があります。

Azure ネットワークプラグイン: Azure ネットワークプラグインが使用されている場合、"externalTrafficPolicy=Local" が指定されている内部 LoadBalancer サービスには、AKS クラスターに属さない clusterCIDR の IP を持つ VM からアクセスすることはできません。

Kubernetes サービスのアドレス範囲: このパラメーターは、Kubernetes によってクラスターの内部サービスに割り当てられる仮想 IP のセットです。クラスターの作成後は、この範囲を更新することはできません。次の要件を満たす任意のプライベートアドレス範囲を使用できます。

クラスターの仮想ネットワークの IP アドレス範囲に含まれていてはなりません
クラスターの仮想ネットワークがピアリングする他の仮想ネットワークと重複していてはなりません
オンプレミスのどの IP アドレスとも重複していてはなりません
169.254.0.0/16、172.30.0.0/16、172.31.0.0/16、または 192.0.2.0/24 の範囲内にあってはなりません

技術的には、クラスターと同じ仮想ネットワーク内のサービスアドレス範囲を指定できますが、お勧めはしません。重複する IP アドレス範囲を使うと、予期しない動作になる可能性があります。詳細については、この記事の FAQ のセクションを参照してください。 Kubernetes サービスについて詳しくは、Kubernetes ドキュメントの「Services」(サービス) をご覧ください。

[Kubernetes DNS service IP address](Kubernetes DNS サービスの IP アドレス): クラスターの DNS サービスの IP アドレス。 [Kubernetes service address range](Kubernetes サービスアドレスの範囲) 内に含まれるアドレスを指定する必要があります。アドレス範囲内の最初の IP アドレスは使用しないでください。サブネット範囲の最初のアドレスは、kubernetes.default.svc.cluster.local アドレスに使用されます。

Docker ブリッジのアドレス:Docker ブリッジのネットワークアドレスは、すべての Docker インストールに存在する既定の docker0 ブリッジのネットワークアドレスを表します。 docker0 ブリッジが AKS クラスターやポッド自体で使用されることはありませんが、AKS クラスター内での docker build などのシナリオを引き続きサポートするには、このアドレスを設定する必要があります。 Docker ブリッジのネットワークアドレスの CIDR を選択する必要があります。そうしないと、他の CIDR と競合するおそれのあるサブネットが Docker によって自動的に選択されます。選択するアドレス空間がネットワーク上の残りの CIDR と競合してはなりません。これには、クラスターのサービス CIDR とポッド CIDR が含まれます。

ネットワークを構成する - CLI

Azure CLI を使って AKS クラスターを作成するときも、Azure CNI ネットワークを構成できます。 Azure CNI ネットワークを有効にして新しい AKS クラスターを作成するには、次のコマンドを使います。

最初に、AKS クラスターを参加させる既存のサブネットのサブネットリソース ID を取得します。

$ az network vnet subnet list \
    --resource-group myVnet \
    --vnet-name myVnet \
    --query "[0].id" --output tsv

/subscriptions/<guid>/resourceGroups/myVnet/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/default

az aks create コマンドに --network-plugin azure 引数を指定して実行し、高度なネットワークでクラスターを作成します。前の手順で収集したサブネット ID で、--vnet-subnet-id の値を更新します。

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --network-plugin azure \
    --vnet-subnet-id <subnet-id> \
    --docker-bridge-address 172.17.0.1/16 \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --generate-ssh-keys

ネットワークを構成する - ポータル

Azure Portal の次のスクリーンショットは、AKS クラスターの作成時にこれらの設定を構成する場合の例を示しています。

AKS クラスターの作成時にこれらの設定を構成する場合の例を示す Azure portal のスクリーンショット

IP サブネットの使用状況を監視する

Azure CNI には、IP サブネットの使用状況を監視する機能が用意されています。 IP サブネットの使用状況の監視を有効にするには、次の手順に従います。

YAML ファイルを取得する

GitHub から container-azm-ms-agentconfig.yaml という名前のファイルをダウンロードまたは grep します。
統合で azure_subnet_ip_usage を見つけます。 enabled を true に設定します。
ファイルを保存します。

AKS の資格情報の取得

サブスクリプション、リソースグループ、クラスターの変数を設定します。次の例を考えてみます。


    $s="subscriptionId"

    $rg="resourceGroup"

    $c="ClusterName"

    az account set -s $s

    az aks get-credentials -n $c -g $rg

構成を適用する

ダウンロードした container-azm-ms-agentconfig.yaml ファイルが保存されているフォルダーでターミナルを開きます。
まず、コマンド kubectl apply -f container-azm-ms-agentconfig.yaml を使用して構成を適用します。
これによりポッドが再起動され、5 分から 10 分後にメトリックが表示されます。
クラスターのメトリックを表示するには、Azure portal のクラスターページで [ブック] に移動し、"サブネット IP の使用状況" という名前のブックを見つけます。ビューは次のようになります。

Azure portal のブックブレードの図が表示され、AKS クラスターのサブネット IP 使用状況のメトリックが表示されています。

よく寄せられる質問

クラスターサブネットに VM を展開できますか。

はい。
Azure CNI 対応ポッドで発生したトラフィックに対して、外部システムではどのソース IP が認識されますか。

AKS クラスターと同じ仮想ネットワーク内のシステムでは、ポッドの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。 AKS クラスター仮想ネットワークの外部にあるシステムでは、ノードの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。
ポッドごとのネットワークポリシーを構成できますか。

はい、Kubernetes ネットワークポリシーは AKS で使用できます。開始するには、AKS でネットワークポリシーを使用してポッド間のトラフィックをセキュリティで保護する方法に関する記事を参照してください。
ノードに展開できるポッドの最大数は構成できますか。

はい。Azure CLI または Resource Manager テンプレートを使用してクラスターをデプロイするときに構成することができます。「ノードごとの最大ポッド数」を参照してください。

既存のクラスターでノードごとのポッドの最大数を変更することはできません。
AKS クラスターの作成時に作成したサブネットの追加のプロパティを構成するにはどうすればよいですか。たとえば、サービスエンドポイントなどのプロパティです。

AKS クラスターの作成中時に作成する仮想ネットワークとサブネットのプロパティの詳細な一覧は、Azure portal の標準の仮想ネットワーク構成ページで構成できます。
"Kubernetes サービスのアドレス範囲" のクラスター仮想ネットワーク内で別のサブネットを使用できますか。

お勧めはしませんが、この構成は可能です。サービスのアドレス範囲は、Kubernetes によってクラスターの内部サービスに割り当てられる仮想 IP (VIP) のセットです。 Azure のネットワークには、Kubernetes クラスターのサービスの IP 範囲の可視性がありません。クラスターのサービスアドレス範囲には可視性がないため、後でクラスターの仮想ネットワークにサービスのアドレス範囲と重複する新しいサブネットが作成される可能性があります。このような重複が発生した場合、Kubernetes は、サブネット内の他のリソースによって既に使用されている IP をサービスに割り当てる可能性があり、予期しない動作やエラーの原因となります。クラスターの仮想ネットワークの外部のアドレス範囲を使用することで、この重複のリスクを回避できます。

次のステップ

IP の動的割り当てと拡張サブネットのサポートを備えた Azure CNI ネットワークを構成するには、「AKS での IP の動的割り当てと拡張サブネットのサポートのための Azure CNI ネットワークの構成」を参照してください。

AKS のネットワークの詳細については、次の記事を参照してください。