次の方法で共有

Azure Container Networking Interface (CNI) ポッド サブネット

  • [アーティクル]

Azure CNI ポッド サブネットは、クラスター ノードとは別のサブネットからポッドに IP アドレスを割り当てます。 この機能は、動的 IP 割り当てと静的ブロック割り当て (プレビュー) の 2 つのモードで使用できます。

前提条件

Note

CIDR の静的ブロック割り当てを使う場合、Kubernetes Load Balancer サービスを使用してアプリケーションを Private Link サービスとして公開することはサポートされません。

  • AKS で基本的な Azure CNI ネットワークを構成するための前提条件を確認してください。同じ前提条件がこの記事にも適用されます。

  • AKS で基本的な Azure CNI ネットワークを構成するためのデプロイ パラメーターを確認してください。同じパラメーターが適用されます。

  • AKS Engine クラスターと DIY クラスターはサポートされていません。

  • Azure CLI のバージョン 2.37.0 以降と aks-preview 拡張機能のバージョン 2.0.0b2 以降。

  • サブスクリプションのサブスクリプションレベルの機能フラグ 'Microsoft.ContainerService/AzureVnetScalePreview' を登録します。

  • 既存のクラスターがある場合は、IP サブネットの使用状況を監視するためのコンテナー分析情報アドオンを有効にする必要があります。 次の例に示すように、az aks enable-addons コマンドを使ってコンテナーの分析情報を有効にできます。

    az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>

動的 IP 割り当てモード

動的 IP 割り当ては、AKS クラスターをホストするサブネットとは別のサブネットからポッド IP を割り当てることで、ポッドの IP アドレス枯渇の問題を軽減するのに役立ちます。

動的 IP 割り当てモードには、次の利点があります。

  • IP の使用効率の向上: IP は、ポッド サブネットからクラスター ポッドへと動的に割り当てられます。 これにより、すべてのノードで IP が静的に割り当てられる従来の CNI ソリューションと比べて、クラスター内での IP の使用効率が向上します。
  • スケーラブルで柔軟: ノードとポッドのサブネットを個別にスケーリングできます。 1 つのポッド サブネットを、クラスターの複数のノード プール間で共有することも、同じ VNet にデプロイされた複数の AKS クラスター間で共有することもできます。 ノード プール用に個別のポッド サブネットを構成することもできます。
  • ハイ パフォーマンス: ポッドには VNet IP が割り当てられるため、VNet 内の他のクラスター ポッドとリソースに直接接続できます。 このソリューションでは、パフォーマンスを低下させることなく、非常に大規模なクラスターをサポートできます。
  • ポッドに対する個別の VNet ポリシー: ポッドには個別のサブネットがあるので、ノード ポリシーとは異なる VNet ポリシーを構成できます。 このため、ノードではなくポッドに対してのみインターネット接続を許可したり、Azure NAT Gateway を使用してノード プール内のポッドのソース IP を修正したり、ネットワーク セキュリティ グループ (NSG) を使用してノード プール間のトラフィックをフィルター処理したりするなど、多くの便利なシナリオを実現できます。
  • Kubernetes ネットワーク ポリシー: Azure ネットワーク ポリシーと Calico は、どちらもこのモードで機能します。

IP アドレス指定を計画する

動的 IP 割り当てでは、ノードとポッドは独立してスケーリングされるため、アドレス空間を個別に計画できます。 ポッド サブネットはノード プールの粒度に合わせて構成できるため、ノード プールを追加するとき、常に新しいサブネットを追加できます。 クラスター/ノード プール内のシステム ポッドはポッド サブネットからも IP を受信するので、この動作については把握をしておく必要があります。

IP は、16 個のバッチ単位でノードに割り当てられます。 ポッド サブネットの IP 割り当ては、クラスター内のノードあたり少なくとも 16 個の IP で計画する必要があります。ノードは起動時に 16 個の IP を要求し、割り当てにおいて未割り当ての IP が 8 個未満になると常に、16 個の別のバッチを要求します。

Kubernetes サービスと Docker ブリッジについては、IP アドレスの計画に変更はありません。

静的ブロック割り当てモード (プレビュー)

静的ブロック割り当ては、個々の IP ではなく CIDR ブロックをノードに割り当てることで、ポッド サブネットのサイズ設定と Azure アドレス マッピングの制限を軽減するのに役立ちます。

