Azure Kubernetes Service (AKS) の独自の IP アドレス範囲で kubenet ネットワークを使用する

重要

2028 年 3 月 31 日に、Azure Kubernetes Service (AKS) の kubenet ネットワークは廃止されます。

サービスの中断を回避するには、AKS の kubenet で動作するワークロードがサポートされなくなるその日付より前に、Azure Container Networking Interface (CNI) オーバーレイにアップグレードする必要があります。

AKS クラスターでは、kubenet が使用され、既定で Azure 仮想ネットワークとサブネットが自動的に作成されます。 kubenet を使用すると、ノードで、Azure 仮想ネットワーク サブネットから IP アドレスが取得されます。 ポッドでは、ノードの Azure 仮想ネットワーク サブネットとは論理的に異なるアドレス空間から IP アドレスを受け取ります。 その後、ポッドで Azure 仮想ネットワークのリソースに到達できるように、ネットワーク アドレス変換 (NAT) が構成されます。 トラフィックの発信元 IP アドレスは、ノードのプライマリ IP アドレスに NAT 変換されます。 この方法により、ポッドで使用するためにネットワーク空間で予約する必要がある IP アドレスの数が大幅に減ります。

Azure Container Networking Interface (CNI) を使用すると、すべてのポッドで、サブネットから IP アドレスが取得され、直接アクセスできます。 これらの IP アドレスは、事前に計画し、ネットワーク空間全体で一意にする必要があります。 各ノードには、サポートされるポッドの最大数に関する構成パラメーターがあります。 次に、ノードごとにそれと同じ数の IP アドレスが、そのノードに対して事前に予約されます。 この方法では詳細な計画が求められ、多くの場合、IP アドレスが不足するか、アプリケーション需要の拡大に伴い、より大きなサブネットでクラスターの再構築が必要になります。 クラスターの作成時または新しいノード プールの作成時に、ノードにデプロイできる最大ポッド数を構成できます。 新しいノード プールの作成時に maxPods を指定しない場合は、kubenet の既定値 110 を受け取ります。

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

前提条件

• 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 には、少なくとも、ご利用の仮想ネットワーク内のサブネットに対するネットワーク共同作成者ロールが必要です。 CLI を使用すると、ロールの割り当てを自動的に設定できます。 ARM テンプレートまたは他のクライアントを使っている場合は、ロールの割り当てを手動で設定する必要があります。 また、クラスター ID を作成してアクセス許可を割り当てるには、サブスクリプション所有者などの適切なアクセス許可が必要です。 組み込みのネットワーク共同作成者ロールを使用する代わりにカスタム ロールを定義する場合は、次のアクセス許可が必要です。
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

警告

Windows Server ノード プールを使用するには、Azure CNI を使用する必要があります。 Windows Server コンテナーには、kubenet ネットワーク モデルは使用できません。

開始する前に

Azure CLI バージョン 2.0.65 以降がインストールされ、構成されている必要があります。 az --version を実行して、バージョンを確認します。 インストールまたはアップグレードが必要な場合は、Azure CLI のインストールに関するページを参照してください。

独自のサブネットを使用した kubenet ネットワークの概要

多くの環境で、割り当て済みの IP アドレス範囲を使用して仮想ネットワークとサブネットを定義しています。これらのリソースを使用して複数のサービスとアプリケーションをサポートします。 ネットワーク接続を提供するため、AKS クラスターで、kubenet (基本ネットワーク) または Azure CNI (高度なネットワーク) を使用できます。

kubenet では、ノードだけが仮想ネットワーク サブネットの IP アドレスを受け取ります。 ポッドが相互に直接通信することはできません。 代わりに、複数のノードにまたがるポッド間の接続は、ユーザー定義ルーティング (UDR) と IP 転送で処理されます。 既定では、UDR と IP 転送の構成は AKS サービスによって作成および保守されますが、必要に応じてカスタム ルート管理用に独自のルート テーブルを用意することができます。 また、割り当てられた IP アドレスを受け取り、アプリケーションに対するトラフィックを負荷分散するサービスの背後に、ポッドをデプロイすることもできます。 次の図は、ポッドではなく AKS ノードが仮想ネットワーク サブネットの IP アドレスを受け取る方法を示しています。

