共用方式為

Azure 容器網路介面 (CNI) Pod 子網路

  • 發行項

Azure CNI Pod 子網路會將 IP 位址指派給來自叢集節點之不同子網路的 Pod。 此功能有兩種模式可供使用：動態 IP 配置和靜態區塊配置 (預覽)。

必要條件

注意

使用 CIDR 的靜態區塊配置時，不支援使用 Kubernetes Load Balancer Service 將應用程式公開為 Private Link 服務。

  • 請檢閱在 AKS 中設定基本 Azure CNI 網路的必要條件 (部分機器翻譯)，因為本文適用相同的必要條件。

  • 請檢閱在 AKS 中設定基本 Azure CNI 網路的部署參數 ，因為相同參數同樣適用。

  • 不支援 AKS 引擎和 DIY 叢集。

  • Azure CLI 2.37.0 版或更新版本，以及 aks-preview 延伸模組 2.0.0b2 版或更新版本。

  • 為您的訂用帳戶註冊訂用帳戶層級功能旗標：'Microsoft.ContainerService/AzureVnetScalePreview'。

  • 如果您有現有的叢集，則必須啟用容器深入解析來監視 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 橋接器的 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
  • 每個子網路只能使用單一作業模式。 如果子網路使用靜態區塊配置模式，則無法在具有相同子網路的不同叢集或節點集區中使用動態 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 數目上限。 每個節點上會從該節點的所有可用 IP 保留 1 個 IP，以供內部使用。

規劃 IP 時，請務必使用下列計算來定義 --max-pods 組態：max_pods_per_node = (16 * N) - 1，其中 N 是大於 0 的任何正整數。

沒有 IP 的理想值會要求最大 Pod 值符合上述運算式。

請參閱下列範例案例：

範例案例 max_pods 每個節點配置的 CIDR 區塊 Pod 可用的 IP 總計 節點的 IP 浪費
低浪費 (可接受) 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 具有足夠大且連續的位址空間，以支援叢集的規模。