本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Windows 的字首模式
在 Amazon EKS 中，在 Windows 主機上執行的每個 Pod 預設都會由 [VPC 資源控制器](https://github.com/aws/amazon-vpc-resource-controller-k8s)指派次要 IP 地址。此 IP 地址是從主機子網路配置的 VPC 可路由地址。在 Linux 上，連接至執行個體的每個 ENI 都有多個插槽，可由次要 IP 地址或 /28 CIDR （字首） 填入。不過，Windows 主機僅支援單一 ENI 及其可用的插槽。只使用次要 IP 地址可以人工限制您可以在 Windows 主機上執行的 Pod 數量，即使有大量的 IP 地址可供指派。
為了增加 Windows 主機上的 Pod 密度，特別是在使用較小的執行個體類型時，您可以為 Windows 節點啟用**字首委派**。啟用字首委派時，會將 /28 IPv4 字首指派給 ENI 插槽，而不是次要 IP 地址。前綴委派可以透過將 `enable-windows-prefix-delegation: "true"`項目新增至`amazon-vpc-cni`組態映射來啟用。這與您需要設定`enable-windows-ipam: "true"`項目以啟用 Windows 支援的組態映射相同。
請遵循 [EKS 使用者指南](https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html)中提及的指示，為 Windows 節點啟用字首委派模式。
![\[兩個工作者子網路的圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/networking/pm_windows-1.jpg)
圖：次要 IP 模式與字首委派模式的比較
您可以指派給網路界面的 IP 地址數量上限取決於執行個體類型及其大小。指派給網路界面的每個字首都會使用可用的插槽。例如，`c5.large`執行個體每個網路界面有 個`10`插槽的限制。網路介面上的第一個插槽一律會由介面的主要 IP 地址耗用，讓您擁有 9 個字首和/或次要 IP 地址的插槽。如果已指派這些插槽字首，節點可以支援 (9 \$1 16) 144 個 IP 地址，如果已指派次要 IP 地址，則只能支援 9 個 IP 地址。如需詳細資訊，請參閱[每個執行個體類型每個網路介面 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)的文件[，以及將字首指派給網路介面](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-prefix-eni.html)。
在工作者節點初始化期間，VPC 資源控制器會為主要 ENI 指派一或多個字首，透過維護 IP 地址的暖集區來加快 Pod 啟動速度。您可以在`amazon-vpc-cni`組態映射中設定下列組態參數，以控制暖集區中保留的字首數量。
+ `warm-prefix-target`，超過目前需求的要配置字首數目。
+ `warm-ip-target`，超過目前需求要配置的 IP 地址數量。
+ `minimum-ip-target`，隨時可用的 IP 地址數量下限。
+ `warm-ip-target` 和/或`minimum-ip-target`如果設定 會覆寫 `warm-prefix-target`。
在節點上排程更多 Pod 時，系統會為現有的 ENI 請求額外的字首。在節點上排程 Pod 時，VPC 資源控制器會先嘗試從節點上現有的字首指派 IPv4 地址。如果無法這麼做，只要子網路具有所需的容量，就會請求新的 IPv4 字首。
![\[將 IP 指派給 Pod 的程序流程圖\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/networking/pm_windows-2.jpg)
圖：指派 IPv4 地址至 Pod 時的工作流程
## 建議
### 在 時使用字首委派
如果您在工作者節點上遇到 Pod 密度問題，請使用字首委派。為了避免錯誤，建議您在遷移至字首模式之前，先檢查子網路是否有 /28 字首的連續地址區塊。如需[子網路保留詳細資訊，請參閱「使用子網路保留以避免子網路分段 (IPv4)](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)」一節。
根據預設，Windows 節點`max-pods`上的 會設定為 `110`。對於絕大多數的執行個體類型，這應該已足夠。如果您想要增加或減少此限制，請在使用者資料中的引導命令中新增下列項目：
```
-KubeletExtraArgs '--max-pods=example-value'
```
如需 Windows 節點引導組態參數的詳細資訊，請參閱[此處](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html#bootstrap-script-configuration-parameters)的文件。
### 在 時避免字首委派
如果您的子網路片段很大，且可用 IP 地址不足以建立 /28 字首，請避免使用字首模式。如果產生字首的子網路分段 （具有分散次要 IP 地址的大量使用子網路），字首連接可能會失敗。建立新子網路並保留字首可避免此問題。
### 設定字首委派的參數以保留 IPv4 地址
`warm-prefix-target`、 `warm-ip-target`和 `minimum-ip-target`可用來使用字首微調預先擴展和動態擴展的行為。根據預設，會使用下列值：
```
warm-ip-target: "1"
minimum-ip-target: "3"
```
透過微調這些組態參數，您可以實現最佳平衡，以保留 IP 地址並確保因指派 IP 地址而降低 Pod 延遲。如需這些組態參數的詳細資訊，請參閱[此處](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md)的文件。
### 使用子網路預留來避免子網路分段 (IPv4)
當 EC2 將 /28 IPv4 字首配置給 ENI 時，它必須是來自子網路的連續 IP 地址區塊。如果產生字首的子網路是分段的 （具有分散次要 IP 地址的高度使用子網路），字首連接可能會失敗，而且您會看到下列節點事件：
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
為了避免分段並有足夠的連續空間來建立字首，請使用 [VPC 子網路 CIDR 保留](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html#work-with-subnet-cidr-reservations)來保留子網路內的 IP 空間，以供字首使用。建立保留後，不會將保留區塊中的 IP 地址指派給其他資源。如此一來，VPC 資源控制器就能在對節點 ENI 的指派呼叫期間取得可用的字首。
建議建立新的子網路、為字首預留空間，並為在該子網路中執行的工作者節點啟用字首指派。如果新的子網路專用於在啟用字首委派的 EKS 叢集中執行的 Pod，則您可以略過字首保留步驟。
### 從次要 IP 模式遷移至字首委派模式時取代所有節點，反之亦然
強烈建議您建立新的節點群組，以增加可用 IP 地址的數量，而不是輪流取代現有的工作者節點。
使用自我管理節點群組時，轉換的步驟如下：
+ 增加叢集中的容量，讓新節點能夠容納您的工作負載
+ 啟用/停用 Windows 的字首委派功能
+ 封鎖並耗盡所有現有的節點，以安全地移出所有現有的 Pod。為了防止服務中斷，建議您在關鍵工作負載的生產叢集上實作 [Pod 中斷預算](https://kubernetes.io/docs/tasks/run-application/configure-pdb)。
+ 確認 Pod 正在執行後，您可以刪除舊節點和節點群組。新節點上的 Pod 將從指派給節點 ENI 的字首指派 IPv4 地址。
使用受管節點群組時，轉換的步驟如下：
+ 啟用/停用 Windows 的字首委派功能
+ 使用[此處](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html)提及的步驟更新節點群組。這會執行與上述類似的步驟，但由 EKS 管理。
**警告**
在相同模式的節點上執行所有 Pod
對於 Windows，我們建議您避免同時在次要 IP 模式和字首委派模式下執行 Pod。當您從次要 IP 模式遷移至字首委派模式，反之亦然執行 Windows 工作負載時，可能會發生這種情況。
雖然這不會影響您執行中的 Pod，但節點的 IP 地址容量可能不一致。例如，假設 t3.xlarge 節點有 14 個用於次要 IPv4 地址的插槽。如果您執行 10 個 Pod，則次要 IP 地址會耗用 ENI 上的 10 個插槽。在您啟用字首委派後，公告至 kube-api 伺服器的容量為 （每個字首 14 個插槽 \$1 16 個 ip 地址） 244，但目前實際容量為 （每個字首 4 個剩餘插槽 \$1 16 個地址） 64。如果您執行的 Pod 數量超過可供指派的 IP 地址，則公告的容量與實際容量 （剩餘插槽） 數量之間的這種不一致可能會導致問題。
也就是說，您可以使用上述的遷移策略，將 Pod 從次要 IP 地址安全地轉換為從字首取得的地址。在模式之間切換時，Pod 會繼續正常執行，並且：
+ 從次要 IP 模式切換到字首委派模式時，不會釋出指派給執行中 Pod 的次要 IP 地址。字首將指派給可用插槽。一旦 Pod 終止，將會釋出其正在使用的次要 IP 和插槽。
+ 從字首委派模式切換到次要 IP 模式時，如果其範圍內的所有 IPs 都不再配置給 Pod，則會釋出字首。如果任何來自 字首的 IP 指派給 Pod，則該字首會保留到 Pod 終止為止。
### 使用字首委派對問題進行偵錯
您可以使用我們的偵錯指南[，](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/troubleshooting.md)深入了解您在 Windows 上字首委派所面臨的問題。