Azure でサポートされる UDR のルート数は最大 400 なので、AKS クラスターに 400 個を超えるノードを作成することはできません。 AKS 仮想ノードや Azure ネットワーク ポリシーは、kubenet ではサポートされていません。 Calico ネットワーク ポリシーはサポートされています。

Azure CNI では、各ポッドが IP サブネット内の IP アドレスを受け取り、他のポッドやサービスと直接通信できます。 クラスターは、指定する IP アドレスの範囲まで拡大できます。 ただし、IP アドレスの範囲を事前に計画する必要があり、すべての IP アドレスが、ノードでサポートできるポッドの最大数に基づいて AKS ノードによって消費されます。 Azure CNI では、仮想ノードやネットワーク ポリシー (Azure または Calico) などの高度なネットワーク機能とシナリオがサポートされます。

kubenet に関する制限と考慮事項

• kubenet の設計には、追加のホップが必要になるため、ポッド通信の待機時間がわずかに増加します。
• kubenet を使用するには、ルート テーブルとユーザー定義ルートが必要なため、操作が複雑になります。
  • 詳細については、「AKS のユーザー定義ルーティング テーブルを使用してクラスター エグレスをカスタマイズする」と「AKS で送信の種類を使用してクラスター エグレスをカスタマイズする」を参照してください。
• kubenet の設計により、直接的なポッドのアドレス指定は kubenet ではサポートされていません。
• Azure CNI クラスターとは異なり、複数の kubenet クラスターで 1 つのサブネットを共有することはできません。
• AKS では Network Security Groups (NSG) がそのサブネットに適用されず、そのサブネットに関連付けられている NSG が変更されることもありません。 独自のサブネットを指定し、そのサブネットに関連付けられている NSG を追加する場合は、NSG のセキュリティ規則で、ノードとポッドの CIDR 間のトラフィックが許可されている必要があります。 詳しくは、「ネットワーク セキュリティ グループ」を参照してください。
• kubenet でサポートされていない機能には次のものが含まれます。
  • Azure ネットワーク ポリシー
  • Windows ノード プール
  • 仮想ノード アドオン

注

クラスター内の一部のシステム ポッド (konnectivity など) では、オーバーレイ アドレス空間からの IP ではなく、ホスト ノードの IP アドレスが使用されます。 システム ポッドでは、ノード IP のみが使用され、仮想ネットワークの IP アドレスは使用されません。

IP アドレスの使用可能性と不足

Azure CNI でよくある問題は、割り当てられている IP アドレス範囲が小さすぎて、クラスターをスケーリングまたはアップグレードするときにノードを追加できないことです。 ネットワーク チームが、予想されるアプリケーションの需要をサポートするのに十分な大きさの IP アドレス範囲を発行できないこともあります。

妥協案として、kubenet を使用する AKS クラスターを作成し、既存の仮想ネットワーク サブネットに接続することができます。 この方法では、ノードは定義済みの IP アドレスを受け取ることができ、クラスター内で実行される可能性のあるポッド用に多数の IP アドレスを事前に予約する必要がありません。 kubenet では、はるかに小さい IP アドレス範囲を使用し、大きなクラスターやアプリケーションの需要をサポートできます。 たとえば、お使いのサブネットの /27 の IP アドレス範囲で、20 から 25 ノードのクラスターを実行し、スケーリングやアップグレードのための十分な余裕を確保できます。 このクラスター サイズでは、最大で 2,200 ～ 2,750 個のポッドをサポートできます (既定では、ノードあたり最大 110 ポッド)。 AKS において kubenet で構成できるノードあたりの最大ポッド数は 250 です。

次の基本的な計算で、ネットワーク モデルの違いを比較します。

• kubenet: 単純な /24 IP アドレス範囲では、クラスター内で最大 251 個のノードをサポートできます。 各 Azure 仮想ネットワーク サブネットでは、最初の 3 つの IP アドレスが管理操作用に予約されます。 このノード数では、最大で 27,610 個のポッドをサポートできます (既定では、ノードあたり最大 110 ポッド)。
• Azure CNI: 同じ基本的な /24 サブネット範囲では、クラスター内で最大 8 ノードしかサポートできません。 既定ではノードあたり最大 30 ポッドなので、このノード数では最大で 240 個のポッドしかサポートできません。

