本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 最佳化 IP 地址使用率
**提示**
透過 Amazon EKS 研討會[探索](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)最佳實務。
由於應用程式現代化，容器化環境正在快速擴展。這表示正在部署越來越多的工作者節點和 Pod。
[Amazon VPC CNI](vpc-cni.md) 外掛程式會從 VPC 的 CIDR (s) 指派每個 Pod 的 IP 地址。此方法透過 VPC 流程日誌和其他監控解決方案等工具，提供 Pod 地址的完整可見性。根據您的工作負載類型，這可能會導致 Pod 耗用大量 IP 地址。
設計 AWS 聯網架構時，請務必在 VPC 和節點層級最佳化 Amazon EKS IP 使用量。這可協助您緩解 IP 耗盡問題，並提高每個節點的 Pod 密度。
在本節中，我們將討論可協助您實現這些目標的技巧。
## 最佳化節點層級 IP 消耗
[字首委派](https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html)是 Amazon Virtual Private Cloud (Amazon VPC) 的一項功能，可讓您將 IPv4 或 IPv6 字首指派給 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。它會增加每個網路界面 (ENI) 的 IP 地址，這會提高每個節點的 Pod 密度並改善您的運算效率。自訂聯網也支援字首委派。
如需詳細資訊，請參閱 [Linux 節點的字首委派](prefix-mode-linux.md)和 [Windows 節點的字首委派](prefix-mode-win.md)一節。
## 減少 IP 耗盡
為了防止叢集耗用所有可用的 IP 地址，我們強烈建議您調整 VPCs 和子網路的大小，並考量其成長。
採用 [IPv6](ipv6.md) 是從一開始就避免這些問題的好方法。不過，對於可擴展性需求超過初始規劃且無法採用 IPv6 的組織，改善 VPC 設計是對 IP 地址耗盡的建議回應。Amazon EKS 客戶最常用的技術是將不可路由CIDRs 新增至 VPC，並將 VPC CNI 設定為在將 IP 地址配置到 Pod 時使用此額外的 IP 空間。這通常稱為[自訂聯網](custom-networking.md)。
我們將介紹您可以使用哪些 Amazon VPC CNI 變數來最佳化指派給節點的 IPs 暖集區。我們將使用一些其他非 Amazon EKS 內部的架構模式來關閉本節，但有助於緩解 IP 耗盡。
### 使用 IPv6 （建議）
採用 IPv6 是解決 RFC1918 限制的最簡單方法；強烈建議您在選擇網路架構時考慮採用 IPv6 作為您的第一個選項。IPv6 提供更大的總 IP 地址空間，而叢集管理員可以專注於遷移和擴展應用程式，而無需努力解決 IPv4 限制。
Amazon EKS 叢集同時支援 IPv4 和 IPv6。根據預設，EKS 叢集會使用 IPv4 地址空間。在叢集建立時間指定 IPv6 型地址空間將啟用 IPv6 的使用。在 IPv6 EKS 叢集中，Pod 和服務會接收 IPv6 地址**，同時維持舊版 IPv4 端點連線到 IPv6 叢集上執行之服務的能力，反之亦然**。叢集內的所有 pod-to-pod 通訊一律會透過 IPv6 進行。在 VPC (/56) 中，IPv6 子網路的 IPv6 CIDR 區塊大小固定為 /64。這提供 2^64 （約 18 百分位數） IPv6 地址，允許 在 EKS 上擴展部署。
如需詳細資訊，請參閱[執行 IPv6 EKS 叢集](ipv6.md)一節，如需實作體驗，請參閱使用 [ IPv6 實作研討會中了解 Amazon EKS 上的](https://catalog.workshops.aws/ipv6-on-aws/en-US/lab-6) [ IPv6 ](https://catalog.workshops.aws/ipv6-on-aws/en-US)一節。
![\[IPv6 模式中的 EKS 叢集\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/networking/opt_ipv6.gif)
### 最佳化 IPv4 叢集中的 IP 消耗
本節專供執行舊版應用程式和/或尚未準備好遷移至 IPv6 的客戶使用。雖然我們鼓勵所有組織盡快遷移至 IPv6，但我們認識到，有些組織可能仍需要研究替代方法，以使用 IPv4 擴展容器工作負載。因此，我們也會逐步解說架構模式，以最佳化 Amazon EKS 叢集的 IPv4 (RFC1918) 地址空間使用。
#### 規劃成長
作為防禦 IP 耗盡的第一道防線，我們強烈建議將您的 IPv4 VPCs 和子網路大小納入增長考量，以防止您的叢集使用所有可用的 IP 地址。如果子網路沒有足夠的可用 IP 地址，您將無法建立新的 Pod 或節點。
在建置 VPC 和子網路之前，建議從所需的工作負載規模向後工作。例如，當使用 [eksctl](https://eksctl.io/) （在 EKS 上建立和管理叢集的簡單 CLI 工具） /19 子網路建置叢集時，預設會建立。/19 的網路遮罩適用於大多數工作負載類型，允許配置超過 8000 個地址。
**重要**
當您調整 VPCs和子網路的大小時，可能會有數個元素 (Pod 和節點除外） 可以使用 IP 地址，例如負載平衡器、RDS 資料庫和其他 Vpc 內服務。
此外，Amazon EKS 可以建立最多 4 個彈性網路介面 (X-ENI)，允許與控制平面通訊 （如需詳細資訊，請參閱[此處](subnets.md))。在叢集升級期間，Amazon EKS 會建立新的 X-ENIs並在升級成功時刪除舊的 X-ENI。因此，對於與 EKS 叢集相關聯的子網路，我們建議的網路遮罩至少為 /28 (16 個 IP 地址）。
您可以使用[範例 EKS 子網路計算器](https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsx)試算表來規劃您的網路。試算表會根據工作負載和 VPC ENI 組態計算 IP 用量。IP 用量會與 IPv4 子網路進行比較，以判斷組態和子網路大小是否足以滿足您的工作負載。請注意，如果您 VPC 中的子網路用完可用的 IP 地址，建議您使用 VPC 的原始 CIDR 區塊[建立新的子網路](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#create-subnets)。請注意，Amazon [EKS 現在允許修改叢集子網路和安全群組](https://aws.amazon.com/about-aws/whats-new/2023/10/amazon-eks-modification-cluster-subnets-security/)。
#### 自訂聯網
如果您即將耗盡 RFC1918 IP 空間，您可以使用[自訂網路](custom-networking.md)模式， IPs 透過在專用其他子網路中排程 Pod 來節省可路由 IP。雖然自訂聯網會接受次要 CIDR 範圍的有效 VPC 範圍，但我們建議您使用來自 CG-NAT 空間CIDRs (/16)，即 `100.64.0.0/10`或 ，`198.19.0.0/16`因為相較於 RFC1918 範圍，它們不太可能在公司設定中使用。
如需詳細資訊，請參閱[自訂聯網](custom-networking.md)的專用區段。
![\[自訂聯網\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/networking/opt_custom-networking.gif)
#### 增強型子網路探索
增強型子網路探索透過標記新的子網路，讓 [Amazon VPC CNI](vpc-cni.md) 可以探索它們，為 IP 耗盡提供簡化的網路組態替代方案。透過增強型子網路探索，目前的工作負載可以繼續在相同的子網路上執行，而 Amazon Elastic Kubernetes Service (Amazon EKS) 現在可以在新的「可用子網路」上排程額外的 Pod。
如果您叢集目前的子網路用完 IP 地址，您可以直接將其他子網路新增至 Amazon EKS 叢集，如下所示：
1. 將新的 CIDR 區塊與您的 VPC 建立關聯。
1. 在新的 CIDR 區塊中建立新的子網路，並使用 "kubernetes.io/role/cni" = "1" 標記它。
1. 啟用 Amazon VPC CNI 附加元件對「true」的 ENABLE\$1SUBNET\$1DISCOVERY 組態 （自 1.18.0 版以來的預設值）。
在 VPC 和 Amazon EKS 叢集上啟用增強型子網路探索後，新的彈性網路界面 (ENIs) 會連接到您的 Amazon EKS 節點，如下圖所述：
![\[增強型子網路探索\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/networking/opt_enhanced-subnet-discovery.gif)
如需詳細資訊，請參閱 AWS 容器部落格上的 [Amazon VPC CNI 推出增強型子網路探索](https://aws.amazon.com/blogs/containers/amazon-vpc-cni-introduces-enhanced-subnet-discovery/)。
#### 最佳化 IPs暖集區
使用預設組態時，VPC CNI 會將整個 ENI （和相關聯的 IPs) 保留在暖集區中。這可能會耗用大量 IPs，特別是在較大的執行個體類型上。
如果您的叢集子網路可用 IP 地址數量有限，請仔細檢查這些 VPC CNI 組態環境變數：
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_ENI_TARGET`
您可以設定 的值`MINIMUM_IP_TARGET`，以符合您預期在節點上執行的 Pod 數量。這樣做將確保在建立 Pod 時，CNI 可以從暖集區指派 IP 地址，而無需呼叫 EC2 API。
請注意，將值設定為`WARM_IP_TARGET`太低，將對 EC2 API 造成額外的呼叫，這可能會導致請求限流。對於大型叢集，請使用 搭配 `MINIMUM_IP_TARGET`來避免調節請求。
若要設定這些選項，您可以下載`aws-k8s-cni.yaml`資訊清單並設定環境變數。撰寫時，最新版本位於[此處](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/config/master/aws-k8s-cni.yaml)。檢查組態值的版本是否符合安裝的 VPC CNI 版本。
**警告**
當您更新 CNI 時，這些設定將重設為預設值。請在更新 CNI 之前進行備份。檢閱組態設定，判斷是否需要在更新成功後重新套用。
您可以即時調整 CNI 參數，而不會讓現有應用程式停機，但您應該選擇可支援可擴展性需求的值。例如，如果您使用的是批次工作負載，建議您更新預設值`WARM_ENI_TARGET`以符合 Pod 擴展需求。`WARM_ENI_TARGET` 設定為高值一律會維持執行大型批次工作負載所需的暖 IP 集區，因此可避免資料處理延遲。
**警告**
改善 VPC 設計是對 IP 地址耗盡的建議回應。考慮 IPv6 和次要 CIDRs等解決方案。在排除其他選項之後，調整這些值以將暖 IPs 數量降至最低，應該是暫時的解決方案。錯誤設定這些值可能會干擾叢集操作。在對生產系統進行任何變更之前，請務必檢閱[此頁面](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/eni-and-ip-target.md)上的考量事項。
#### 監控 IP 地址庫存
除了上述解決方案之外，也請務必掌握 IP 使用率。您可以使用 [CNI 指標協助程式](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md)監控子網路的 IP 地址庫存。一些可用的指標包括：
+ 叢集可支援的 ENIs 數量上限
+ 已配置ENIs 數量
+ 目前指派給 Pod 的 IP 地址數量
+ 可用的 IP 地址總數和上限
您也可以設定 [CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)，以便在子網路用完 IP 地址時收到通知。
**警告**
確定 VPC CNI 的`DISABLE_METRICS`變數設定為 false。
#### 其他考量事項
還有其他非 Amazon EKS 內部的架構模式，可協助 IP 耗盡。例如，您可以[最佳化跨 VPCs通訊](subnets.md#cross-vpcs)[，或跨多個帳戶共用 VPC](subnets.md#subnets-multiple-accounts)，以限制 IPv4 地址配置。
在此處進一步了解這些模式：
+ [設計超大規模 Amazon VPC 網路](https://aws.amazon.com/blogs/networking-and-content-delivery/designing-hyperscale-amazon-vpc-networks/)、
+ [使用 Amazon VPC Lattice 建置安全的多帳戶多 VPC 連線](https://aws.amazon.com/blogs/networking-and-content-delivery/build-secure-multi-account-multi-vpc-connectivity-for-your-applications-with-amazon-vpc-lattice/)。