Azure Kubernetes Service (AKS) で Azure CNI オーバーレイ ネットワークを構成する

従来の Azure Container Networking Interface (CNI) では 、すべてのポッドに VNet IP アドレスが割り当てられます。 この IP アドレスは、すべてのノード上で事前に予約されている IP のセットまたはポッド用に予約された別のサブネットから割り当てられます。 このアプローチでは IP アドレスの計画が必要であり、アプリケーションの需要が増加するにつれて、クラスターのスケーリングを困難にするような、アドレスの枯渇につながる可能性があります。

Azure CNI オーバーレイを使用する場合、クラスター ノードは Azure Virtual Network (VNet) サブネットにデプロイされます。 ポッドには、ノードをホストしている VNet とは論理的に異なるプライベート CIDR から IP アドレスが割り当てられます。 クラスター内のポッドとノードのトラフィックは、オーバーレイ ネットワークを使用します。 ネットワーク アドレス変換 (NAT) では、ノードの IP アドレスを使用してクラスターの外部のリソースに到達します。 このソリューションにより、VNet IP アドレスが大幅に節約され、クラスターを大きなサイズにスケーリングできます。 さらに、プライベート CIDR を異なる AKS クラスターで再利用できるため、Azure Kubernetes Service (AKS) のコンテナー化されたアプリケーションで使用できる IP 空間が拡張されるというメリットもあります。

オーバーレイ ネットワークの概要

オーバーレイ ネットワークでは、Kubernetes クラスター ノードのみにサブネットから IP が割り当てられます。 ポッドは、クラスター作成時に提供されるプライベート CIDR から IP を受け取ります。 各ノードには、同じ CIDR から分割された /24 アドレス空間が割り当てられます。 クラスターのスケールアウト時に作成される追加のノードは、同じ CIDR から /24 アドレス空間を自動的に受け取ります。 Azure CNI は、この /24 空間からポッドに IP を割り当てます。

ポッドのプライベート CIDR 空間用の別のルーティング ドメインが Azure ネットワーク スタックに作成され、これによりポッド間の直接通信用オーバーレイ ネットワークが作成されます。 クラスター サブネットにカスタム ルートをプロビジョニングする必要も、カプセル化の方法を使ってポッド間でトラフィックをトンネリングする必要もなく、VNet 内の VM と同等のポッド間の接続パフォーマンスが提供されます。 ポッド内で実行されているワークロードでは、ネットワーク アドレスの操作が行われているということさえ検知されません。

オンプレミスやピアリングされた VNet など、クラスター外のエンドポイントとの通信は、NAT を介し、ノード IP を使用して行われます。 Azure CNI は、トラフィックのソース IP (ポッドのオーバーレイ IP) を VM のプライマリ IP アドレスに変換し、Azure ネットワーク スタックがトラフィックを宛先にルーティングできるようにします。 クラスター外のエンドポイントは、ポッドに直接接続できません。 ポッドのアプリケーションを Kubernetes Load Balancer サービスとして公開して、VNet でアクセスできるようにする必要があります。

オーバーレイ ポッドのインターネットへのアウトバウンド (エグレス) 接続は、Standard SKU Load Balancer またはマネージド NAT Gateway を使用して提供できます。 また、クラスター サブネット上のユーザー定義ルートを使用してファイアウォールに送信することで、エグレス トラフィックを制御することもできます。

クラスターへのイングレス接続は、Nginx や HTTP アプリケーション ルーティングなどのイングレス コントローラーを使用して実現できます。 Azure Application Gateway を使ったイングレス接続を構成することはできません。 詳細については、Azure CNI オーバーレイの制限事項に関するページを参照してください。

Kubenet と Azure CNI オーバーレイの違い

Azure CNI オーバーレイと同様に、Kubenet は VNet とは論理的に異なるアドレス空間からポッドに IP アドレスを割り当てますが、スケーリングなどの制限があります。 次の表は、Kubenet と Azure CNI オーバーレイの比較の詳細を示しています。 IP が不足しているために VNet IP アドレスをポッドに割り当てたくない場合は、Azure CNI オーバーレイを使用することをお勧めします。