静的ブロック割り当てモードには、次の利点があります。

  • 優れた IP スケーラビリティ: 従来の CNI による個々の IP の動的割り当てとは対照的に、CIDR ブロックはクラスター ノードに静的に割り当てられ、ノードの有効期間中は存在します。 これにより、CIDR ブロックに基づくルーティングが可能になり、従来のクラスターあたり 65,000 ポッドから最大 100 万ポッドにクラスターの制限をスケールアップすることができます。 Azure 仮想ネットワークは、クラスターの規模に対応できる十分な大きさにする必要があります。
  • 柔軟性: ノードとポッドのサブネットは個別にスケーリングできます。 1 つのポッド サブネットを、クラスターの複数のノード プール間で共有することも、同じ VNet にデプロイされた複数の AKS クラスター間で共有することもできます。 ノード プール用に個別のポッド サブネットを構成することもできます。
  • ハイ パフォーマンス: ポッドには仮想ネットワークの IP が割り当てられるため、VNet 内の他のクラスター ポッドとリソースに直接接続できます。
  • ポッドに対する個別の VNet ポリシー: ポッドには個別のサブネットがあるので、ノード ポリシーとは異なる VNet ポリシーを構成できます。 このため、ノードではなくポッドに対してのみインターネット接続を許可したり、Azure NAT Gateway を使用してノード プール内のポッドのソース IP を修正したり、NSG を使用してノード プール間のトラフィックをフィルター処理したりするなど、多くの便利なシナリオを実現できます。
  • Kubernetes ネットワーク ポリシー: Cilium、Azure NPM、Calico は、このソリューションと連携して動作します。

制限事項

Azure CNI 静的ブロック割り当てを使う場合の制限の一部を次に示します。

  • Kubernetes の必要最小バージョンは 1.28 です
  • サポートされる最大サブネット サイズは x.x.x.x/12 から 100 万 IP です
  • サブネットごとに 1 つの動作モードのみを使用できます。 サブネットで静的ブロック割り当てモードを使う場合、サブネットが同じである別のクラスターまたはノード プールで動的 IP 割り当てモードを使うことはできません。またその逆も同様です。
  • 新しいクラスター、またはサブネットが異なるノード プールを既存のクラスターに追加する場合にのみサポートされています。 既存のクラスターまたはノード プールの移行または更新はサポートされていません。
  • ノード プール内のノードに割り当てられたすべての CIDR ブロックで、ノードのプライマリ IP として 1 つの IP が選ばれます。 そのため、ネットワーク管理者が --max-pods 値を選ぶ場合は、最適な方法でニーズに応え、サブネット内の IP を最適な方法で使用できるように、次の計算を使ってみてください。

max_pods = (N * 16) - 1 (N は任意の正の整数であり、N> 0 です)

利用可能なリージョン

この機能は、次のリージョンでは使用できません。

  • 米国南部
  • 米国東部 2
  • 米国西部
  • 米国西部 2

IP アドレス指定を計画する

静的ブロック割り当てでは、ノードとポッドは独立してスケーリングされるため、アドレス空間を個別に計画できます。 ポッド サブネットはノード プールの粒度に合わせて構成できるため、ノード プールを追加するとき、常に新しいサブネットを追加できます。 クラスター/ノード プール内のシステム ポッドはポッド サブネットからも IP を受信するので、この動作については把握をしておく必要があります。

ノードあたりのポッドの最大数を定義するノード プールの --max-pods 構成に基づいて、/28 (16 IP) の CIDR ブロックがノードに割り当てられます。 各ノード上で、そのノード上で使用できるすべての IP のうち 1 つの IP が内部的な目的で予約されています。

IP を計画する際は、--max-pods次の計算を使用して構成を定義することが重要です: max_pods_per_node = (16 * N) - 1 (N は 0 より大きい任意の正の整数です)。

IP の無駄がない理想的な値にするには、最大ポッド値が上記の式に準拠している必要があります。

次のサンプル ケースを参照してください。

事例 max_pods ノードごとに割り当てられた CIDR ブロック ポッドで使用可能な IP の合計 ノードでの IP の無駄
無駄が少ない (許容可能) 30 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 30 = 1
理想的なケース 31 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 31 = 0
無駄が多い (お勧めしません) 32 3 (16 * 3) - 1 = 48 - 1 = 47 47 - 32 = 15

Kubernetes サービスについては、IP アドレスの計画に変更はありません。

Note

クラスターのスケールをサポートするのに十分な大きさの連続したアドレス空間を VNet に確保してください。