Azure Kubernetes Service (AKS) でのノード自動プロビジョニング (NAP) のネットワーク構成の概要

この記事では、ノード自動プロビジョニング (NAP) を使用した Azure Kubernetes Service (AKS) クラスターのネットワーク構成要件と推奨事項の概要について説明します。 サポートされている構成、既定のサブネット動作、ロールベースのアクセス制御 (RBAC) のセットアップ、クラスレスドメイン間ルーティング (CIDR) に関する考慮事項について説明します。

AKS でのノード自動プロビジョニングの概要については、 Azure Kubernetes Service (AKS) でのノード自動プロビジョニング (NAP) の概要に関するページを参照してください。

NAP でサポートされているネットワーク構成

NAP のネットワーク サポートを評価する場合は、IP アドレス管理 (IPAM) モード、ネットワーク プラグイン、ネットワーク データ プレーン、およびネットワーク ポリシーを検討してください。 次の表では、NAP でサポートされるオプションについて説明します。

設定レイヤー Option NAP のサポート
IPAM Azure CNI オーバーレイ サポートされています
IPAM Azure CNI ノード サブネット サポートされています
IPAM 動的 IP 割り当てによる Azure CNI ポッド サブネット サポートしていません
ネットワーク プラグイン Kubenet サポートしていません
データ プレーン cilium を搭載した Azure CNI サポートされている Azure CNI IPAM モードでサポートされます
ネットワーク ポリシー Calico サポートしていません

Azure CNI Overlay を Azure CNI Powered by Cilium データ プレーンと共に使用します。 Cilium は高度なネットワーク機能を提供し、NAP でのパフォーマンスのために最適化されています。

NAP のサブネット構成

karpenter が NAP ノードのプロビジョニングに使用するカスタム サブネットを構成するには、AKSNodeClass リソースの省略可能な vnetSubnetID フィールドを設定します。 vnetSubnetIDを指定しない場合、Karpenter はインストール時に構成された既定のサブネットを使用します。これは通常、AKS クラスターの作成時に --vnet-subnet-id パラメーターで指定されたサブネットです。

NAP は、AKS クラスターに Karpenter を自動的にデプロイ、構成、および管理します。これは、オープンソース の Karpenter および AKS Karpenter プロバイダー プロジェクトに基づいています。

AKSNodeClass AKS クラスター上のリソースは、それぞれ異なる vnetSubnetIDを指定できます。これにより、ノード プール間での混合サブネット構成が可能になります。 指定しないノード クラス vnetSubnetID クラスターの既定のサブネット構成を使用します。

サブネットのドリフト挙動

Karpenter は、サブネット構成の変更を監視し、vnetSubnetIDのAKSNodeClassが変更されたときの誤差を検出します。 この動作を理解することは、カスタム ネットワーク構成を管理する際に重要です。

カスタム仮想ネットワークを使用するクラスターの場合、有効なサブネット間で vnetSubnetID を変更すると、 AKSNodeClass に関連付けられている既存のノードがドリフトします。 Karpenter は、新しいサブネットに置換ノードを作成し、NodePool中断予算に従ってドリフトしたノードを適切に中断します。

vnetSubnetIDを変更する前に、クラスター ID に新しいサブネットに必要なアクセス許可があること、およびサブネットに代替ノードに使用できる十分な IP アドレスがあることを確認します。 ポッドの中断予算と karpenter.sh/do-not-disrupt 注釈は、自発的なドリフトの置換を遅らせる可能性があります。

Important

AKS で管理される仮想ネットワークは、カスタム サブネットをサポートしていません。 vnetSubnetIDは、管理するカスタム仮想ネットワークでのみ使用します。

NAP の AKS クラスターの CIDR 範囲

vnetSubnetIDを使用してカスタム ネットワークを構成する場合は、ネットワークの競合を回避するために、クラスターの CIDR 範囲を理解して管理する必要があります。 Azure Resource Manager (ARM) テンプレートを使用して作成する従来の AKS ノード プールとは異なり、Karpenter は、ARM が提供する拡張検証なしでノードを即座にプロビジョニングするカスタム リソース定義 (CRD) を適用します。

NAP カスタム サブネット構成の CIDR に関する考慮事項

vnetSubnetIDを構成する場合は、次の手順を実行する必要があります。

  • CIDR の互換性を確認する: カスタム サブネットが既存の CIDR 範囲と競合しないようにします。
  • IP 容量を計画する: 予想されるスケーリングに必要な IP アドレスを計算します。
  • 接続を検証する: ネットワーク ルートとセキュリティ グループの規則をテストします。
  • 使用状況の監視: サブネットの使用率を追跡し、成長を計画します。
  • ドキュメントの構成: ネットワーク設計上の決定の記録を保持します。

一般的な CIDR の競合

NAP でカスタム サブネットを使用する場合は、次の一般的な CIDR 競合シナリオに注意してください。