領域	Azure CNI オーバーレイ	Kubenet
クラスターのスケール	5,000 ノードと 250 ポッド/ノード	400 ノードと 250 ポッド/ノード
ネットワーク構成	シンプル - ポッド ネットワークに対する追加の構成は不要	複雑 - ポッド ネットワークのクラスター サブネットにルート テーブルと UDR が必要
ポッド接続のパフォーマンス	VNet 内の VM と同等のパフォーマンス	ホップを追加すると、待機時間がわずかに増加
Kubernetes ネットワーク ポリシー	Azure ネットワーク ポリシー、Calico、Cilium	Calico
サポートされている OS プラットフォーム	Linux と Windows Server 2022、2019	Linux のみ

IP アドレス計画

• クラスター ノード: AKS クラスターを設定するときは、VNet サブネットに将来のスケーリングで拡張できる余裕が十分あることを確認します。 各ノード プールを専用サブネットに割り当てることができます。 最初の 3 つの IP アドレスは管理タスク用に予約されているため、/24 サブネットが適合できるのは最大 251 ノードです。
• ポッド: オーバーレイ ソリューションは、クラスター作成時に指定したプライベート CIDR から各ノードのポッドに /24 アドレス空間を割り当てます。 /24 サイズは固定で、増減はできません。 1 つのノードで最大 250 個のポッドを実行できます。 ポッドのアドレス空間を計画するときは、将来のクラスター拡張をサポートするために十分な大きさのプライベート CIDR を確保して、新しいノードに /24 アドレス空間を提供します。
  • ポッドの IP アドレス空間を計画する場合は、次の要因を考慮してください。
    • 同じポッド CIDR 空間は、同じ VNet 内の独立した複数の AKS クラスターで使用できます。
    • ポッド CIDR 空間は、クラスターのサブネット範囲と重複することはできません。
    • ポッド CIDR 領域は、直接接続されたネットワーク (VNet ピアリング、ExpressRoute、VPN など) と重複してはなりません。 外部トラフィックに podCIDR 範囲のソース IP がある場合、クラスターと通信するには、SNAT を介して重複しない IP に変換する必要があります。
• Kubernetes サービス アドレス範囲: サービス アドレス CIDR のサイズは、作成する予定のクラスター サービスの数によって異なります。 /12 より小さくする必要があります。 また、この範囲は、ピアリングされた VNet およびオンプレミス ネットワークで使用されるポッド CIDR 範囲、クラスター サブネット範囲、および IP 範囲と重複しないようにする必要があります。
• Kubernetes DNS サービスの IP アドレス: この IP アドレスは、クラスター サービス検出で使用される、Kubernetes サービスのアドレス範囲内に含まれます。 アドレス範囲の最初のIP アドレスは、 kubernetes.default.svc.cluster.local のアドレスとなるため、使用しないでください。

ネットワーク セキュリティ グループ

Azure CNI オーバーレイを使用したポッド間トラフィックがカプセル化されず、サブネット ネットワーク セキュリティ グループ ルールが適用されます。 サブネット NSG にポッド CIDR トラフィックに影響を与える拒否ルールが含まれている場合は、(すべての AKS エグレス要件に加えて) 適切なクラスター機能を確保するために、次のルールが定められていることを確認します。

• ノード CIDR からすべてのポートとプロトコルのノード CIDR へのトラフィック
• ノード CIDR からすべてのポートとプロトコルのポッド CIDR へのトラフィック (サービス トラフィック ルーティングに必要)
• ポッド CIDR からすべてのポートとプロトコルのポッド CIDR へのトラフィック (ポッド間、ポッドからサービスへのトラフィックに必要、DNS を含む)

ポッドからポッド CIDR ブロック外の任意の宛先へのトラフィックは、SNAT を利用して、ソース IP を、ポッドが実行されるノードの IP に設定します。

クラスター内のワークロード間のトラフィックを制限したい場合は、ネットワーク ポリシーを使用することをお勧めします。

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

ノードごとの最大ポッド数は、クラスター作成時または新しいノード プールの追加時に構成できます。 Azure CNI オーバーレイの既定値は 250 です。 Azure CNI オーバーレイで指定できる最大値は 250 で、最小値は 10 です。 ノード プールの作成時に構成されたノードごとの最大ポッド数は、そのノード プール内のノードにのみ適用されます。

使用するネットワーク モデルの選択

Azure CNI はポッド向けの IP アドレス指定オプションとして、ポッドに VNet IP を割り当てる従来の構成と、オーバーレイ ネットワーク の 2 つが用意されています。 AKS クラスターに使用するオプションは、柔軟性と高度な構成のニーズのバランスを考慮して選択します。 以下の考慮事項は、それぞれのネットワーク モデルが最も適切である可能性がある状況の概要を理解するのに役立ちます。

