次の方法で共有


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

それぞれ 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

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

オーバーレイ ネットワークとデュアルスタック 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 クラスターを作成する

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

    az group create --location <region> --name <resourceGroupName>
    
  2. --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 以降では、この制限はなくなりました。
  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>
    

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' 機能フラグを登録する

  1. az feature register コマンドを使用して、AzureOverlayDualStackPreview 機能フラグを登録します。

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

    状態が [登録済み] と表示されるまでに数分かかります。

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

    az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
    
  3. 状態が 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 のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 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' 機能フラグを登録する

  1. az feature register コマンドを使用して、AzureOverlayDualStackPreview 機能フラグを登録します。

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

    状態が [登録済み] と表示されるまでに数分かかります。

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

    az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
    
  3. 状態が 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

次のステップ

既存のクラスターを Azure CNI オーバーレイにアップグレードする方法については、「Azure Kubernetes Service (AKS) IPAM モードとデータプレーン テクノロジーのアップグレード」を参照してください。

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