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

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 ノード プール
  • 仮想ノード アドオン

Note

クラスター内の 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 ノードしかサポートできません。 このノード数では、最大で 240 個のポッドしかサポートできません (既定では、ノードあたり最大 30 ポッド)。

Note

これらの最大値では、アップグレードまたはスケーリング操作は考慮されていません。 実際には、サブネットの 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 クラスターを作成する

Note

システム割り当て 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    
  

  デプロイ パラメーター:

  • --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 アドレス空間を割り当てるために使用されます。 次の例では、10.244.0.0/16 の --pod-cidr によって、最初のノードに 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/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

Note

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>
  

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

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

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

警告

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

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

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

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

Note

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

独自の VNet とルート テーブルを作成して Azure ネットワーク プラグインで使用する場合、システム割り当ておよびユーザー割り当ての両方のマネージド 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、--enable-managed-identity、--assign-identity パラメーターの値を指定して、ルート テーブルで事前構成されたカスタム サブネットを使用して AKS クラスターを作成します。

   az aks create -g myResourceGroup -n myManagedCluster --vnet-subnet-id mySubnetIDResourceID --enable-managed-identity --assign-identity controlPlaneIdentityResourceID
   

次の手順

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