次の場合は、オーバーレイ ネットワークを使用します。

• 多数のポッドにスケーリングしたくても、VNet の IP アドレス空間は限られています。
• ポッドのほとんどの通信がクラスター内で行われる。
• 仮想ノードなどの高度な AKS 機能を使用する必要がない。

次の場合は、従来の VNet オプションを使用します。

• 使用可能な IP アドレス空間が十分にある。
• ポッドの通信のほとんどが、クラスターの外部にあるリソースに対するものである。
• クラスター外のリソースがポッドに直接接続する必要がある。
• 仮想ノードなどの高度な AKS 機能を使用する必要がある。

Azure CNI オーバーレイに関する制限事項

Azure CNI オーバーレイには次の制限事項があります。

• オーバーレイ クラスターに、イングレス コントローラーとしての Application Gateway (AGIC) は使用できません。
• 仮想マシン可用性セット (VMAS) はオーバーレイではサポートされていません
• ノード プールでDCsv2 シリーズの仮想マシンは使用できません。 コンフィデンシャル コンピューティングの要件を満たすには、代わりに DCasv5 または DCadsv5 シリーズの機密 VM の使用をご検討ください。
• 独自のサブネットを使用してクラスターをデプロイする場合、サブネット、VNET、VNET を含むリソース グループの名前は 63 文字以下にする必要があります。 これは、これらの名前が AKS ワーカー ノードでラベルとして使用されるため、Kubernetes ラベル構文規則適用の対象となるという理由によるものです。

オーバーレイ クラスターの設定

注意

--network-plugin-mode 引数を使用するには、CLI バージョン 2.48.0 以降が必要です。 Windows の場合、最新の aks-preview Azure CLI 拡張機能がインストールされている必要があります。以下の手順に従ってください。

az aks create コマンドを使用し、Azure CNI オーバーレイを使用してクラスターを作成します。 必ず引数 --network-plugin-mode を使用して、これがオーバーレイ クラスターであることを指定してください。 ポッド CIDR が指定されていない場合、AKS は既定の空間 viz. 10.244.0.0/16 を割り当てます。

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create -n $clusterName -g $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16

新しいノードプールを専用サブネットに追加する

Azure CNI オーバーレイを使用してクラスターを作成したら、別のノードプールを作成し、同じ VNet の新しいサブネットにノードを割り当てることができます。 この方法は、同じ VNET またはピアリングされた VNet 内のターゲットに対するホストのイングレス IP またはエグレス IP を制御する場合に役立ちます。

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add  -g $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

既存のクラスターを CNI オーバーレイにアップグレードする

注意

クラスターが次の条件を満たしていれば、既存の Azure CNI クラスターをオーバーレイに更新できます。

• クラスターが Kubernetes バージョン 1.22 以降にある。
• 動的ポッド IP 割り当て機能を使用していない。
• ネットワーク ポリシーが有効になっていない。 ネットワーク ポリシー エンジンは、アップグレード前にアンインストールできます。Azure Network Policy Manager または Calico のアンインストールに関するページを参照してください
• コンテナー ランタイムとして Docker を利用する Windows ノード プールを使用していない。

Note

ルーティング ドメインは ARM でまだサポートされていないため、CNI オーバーレイは ARM ベース (ARM64) のプロセッサ ノードではまだサポートされていません。

Note

既存のクラスターを CNI オーバーレイにアップグレードすることは、元に戻せないプロセスです。

警告

Windows OS ビルド 20348.1668 より前は、Windows オーバーレイ ポッドに関する制限事項 (ホスト ネットワーク ポッドからのパケットが誤って SNAT される) が原因で、オーバーレイにアップグレードするクラスターに追加の悪影響が生じていました。 この問題を回避するには、20348.1668 以上の Windows OS ビルドを使用します。

警告