次の例は、クラスター ポッドおよびサービス CIDR と競合するサブネット CIDR 範囲と、それらの競合を回避する構成を示しています。 vnetSubnetIDを構成する前に、これらのパターンを使用してサブネット範囲を検証します。

# Example conflict scenarios:
# Cluster Pod CIDR: 10.244.0.0/16  
# Custom Subnet:   10.244.1.0/24  ❌ CONFLICT

# Service CIDR:    10.0.0.0/16
# Custom Subnet:   10.0.10.0/24   ❌ CONFLICT

# Safe configuration:
# Cluster Pod CIDR: 10.244.0.0/16
# Service CIDR:     10.0.0.0/16  
# Custom Subnet:    10.1.0.0/24   ✅ NO CONFLICT

カスタム サブネット構成の RBAC セットアップ

NAP でカスタム サブネット構成を使用する場合は、Karpenter がサブネット情報を読み取り、ノードを指定されたサブネットに参加させるために必要なアクセス許可を持っていることを確認する必要があります。 これには、クラスターのマネージド ID に適切な RBAC アクセス許可を設定する必要があります。

次のコマンドを実行するユーザーには、Role Based Access Control Administrator ロールなど、必要なロール定義とロール割り当てを作成するためのアクセス許可が必要です。 別のシナリオでロールの割り当てを作成する必要がない限り、クラスター ID にロール割り当ての書き込みアクセス許可を付与しないでください。

クラスターのマネージド ID のプリンシパル ID を取得します。 クラスター ID の種類に対応するコマンドを使用します。

CLUSTER_IDENTITY=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query identity.principalId \
  --output tsv)

これらのアクセス許可を設定するには、2 つの主な方法があります。 広範な仮想ネットワーク (VNet) アクセス許可 を 割り当てるか、スコープ付きサブネットのアクセス許可を割り当てます。

この方法は最も制限が緩く、メイン VNet 内のサブネットを読み取って参加させるアクセス許可をクラスター ID に付与し、ネットワーク共同作成者アクセスを提供します。

Important

ネットワーク共同作成者ロールは、Microsoft.Network/*を付与します。これにより、クラスター ID は、割り当てられた VNet スコープ内のネットワーク リソースを作成、変更、および削除できます。 NAP にはこのシナリオのサブネットの読み取りと参加のアクセス許可のみが必要であるため、運用環境でロールを使用する前に、このアクセス権を確認してください。

利点と考慮事項

次の表は、VNet スコープでネットワーク共同作成者ロールを割り当てる際のトレードオフの概要を示しています。

広範な VNet アクセス許可の利点 広範な VNet アクセス許可に関する考慮事項
• アクセス許可の管理を簡素化します。
• 新しいサブネットを追加するときにアクセス許可を更新する必要がなくなります。
• シングルテナント環境に適しています。
• サブスクリプションがカスタム ロールの最大数に達したときに機能します。		 • 厳密に必要以上に広範なアクセス許可を提供します。
• 厳密なセキュリティ要件を満たしていない可能性があります。

必要なアクセス許可

広範な VNet アクセス許可を割り当てるには、クラスターのマネージド ID に VNet に対する次のアクセス許可を付与します。

# Get your VNet resource ID
VNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME"

# Assign Network Contributor role for subnet read/join operations
az role assignment create \
  --assignee-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Network Contributor" \
  --scope $VNET_ID

カスタム ネットワークを設定し、広範な VNet アクセス許可を割り当てる完全な例については、 カスタム VNet のセットアップ - 最も制限の緩い RBAC サンプル スクリプトを参照してください。

カスタム サブネット構成の例

次の例では、vnetSubnetID リソースの AKSNodeClass フィールドを使用して NAP ノードのカスタム サブネットを構成する方法を示します。

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}形式を使用して、spec.vnetSubnetID フィールドをターゲット サブネットの完全なAzure リソース ID に設定します。

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

次の例は、異なるサブネット構成で複数のノード クラスを使用する方法を示しています。

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$FRONTEND_SUBNET_NAME"
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: backend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

Bring Your Own CNI (BYO CNI) サポート ポリシー

Karpenter for Azure では、独自の Container Network Interface (BYO CNI) 構成を使用でき、AKS と同じサポート ポリシーに従います。 BYO CNI では、KUbenet や Calico など、NAP がサポートされていないものとして一覧表示される構成はサポートされません。 カスタム CNI を使用する場合、ネットワークに関連するトラブルシューティング サポートは、サービス レベルアグリーメントまたは保証の範囲外です。

サポート スコープの詳細

Karpenter で BYO CNI を使用する場合の概要とサポートされない内容を次に示します。

  • サポートされる: Bring Your Own (BYO) CNI 構成を使用する場合の Karpenter 固有の機能と統合の問題。
  • サポートされていません:CNI 固有のネットワークの問題、構成の問題、またはサードパーティの CNI プラグインを使用する場合のトラブルシューティング。

次のステップ

AKS でのノード自動プロビジョニングの詳細については、次の記事を参照してください。

  • Last updated on