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

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

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 アドレスを受け取る方法を示します。

AKS クラスターでの kubenet ネットワークモデル

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 でサポートされていない機能には次のものが含まれます。

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

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 機能を使用する必要がある。

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

仮想ネットワークとサブネットの作成

az group create コマンドを使用して、リソースグループを作成します。
```
az group create --name myResourceGroup --location eastus
```
使用できる既存の仮想ネットワークとサブネットがない場合は、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
```
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 \
    --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 アドレス空間を割り当てるために使用されます。次の例では、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> \
    --generate-ssh-keys
```

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

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

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

警告

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

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

Kubenet ネットワークで要求を正常にルーティングするには、整理されたルートテーブルルールが必要です。この設計のため、ルートテーブルはそれに依存するクラスターごとに慎重に保守する必要があります。異なるクラスターからのポッド 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 を使用する必要があります。このサブネットは、カスタムルートテーブルに関連付けられている必要もあります。

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

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

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 を使用した既存のアプリのデプロイを開始できます。

次の方法で共有

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

前提条件

開始する前に

独自のサブネットでの kubenet ネットワークの概要

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

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

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

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

仮想ネットワークとサブネットの作成

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

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

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

マネージド ID の作成

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

AKS クラスターを作成する

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

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

次のステップ

その他のリソース

次の方法で共有

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

前提条件

開始する前に

独自のサブネットでの kubenet ネットワークの概要

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

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

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

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

仮想ネットワークとサブネットの作成

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

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

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

マネージド ID の作成

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

AKS クラスターを作成する

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

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

次のステップ

その他のリソース

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

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

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

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