Azure 容器網路介面 (CNI) Pod 子網
Azure CNI Pod 子網會將IP位址指派給來自叢集節點之不同子網的Pod。 此功能有兩種模式可供使用:動態IP配置和靜態區塊配置(預覽)。
必要條件
注意
使用 CIDR 的靜態區塊配置時,不支援使用 Kubernetes Load Balancer 服務將應用程式公開為 Private Link 服務。
請檢閱在 AKS 中設定基本 Azure CNI 網路的必要條件 (部分機器翻譯),因為本文適用相同的必要條件。
請檢閱在 AKS 中設定基本 Azure CNI 網路的部署參數 ,因為相同參數同樣適用。
不支援 AKS 引擎和 DIY 叢集。
Azure CLI 版本或更新版本
2.37.0
和aks-preview
擴充功能版本或更新版本2.0.0b2
。為您的訂用帳戶註冊訂用帳戶層級功能旗標:『Microsoft.ContainerService/AzureVnetScalePreview』。
如果您有現有的叢集,您必須啟用 Container Insights 來監視 IP 子網使用量附加元件。 您可以使用
az aks enable-addons
命令來啟用容器見解,如下列範例所示:az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>
動態IP配置模式
動態IP配置可藉由從裝載 AKS 叢集的子網配置 Pod IP,協助減輕 Pod IP 位址耗盡問題。
動態 IP 配置模式提供下列優點:
- 更有效地利用 IP:IP 會從 Pod 子網路動態分配給叢集 Pod。 相較於傳統 CNI 解決方案,此方式可更有效地利用叢集中的 IP。
- 具備擴充能力與彈性:節點和 Pod 子網路均可獨立擴充。 您可以在叢集的多個節點集區或部署在相同 VNet 中的多個 AKS 叢集中共用單一 Pod 子網路。 此外,您也可以為節點集區設定個別的 Pod 子網路。
- 高效能:由於 Pod 已獲指派 VNet IP,因此它們會直接連線到 VNet 中的其他叢集 Pod 和資源。 此解決方案可支援非常大量的叢集,且不會導致效能降低。
- 為 Pod 提供個別 VNet 原則:由於 Pod 具有個別的子網路,因此可為其設定不同於節點原則的個別 VNet 原則。 這可啟用許多實用的案例,例如只允許Pod的因特網聯機,而不是用於節點、使用 Azure NAT 閘道修正節點集區中 Pod 的來源 IP,以及使用網路安全組 (NSG) 來篩選節點集區之間的流量。
- Kubernetes 網路原則:Azure 網路原則和 Calico 都使用此模式。
規劃 IP 位址
使用動態IP配置,節點和Pod會獨立調整,因此您可以個別規劃其位址空間。 由於 Pod 子網路可設定為節點集區的細微性,因此,您一律可在新增節點集區時新增子網路。 叢集/節點集區中的系統 Pod 也會從 Pod 子網路接收 IP,因此必須將此行為納入考量。
IP 會以 16 個批次配置給節點。 Pod 子網 IP 配置應規劃叢集中每個節點至少 16 個 IP,因為節點在啟動時要求 16 個 IP,並在配置中未配置 8 個 IP 時 <要求另一批 16 個 IP。
Kubernetes 服務和 Docker Bridge 的 IP 地址規劃保持不變。
靜態區塊設定模式 (預覽)
靜態區塊配置可藉由將 CIDR 區塊指派給節點,而不是個別 IP,協助減輕潛在的 Pod 子網大小調整和 Azure 位址對應限制。
靜態區塊配置模式提供下列優點:
- 更好的IP延展性:CIDR 區塊會以靜態方式配置給叢集節點,並存在於節點的存留期,而不是使用傳統 CNI 的傳統動態配置個別 IP。 這會根據 CIDR 區塊啟用路由,並協助將叢集限制從每個叢集的傳統 65K Pod 調整為最多 100 萬個 Pod。 您的 Azure 虛擬網絡 必須夠大,才能容納叢集的規模。
- 彈性:節點和 Pod 子網可以獨立調整。 您可以在叢集的多個節點集區或部署在相同 VNet 中的多個 AKS 叢集中共用單一 Pod 子網路。 此外,您也可以為節點集區設定個別的 Pod 子網路。
- 高效能:由於 Pod 已獲指派虛擬網路 IP,因此它們會直接連線到 VNet 中的其他叢集 Pod 和資源。
- 為 Pod 提供個別 VNet 原則:由於 Pod 具有個別的子網路,因此可為其設定不同於節點原則的個別 VNet 原則。 這可實現許多實用案例,例如,僅針對 Pod 而非節點允許網際網路連線、使用 Azure NAT 閘道修正節點集區中 Pod 的來源 IP,以及使用 NSG 篩選節點集區之間的流量。
- Kubernetes 網路原則:Cilium、Azure NPM 和 Calico 可使用此解決方案。
限制
以下是使用 Azure CNI 靜態區塊配置的一些限制:
- 所需的 Kubernetes 最低版本為 1.28
- 支援的子網大小上限為 x.x.x.x/12 ~ 1 百萬個 IP
- Windows 節點集區不支援
- 不支援 Cilium 數據平面
- 每個子網只能使用單一作業模式。 如果子網使用靜態區塊配置模式,則無法在具有相同子網的不同叢集或節點集區中使用動態IP配置模式,反之亦然。
- 只有在新的叢集或將具有不同子網的節點集區新增至現有叢集時才支援。 不支援移轉或更新現有的叢集或節點集區。
- 在指派給節點集區中節點的所有 CIDR 區塊中,將會選取一個 IP 作為節點的主要 IP。 因此,對於網路管理員來說,選取
--max-pods
值會嘗試使用下列計算來最符合您的需求,並在子網中獲得最佳IP使用量:
max_pods = (N * 16) - 1
其中 N
是任何正整數和 N
> 0
區域可用性
此功能不適用於下列區域:
- 美國南部
- 美國東部 2
- 美國西部
- 美國西部 2
規劃 IP 位址
使用靜態區塊配置,節點和 Pod 會獨立調整,因此您可以個別規劃其地址空間。 由於 Pod 子網路可設定為節點集區的細微性,因此,您一律可在新增節點集區時新增子網路。 叢集/節點集區中的系統 Pod 也會從 Pod 子網路接收 IP,因此必須將此行為納入考量。
/28 (16 個 IP) 的 CIDR 區塊會根據節點 --max-pods
集區的組態配置給節點,這會定義每個節點的 Pod 數目上限。 1 IP 會保留於該節點上所有可用IP的每個節點上,以供內部使用。
規劃IP時,請務必使用下列計算來定義組 --max-pods
態: max_pods_per_node = (16 * N) - 1
,其中 N
是大於 0
的任何正整數。
沒有IP的理想值會要求 max pods 值符合上述表達式。
請參閱下列範例案例:
範例案例 | max_pods |
每個節點配置的 CIDR 區塊 | Pod 可用的IP總計 | 節點的IP wastage |
---|---|---|---|---|
低破壞(可以接受) | 30 | 2 | (16 * 2) - 1 = 32 - 1 = 31 | 31 - 30 = 1 |
理想案例 | 31 | 2 | (16 * 2) - 1 = 32 - 1 = 31 | 31 - 31 = 0 |
高破壞(不建議) | 32 | 3 | (16 * 3) - 1 = 48 - 1 = 47 | 47 - 32 = 15 |
Kubernetes 服務的IP位址規劃保持不變。
注意
請確定您的 VNet 具有足夠大且連續的地址空間,以支援叢集的規模。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應