注

これらの最大値では、アップグレードまたはスケーリング操作は考慮されていません。 実際には、サブネットの IP アドレス範囲でサポートされる最大数のノードを実行することはできません。 スケーリングまたはアップグレード操作に使用できるように、一部の IP アドレスを残しておく必要があります。

仮想ネットワーク ピアリングと ExpressRoute 接続

オンプレミスの接続を提供するため、kubenet および Azure CNI のどちらのネットワーク アプローチでも、Azure 仮想ネットワーク ピアリングまたは ExpressRoute 接続を使用できます。 重複および正しくないトラフィック ルーティングが発生しないように、慎重に IP アドレス範囲を計画する必要があります。 たとえば、多くのオンプレミス ネットワークでは、ExpressRoute 接続経由でアドバタイズされる 10.0.0.0/8 アドレス範囲が使用されます。 AKS クラスターをこのアドレス範囲外の Azure 仮想ネットワーク サブネット (172.16.0.0/16 など) に作成することをお勧めします。

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

以下の考慮事項は、それぞれのネットワーク モデルがどのような場合に最も適している可能性があるかについて概要を理解するのに役立ちます。

kubenet を使用する場合:

• IP アドレス空間が限られている。
• ポッドのほとんどの通信が、クラスター内で行われる。
• 仮想ノードや Azure ネットワーク ポリシーなどの高度な AKS 機能を使用する必要がない。

Azure CNI を使用する場合:

• 使用可能な IP アドレス空間が十分にある。
• ポッドのほとんどの通信が、クラスターの外部にあるリソースに対するものである。
• ポッド接続用にユーザー定義ルートを管理したくない。
• 仮想ノードや Azure ネットワーク ポリシーなどの高度な AKS 機能を使用する必要がある。

使用するネットワーク モデルの決定に役立つ詳細については、ネットワーク モデルとそのサポート範囲の比較に関するページを参照してください。

仮想ネットワークとサブネットを作成する

1. az group create コマンドを使用して、リソース グループを作成します。

   az group create --name myResourceGroup --location eastus
   

2. 使用できる既存の仮想ネットワークとサブネットがない場合は、az network vnet create コマンドを使用してこれらのネットワーク リソースを作成します。 次のコマンド例では、アドレス プレフィックスが 192.168.0.0/16 の myAKSVnet という名前の仮想ネットワークと、アドレス プレフィックスが 192.168.1.0/24 の myAKSSubnet という名前のサブネットを作成します。

   az network vnet create \
       --resource-group myResourceGroup \
       --name myAKSVnet \
       --address-prefixes 192.168.0.0/16 \
       --subnet-name myAKSSubnet \
       --subnet-prefix 192.168.1.0/24 \
       --location eastus
   

3. az network vnet subnet show コマンドを使用してサブネット リソース ID を取得し、後で使用するために SUBNET_ID という名前の変数として格納します。

   SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)
   

仮想ネットワークに AKS クラスターを作成する

システム割り当てマネージド ID を使用して AKS クラスターを作成する

注

システム割り当て ID を使用する場合は、Azure CLI で、クラスターの作成後にシステム割り当て ID にネットワーク共同作成者ロールが付与されます。 ARM テンプレートまたはその他のクライアントを使用している場合は、代わりにユーザー割り当てマネージド ID を使用する必要があります。

