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 Overlay 支援
IPAM Azure CNI Node 子網 支援
IPAM Azure CNI Pod 子網與動態 IP 分配 不支援
網路外掛 Kubenet 不支援
資料平面 Azure CNI Powered by Cilium 可搭配受支援的 Azure CNI IPAM 模式
網路原則 Calico 不支援

使用 Azure CNI Overlay 搭配 Azure CNI Powered by Cilium 數據平面。 Cilium 提供進階網路功能，並針對 NAP 的效能進行了最佳化。

NAP 的子網路設定

在 vnetSubnetID 資源中設定選用的 AKSNodeClass 欄位，以設定 Karpenter 用於佈建 NAP 節點的自訂子網路。 如果你沒有指定 vnetSubnetID，Karpenter 會使用安裝時設定的預設子網路，這通常是你建立 AKS 叢集時參數所指定的 --vnet-subnet-id 子網路。

NAP 會自動部署、配置並管理 Karpenter 在你的 AKS 叢集上，並基於開源的 Karpenter 及 AKS Karpenter 供應商 專案。

AKSNodeClass 你的 AKS 叢集上的資源可以各自指定不同的 vnetSubnetID，這讓節點池間的子網路配置能夠混合。 沒有指定 vnetSubnetID 欄位的節點類別會使用叢集的預設子網路設定。

子網路漂移行為

Karpenter 會監視子網路配置變更，並在 vnetSubnetID中的AKSNodeClass被修改時檢測偏移。 在管理自訂網路設定時，了解此行為至關重要。

對於使用自訂虛擬網路的叢集，從一個有效子網切換 vnetSubnetID 到另一個子網會導致與該 AKSNodeClass 子網相關的現有節點漂移。 Karpenter 會在新的子網路中建立替換節點，並根據NodePool中斷預算平順地淘汰已漂移的節點。

在更改 vnetSubnetID之前，請確保叢集身份在新子網路上擁有所需的權限，且該子網路有足夠的可用 IP 位址作為替代節點。 Pod 中斷預算和karpenter.sh/do-not-disrupt註釋可能會延遲自願性漂移取代。

這很重要

AKS 管理的虛擬網路不支援自訂子網路。 僅可將 vnetSubnetID 與由您管理的自訂虛擬網路搭配使用。

適用於 NAP 的 AKS 叢集 CIDR 範圍

當你用 設定自訂網路 vnetSubnetID時，你需要了解並管理叢集的 CIDR 範圍，以避免網路衝突。 與傳統透過 Azure Resource Manager（ARM）範本建立的 AKS 節點池不同，Karpenter 套用自訂資源定義（CRD），能即時配置節點，無需 ARM 提供的延伸驗證。

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 具有讀取子網路資訊並將節點加入指定子網路的必要權限。 這需要為叢集的受控識別設定適當的 RBAC 許可權。

執行下列命令的人員必須具備建立所需角色定義和角色指派的權限，例如 角色型存取控制管理員 角色。 除非叢集身份需要為其他情境建立角色指派，否則不要賦予叢集身份角色指派寫入權限。

取得叢集受控識別的主體識別碼。 使用對應叢集身份類型的指令：

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

設定這些許可權有兩種主要方法： 指派廣泛的虛擬網路 （VNet） 許可權 或 指派範圍子網路許可權。

此方法是最寬鬆的方法，可授與叢集身分識別許可權，以讀取和加入主要 VNet 內的任何子網，並提供網路參與者存取權。

這很重要

網路貢獻者角色授予 Microsoft.Network/*，允許叢集身份在指定的 VNet 範圍內建立、修改及刪除網路資源。 在使用該角色前，請先檢視此存取權限，因為 NAP 在此情境下僅需子網讀取與加入權限。

優點和考量事項

下表說明在 VNet 範圍內指派網路貢獻者角色的權衡。

廣泛 VNet 權限的好處 廣泛 VNet 權限的考量
• 簡化權限管理。
• 新增子網路時無需更新權限。
• 適用於單一租戶環境。
• 當訂用帳戶達到自訂角色數目上限時的功能。		 • 提供比絕對必要的更廣泛的權限。
• 可能不符合嚴格的安全要求。

所需權限

若要指派廣泛的 VNet 許可權，請將叢集的託管識別授予下列 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 節點的自訂子網路：

將 spec.vnetSubnetID 欄位設為目標子網路的完整 Azure 資源識別碼，並使用 /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName} 格式。

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"

自備 CNI （BYO CNI） 支援政策

Karpenter for Azure 允許自帶容器網路介面（BYO CNI）設定，且遵循與 AKS 相同的支援政策。 BYO CNI 不會讓 NAP 列為不受支援的設定（例如 kubenet 或 Calico）變成受支援。 使用自訂 CNI 時，與網路相關的故障排除支援不屬於任何服務水準協議或保固範圍。

支援範圍詳細資料

以下概述將 BYO CNI 與 Karpenter 搭配使用時支援的內容和不支援的內容：

  • 支援: 使用自備（BYO）CNI 設定時，Karpenter 特定的功能和整合性問題。
  • 不支援: 使用第三方 CNI 外掛程式時，CNI 特定的網路問題、設定問題或疑難排解。

後續步驟

如需 AKS 中節點自動布建的詳細資訊，請參閱下列文章：

  • Last updated on