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

[アーティクル]
08/16/2024

従来の 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 と同等のポッド間の接続パフォーマンスが提供されます。ポッド内で実行されているワークロードでは、ネットワークアドレスの操作が行われているということさえ検知されません。

それぞれ 3 つのポッドを持つ 2 つのノードがオーバーレイネットワークで動作していることを示すダイアグラム。クラスター外エンドポイントへのポッドトラフィックは、NAT 経由でルーティングされます。

オンプレミスやピアリングされた 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) は使用できません。
オーバーレイクラスターに Application Gateway for Containers は使用できません。
仮想マシン可用性セット (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 \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --generate-ssh-keys

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

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 --resource-group $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

既存のクラスターを 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 以降。

制限事項

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

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 クラスターを作成する

[az group create][az-group-create] コマンドを使用して、クラスターの Azure リソースグループを作成します。
```
az group create --location <region> --name <resourceGroupName>
```

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

az aks create \
    --location <region> \
    --resource-group <resourceGroupName> \
    --name <clusterName> \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys

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

クラスターが作成されたら、ワークロードをデプロイできます。この記事では、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
YAML

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

デプロイが公開されて 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

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 マニフェストを使用して 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

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

Azure CNI Powered by Cilium を使用したデュアルスタックネットワーク - (プレビュー)

Azure CNI Powered by Cilium を使用して、デュアルスタック AKS クラスターをデプロイできます。これにより、Cilium ネットワークポリシーエンジンを使用して IPv6 トラフィックを制御することもできます。

重要

AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。プレビューは、"現状有姿" および "利用可能な限度" で提供され、サービスレベルアグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォートベースでカスタマーサポートによって部分的にカバーされます。そのため、これらの機能は、運用環境での使用を意図していません。詳細については、次のサポート記事を参照してください。

前提条件

最新バージョンの AKS プレビュー拡張機能が必要です。
Kubernetes バージョン 1.29 以上が必要です。

aksプレビューの Azure CLI 拡張機能をインストールする

az extension add コマンドを使用して aks-preview 拡張機能をインストールします。
```
az extension add --name aks-preview
```
az extension update コマンドを使って拡張機能の最新バージョンに更新します。
```
az extension update --name aks-preview
```

'AzureOverlayDualStackPreview' 機能フラグを登録する

az feature register コマンドを使用して、AzureOverlayDualStackPreview 機能フラグを登録します。
```
az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
```
状態が [登録済み] と表示されるまでに数分かかります。

次のように az feature show コマンドを使用して、登録状態を確認します。

az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"

状態が Registered と表示されたら、az provider register コマンドを使用して Microsoft.ContainerService リソースプロバイダーの登録を最新の情報に更新します。
```
az provider register --namespace Microsoft.ContainerService
```

Azure CNI Powered by Cilium を使用してオーバーレイクラスターを設定する

az aks create コマンドを使用し、Azure CNI オーバーレイを使用してクラスターを作成します。引数 --network-dataplane cilium を使用して Cilium データプレーンを指定することを忘れないでください。

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

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

Azure CNI Powered by Cilium の詳細については、「Azure CNI Powered by Cilium」を参照してください。

デュアルスタックネットワーク Windows ノードプール - (プレビュー)

Windows ノードプールを使用して、デュアルスタック AKS クラスターをデプロイできます。

重要

aksプレビューの Azure CLI 拡張機能をインストールする

az extension add コマンドを使用して aks-preview 拡張機能をインストールします。
```
az extension add --name aks-preview
```
az extension update コマンドを使って拡張機能の最新バージョンに更新します。
```
az extension update --name aks-preview
```

'AzureOverlayDualStackPreview' 機能フラグを登録する

az feature register コマンドを使用して、AzureOverlayDualStackPreview 機能フラグを登録します。
```
az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
```
状態が [登録済み] と表示されるまでに数分かかります。

次のように az feature show コマンドを使用して、登録状態を確認します。

az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"

状態が Registered と表示されたら、az provider register コマンドを使用して Microsoft.ContainerService リソースプロバイダーの登録を最新の情報に更新します。
```
az provider register --namespace Microsoft.ContainerService
```

オーバーレイクラスターを設定する

az aks create コマンドを使用し、Azure CNI オーバーレイを使用してクラスターを作成します。

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

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

Windows ノードプールをクラスターに追加する

[az aks nodepool add][az-aks-nodepool-add] コマンドを使用して、Windows ノードプールをクラスターに追加します。

az aks nodepool add \
    --resource-group $resourceGroup \
    --cluster-name $clusterName \
    --os-type Windows \
    --name winpool1 \
    --node-count 2

次のステップ

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

次の方法で共有

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

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

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

IP アドレス計画

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

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

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

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

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

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

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

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

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

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

前提条件

制限事項

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

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

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

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

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

Azure CNI Powered by Cilium を使用したデュアルスタックネットワーク - (プレビュー)

前提条件

aksプレビューの Azure CLI 拡張機能をインストールする

'AzureOverlayDualStackPreview' 機能フラグを登録する

Azure CNI Powered by Cilium を使用してオーバーレイクラスターを設定する

デュアルスタックネットワーク Windows ノードプール - (プレビュー)

aksプレビューの Azure CLI 拡張機能をインストールする

'AzureOverlayDualStackPreview' 機能フラグを登録する

オーバーレイクラスターを設定する

Windows ノードプールをクラスターに追加する

次のステップ

その他のリソース

次の方法で共有

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

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

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

IP アドレス計画

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

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

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

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

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

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

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

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

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

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

前提条件

制限事項

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

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

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

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

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

Azure CNI Powered by Cilium を使用したデュアルスタック ネットワーク - (プレビュー)

前提条件

aksプレビューの Azure CLI 拡張機能をインストールする

'AzureOverlayDualStackPreview' 機能フラグを登録する

Azure CNI Powered by Cilium を使用してオーバーレイ クラスターを設定する

デュアルスタック ネットワーク Windows ノードプール - (プレビュー)

aksプレビューの Azure CLI 拡張機能をインストールする

'AzureOverlayDualStackPreview' 機能フラグを登録する

オーバーレイ クラスターを設定する

Windows ノードプールをクラスターに追加する

次のステップ

その他のリソース

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

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

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

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

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

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

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

Azure CNI Powered by Cilium を使用したデュアルスタックネットワーク - (プレビュー)

Azure CNI Powered by Cilium を使用してオーバーレイクラスターを設定する

デュアルスタックネットワーク Windows ノードプール - (プレビュー)

オーバーレイクラスターを設定する