• az aks create コマンドを使用して、システム割り当てマネージド ID で AKS クラスターを作成します。

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --network-plugin kubenet \
      --service-cidr 10.0.0.0/16 \
      --dns-service-ip 10.0.0.10 \
      --pod-cidr 10.244.0.0/16 \
      --vnet-subnet-id $SUBNET_ID \
      --generate-ssh-keys 
  

  デプロイ パラメーター:

  • --service-cidr は省略可能です。 このアドレスは、AKS クラスター内の内部サービスに IP アドレスを割り当てるために使われます。 この IP アドレス範囲は、ネットワーク環境内の他の場所で使用されていないアドレス空間である必要があります。ExpressRoute またはサイト間 VPN 接続を使用して、お使いの Azure 仮想ネットワークを接続している場合、または接続する予定である場合は、すべてのオンプレミス ネットワーク範囲がこれに含まれます。 既定値は 10.0.0.0/16 です。
  • --dns-service-ip は省略可能です。 このアドレスは、サービス IP アドレス範囲の .10 アドレスである必要があります。 既定値は 10.0.0.10 です。
  • --pod-cidr は省略可能です。 このアドレスは、ネットワーク環境の他の場所で使われていない大きいアドレス空間である必要があります。 ExpressRoute またはサイト間 VPN 接続を使用して、お使いの Azure 仮想ネットワークを接続している場合、または接続する予定である場合は、すべてのオンプレミス ネットワーク範囲がこの範囲に含まれます。 既定値は 10.244.0.0/16 です。
    • このアドレス範囲は、スケールアップが予想されるノード数を収容できる十分な大きさである必要があります。 このアドレス範囲は、クラスターをデプロイした後は変更できません。
    • ポッドの IP アドレス範囲は、クラスター内の各ノードに /24 アドレス空間を割り当てるために使用されます。 次の例では、--pod-cidr が 10.244.0.0/16 であるため、最初のノードに 10.244.0.0/24、2 番目のノードに 10.244.1.0/24、3 番目のノードに 10.244.2.0/24 が割り当てられます。
    • クラスターをスケーリングまたはアップグレードすると、Azure プラットフォームによって、新しいノードごとにポッドの IP アドレス範囲が割り当てられ続けます。

ユーザー割り当てマネージド ID を使用して AKS クラスターを作成する

マネージド ID を作成する

• az identity コマンドを使用して、マネージド ID を作成します。 既存のマネージド ID がある場合は、代わりに az identity show --ids <identity-resource-id> コマンドを使用してプリンシパル ID を見つけます。

  az identity create --name myIdentity --resource-group myResourceGroup
  

  出力は、次の出力例のようになります。

  {                                  
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
    "location": "westus2",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

マネージド ID のロールの割り当てを追加する

Azure CLI を使用している場合、ロールは自動的に追加され、この手順をスキップできます。 ARM テンプレートまたは他のクライアントを使用している場合は、クラスターのマネージド ID のプリンシパル ID を使用して、ロールの割り当てを実行する必要があります。

• az network vnet show コマンドを使用して仮想ネットワーク リソース ID を取得し、VNET_ID という名前の変数として格納します。

  VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)
  

• az role assignment create コマンドを使用して、AKS クラスターのマネージド ID に仮想ネットワーク上のネットワーク共同作成者アクセス許可を割り当て、<principalId> を指定します。

  az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"
  
  # Example command
  az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

注

Azure によって使用されるクラスターのマネージド ID に付与されるアクセス許可は、設定までに最大 60 分かかる場合があります。

AKS クラスターを作成する

• az aks create コマンドを使用して AKS クラスターを作成し、assign-identity 引数にコントロール プレーンのマネージド ID リソース ID を指定して、ユーザー割り当てマネージド ID を割り当てます。

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --node-count 3 \
      --network-plugin kubenet \
      --vnet-subnet-id $SUBNET_ID \
      --assign-identity <identity-resource-id> \
      --generate-ssh-keys
  

AKS クラスターを作成すると、ネットワーク セキュリティ グループとルート テーブルが自動的に作成されます。 これらのネットワーク リソースは、AKS コントロール プレーンによって管理されます。 ネットワーク セキュリティ グループは、ノードの仮想 NIC と自動的に関連付けられます。 ルート テーブルは、仮想ネットワーク サブネットと自動的に関連付けられます。 サービスを作成して公開すると、ネットワーク セキュリティ グループ規則とルート テーブルが自動的に更新されます。

kubenet で独自のサブネットとルート テーブルを使用する

kubenet では、ルート テーブルがクラスター サブネット上に存在している必要があります。 AKS では、独自の既存のサブネットとルート テーブルの使用がサポートされています。 カスタム サブネットにルート テーブルが含まれていない場合は、AKS によって作成され、クラスターのライフサイクル全体にわたってルールが追加されます。 クラスターを作成するときにカスタム サブネットにルート テーブルが含まれている場合、クラスターの操作中に既存のルート テーブルが AKS で認識され、クラウド プロバイダーの操作に応じてルールが追加または更新されます。