カスタム azure-ip-masq-agent 構成を使用して、ポッドのパケットに SNAT を使用しないようにする追加の IP 範囲を含める場合、Azure CNI オーバーレイにアップグレードすると、これらの範囲への接続が切断される可能性があります。 オーバーレイ空間のポッド IP には、クラスター ノードの外部からは到達できません。 さらに、かなり古いクラスターでは、前のバージョンの azure-ip-masq-agent の ConfigMap が残っている可能性があります。 azure-ip-masq-agent-config という名前のこの ConfigMap が存在し、意図的に配置されているのではない場合は、update コマンドを実行する前に削除する必要があります。 カスタム ip-masq-agent 構成を使用しない場合は、Azure ip-masq-agent ConfigMaps に関して azure-ip-masq-agent-config-reconciled ConfigMap のみが存在する必要があり、これはアップグレード プロセス中に自動的に更新されます。

アップグレード プロセスにより、各ノード プールが同時に再イメージ化されます。 各ノード プールをオーバーレイに個別にアップグレードすることはサポートされていません。 クラスター ネットワークの中断は、ノード プール内の各ノードが再イメージ化される、ノード イメージのアップグレードまたは Kubernetes バージョンのアップグレードと似た形になります。

Azure CNI クラスターのアップグレード

az aks update コマンドを使用して、Overlay を使用するように既存の Azure CNI クラスターを更新します。

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

ポッドは既存のノード サブネットと重複しない新しいオーバーレイ空間から IP を取得する必要があるため、レガシ CNI からアップグレードする場合は、--pod-cidr パラメーターが必要です。 ポッド CIDR は、ノード プールの VNet アドレスと重複することはできません。 たとえば、VNet アドレスが 10.0.0.0/8 で、ノードがサブネット 10.240.0.0/16 にある場合、--pod-cidr は 10.0.0.0/8 またはクラスター上の既存のサービス CIDR と重複できません。

Kubenet クラスターのアップグレード

az aks update コマンドを使用して、Azure CNI オーバーレイを使用するように既存の Kubenet クラスターを更新します。

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay 

クラスターではポッドに VNet IP 空間と重複しないプライベート CIDR が既に使用されているため、--pod-cidr パラメーターを指定する必要はなく、ポッド CIDR は同じままです。

Note

Kubenet から CNI オーバーレイにアップグレードする場合、ポッドのルーティングにルート テーブルは不要になります。 クラスターで顧客が提供したルート テーブルを使用している場合、ポッド トラフィックを適切なノードに誘導するために使用されていたルートは、移行操作中に自動的に削除されます。 クラスターでマネージド ルート テーブル (ルート テーブルが AKS によって作成され、ノード リソース グループに存在する) を使用している場合、そのルート テーブルは移行の一部として削除されます。

デュアルスタック ネットワーク

オーバーレイ ネットワークとデュアルスタック Azure 仮想ネットワークを使用する場合、AKS クラスターをデュアルスタック モードでデプロイできます。 この構成では、ノードで、Azure 仮想ネットワーク サブネットから IPv4 と IPv6 の両方のアドレスを受け取ります。 ポッドでは、ノードの Azure 仮想ネットワーク サブネットとは論理的に異なるアドレス空間から IPv4 と IPv6 の両方のアドレスを受け取ります。 その後、ポッドで Azure 仮想ネットワークのリソースに到達できるように、ネットワーク アドレス変換 (NAT) が構成されます。 トラフィックの送信元 IP アドレスは、同じファミリのノードのプライマリ IP アドレス (IPv4 から IPv4 および IPv6 から IPv6) に NAT 処理されます。

前提条件

• Azure CLI 2.48.0 以降がインストールされている必要があります。
• Kubernetes バージョン 1.26.3 以降。

制限事項

デュアルスタック ネットワークでは、次の機能はサポートされていません。

• Windows ノードプール
• Azure ネットワーク ポリシー
• Calico ネットワーク ポリシー
• NAT Gateway
• 仮想ノード アドオン

デュアルスタック AKS クラスターをデプロイする

デュアルスタック クラスターをサポートするために、次の属性が提供されます。

• --ip-families: クラスターで有効にする IP ファミリのコンマ区切りリストを取得します。
  • ipv4 または ipv4,ipv6 のみがサポートされています。
• --pod-cidrs: ポッド IP を割り当てる CIDR 表記 IP 範囲のコンマ区切りリストを取得します。
  • このリスト内の範囲の数と順序は、--ip-families に指定されている値と一致する必要があります。
  • 値が指定されていない場合は、既定値の 10.244.0.0/16,fd12:3456:789a::/64 が使用されます。
• --service-cidrs: サービス IP を割り当てる CIDR 表記 IP 範囲のコンマ区切りリストを取得します。
  • このリスト内の範囲の数と順序は、--ip-families に指定されている値と一致する必要があります。
  • 値が指定されていない場合は、既定値の 10.0.0.0/16,fd12:3456:789a:1::/108 が使用されます。
  • --service-cidrs に割り当てられている IPv6 サブネットは、/108 を超えることはできません。

デュアルスタック AKS クラスターを作成する

1. [az group create][az-group-create] コマンドを使用して、クラスターの Azure リソース グループを作成します。

   az group create -l <region> -n <resourceGroupName>
   

2. --ip-families パラメーターが ipv4,ipv6 に設定された az aks create コマンドを使用して、デュアルスタック AKS クラスターを作成します。

   az aks create -l <region> -g <resourceGroupName> -n <clusterName> \
     --network-plugin azure \
     --network-plugin-mode overlay \
     --ip-families ipv4,ipv6
   

---

ワークロードの例を作成する

クラスターが作成されたら、ワークロードをデプロイできます。 この記事では、NGINX Web サーバーのワークロードのデプロイ例について説明します。

NGINX Web サーバーをデプロイする

アプリケーション ルーティング アドオンは、AKS クラスターでのイングレスに推奨される方法です。 アプリケーション ルーティング アドオンの詳細と、アドオンを使用してアプリケーションをデプロイする方法の例については、「アプリケーション ルーティング アドオンでのマネージド NGINX イングレス」を参照してください。

LoadBalancer 型のサービスを使用してワークロードを公開する

重要

現在、AKS の IPv6 サービスに関連する 2 つの制限があります。

• Azure Load Balancer により、リンクローカル アドレスから IPv6 宛先に正常性プローブが送信されます。 Azure Linux ノード プールでは、このトラフィックはポッドにルーティングできないため、externalTrafficPolicy: Cluster でデプロイされた IPv6 サービスに流れるトラフィックは失敗します。 IPv6 サービスは externalTrafficPolicy: Local でデプロイする必要があります。これにより、kube-proxy がノードのプローブに応答します。
• Kubernetes 1.27 より前のバージョンでは、サービスの最初の IP アドレスのみがロード バランサーにプロビジョニングされるため、デュアルスタック サービスでは、最初に一覧表示される IP ファミリのパブリック IP のみを受け取ります。 単一のデプロイにデュアルスタック サービスを提供するために、同じセレクターをターゲットとする 2 つのサービス (1 つは IPv4 用、もう 1 つは IPv6 用) を作成してください。 Kubernetes 1.27 以降では、この制限はなくなりました。

kubectl

1. kubectl expose deployment nginx コマンドを使用して、NGINX デプロイを公開します。

   kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
   kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'
   

   サービスが公開されたことを示す出力が表示されます。

   service/nginx-ipv4 exposed
   service/nginx-ipv6 exposed
   

2. デプロイが公開されて LoadBalancer サービスが完全にプロビジョニングされたら、kubectl get services コマンドを使用してサービスの IP アドレスを取得します。

   kubectl get services
   

   NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
   nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
   nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s
   

3. IPv6 対応ホストからのコマンド ライン Web 要求を使用して機能を確認します。 Azure Cloud Shell は IPv6 に対応していません。

   SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   curl -s "http://[${SERVICE_IP}]" | head -n5
   

   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   <style>
   

YAML

1. 次の YAML マニフェストを使用して NGINX デプロイを公開します。

   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: nginx
     name: nginx-ipv4
   spec:
     externalTrafficPolicy: Cluster
     ports:
    - port: 80
       protocol: TCP
       targetPort: 80
     selector:
       app: nginx
     type: LoadBalancer
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: nginx
     name: nginx-ipv6
   spec:
     externalTrafficPolicy: Cluster
     ipFamilies:
    - IPv6
     ports:
    - port: 80
       protocol: TCP
       targetPort: 80
     selector:
       app: nginx
     type: LoadBalancer
   

2. デプロイが公開されて LoadBalancer サービスが完全にプロビジョニングされたら、kubectl get services コマンドを使用してサービスの IP アドレスを取得します。

   kubectl get services
   

   NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
   nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
   nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s
   

次のステップ

独自のコンテナー ネットワーク インターフェイス (CNI) プラグインで AKS を利用する方法については、「独自のコンテナー ネットワーク インターフェイス (CNI) プラグイン を利用する」を参照してください。