警告

カスタム ルート テーブルにカスタム ルールを追加または更新できます。 ただし、Kubernetes クラウド プロバイダーによって追加されたルールは、更新または削除できません。 0.0.0.0/0 などのルールは通常、(エグレス送信タイプが none でなければ) 特定のルート テーブルに存在し、NVA や他のエグレス ゲートウェイなどのインターネット ゲートウェイのターゲットにマップされます。 ルールを更新する場合は注意が必要です。

カスタム ルート テーブルのセットアップに関する詳細を参照してください。

Kubernet ネットワークで要求を正常にルーティングするには、整理されたルート テーブル ルールが必要です。 この設計のため、ルート テーブルはそれに依存するクラスターごとに慎重に保守する必要があります。 異なるクラスターからのポッド CIDR が重複し、予期しないルーティングや壊れたルーティングのシナリオが発生する可能性があるため、複数のクラスターでルート テーブルを共有することはできません。 同じ仮想ネットワークで複数のクラスターを構成する場合、または仮想ネットワークを各クラスター専用にする場合は、次の制限事項を考慮してください。

• AKS クラスターを作成する前に、カスタム ルート テーブルをサブネットに関連付ける必要があります。
• クラスター作成後、関連付けられているルート テーブル リソースを更新することはできません。 ただし、カスタム ルールはルート テーブルで変更できます。
• AKS クラスターごとに、クラスターに関連付けられているすべてのサブネットに対して、一意のルート テーブルを 1 つだけ使用する必要があります。 ポッドの CIDR が重複し、ルーティング規則が競合する可能性があるため、複数のクラスターでルート テーブルを再利用することはできません。
• システム割り当てマネージド ID の場合、Azure CLI は自動的にロールの割り当てを追加するため、Azure CLI を使用して独自のサブネットとルート テーブルを提供することのみがサポートされます。 ARM テンプレートまたは他のクライアントを使用している場合は、ユーザー割り当てマネージド ID を使用し、クラスターの作成前にアクセス許可を割り当て、ユーザー割り当て ID にカスタム サブネットおよびカスタム ルート テーブルへの書き込みアクセス許可があることを確認する必要があります。
• 複数の AKS クラスターで同じルートテーブルを使用することはサポートされていません。

注

kubenet ネットワーク プラグインを使用して独自の VNet とルート テーブルを作成して使用する場合、クラスターのユーザー割り当てマネージド ID を構成する必要があります。 システム割り当てマネージド ID を使用すると、クラスターを作成する前に ID を取得できないため、ロールの割り当て中に延期期間が発生します。

Azure ネットワーク プラグインを使用して独自の VNet とルート テーブルを作成する場合、システム割り当てとユーザー割り当ての両方のマネージド ID がサポートされます。 BYO シナリオでは、ユーザー割り当てマネージド ID を使用することを強くお勧めします。

ユーザー割り当てマネージド ID を含むルート テーブルを AKS クラスターに追加する

カスタム ルート テーブルを作成して仮想ネットワーク内のサブネットに関連付けたら、ユーザー割り当てマネージド ID を含むルート テーブルを指定して新しい AKS クラスターを作成できます。 AKS クラスターをデプロイする予定の場所に対するサブネット ID を使用する必要があります。 また、このサブネットは、カスタム ルート テーブルに関連付けられている必要があります。

1. az network vnet subnet list コマンドを使用してサブネット ID を取得します。

   az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]
   

2. az aks create コマンドを使用し、--vnet-subnet-id および --assign-identity パラメーターの値を指定して、ルート テーブルで事前構成されたカスタム サブネットを使用して AKS クラスターを作成します。

   az aks create \
       --resource-group myResourceGroup \
       --name myManagedCluster \
       --vnet-subnet-id mySubnetIDResourceID \
       --assign-identity controlPlaneIdentityResourceID \
       --generate-ssh-keys
   

次のステップ

この記事では、AKS クラスターを既存の仮想ネットワーク サブネットにデプロイする方法を示しました。 これで、Helm を使用した新しいアプリの作成、または Helm を使用した既存のアプリのデプロイを開始できます。