本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Windows 網路 ## Windows 容器聯網概觀 Windows 容器與 Linux 容器基本上不同。Linux 容器使用 Linux 建構，例如命名空間、聯集檔案系統和 cgroup。在 Windows 上，這些建構是由[主機運算服務 (HCS)](https://github.com/microsoft/hcsshim) 從容器擷取。HCS 充當位於 Windows 上容器實作上方的 API 層。Windows 容器也會利用 Host Network Service (HNS) 來定義節點上的網路拓撲。 ![Windows 聯網](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/windows-networking.png) 從聯網的角度來看，HCS 和 HNS 可讓 Windows 容器像虛擬機器一樣運作。例如，每個容器都有連接到 Hyper-V 虛擬切換 (vSwitch) 的虛擬網路轉接器 (vNIC)，如上圖所示。 ## IP 地址管理 Amazon EKS 中的節點會使用其彈性網路界面 (ENI) 來連線至 AWS VPC 網路。目前，**每個 Windows 工作者節點僅支援單一 ENI**。Windows 節點的 IP 地址管理由在控制平面中執行的 [VPC 資源控制器](https://github.com/aws/amazon-vpc-resource-controller-k8s)執行。如需 Windows 節點 IP 地址管理工作流程的詳細資訊，請參閱[此處](https://github.com/aws/amazon-vpc-resource-controller-k8s#windows-ipv4-address-management)。 Windows 工作者節點可支援的 Pod 數量取決於節點的大小和可用的 IPv4 地址數量。您可以計算節點上可用的 IPv4 地址，如下所示： + 根據預設，只有次要 IPv4 地址會指派給 ENI。在這種情況下： ``` Total IPv4 addresses available for Pods = Number of supported IPv4 addresses in the primary interface - 1 ``` 我們從總數中減去一個，因為一個 IPv4 地址將用作 ENI 的主要地址，因此無法配置給 Pod。 + 如果叢集已透過啟用[字首委派功能](prefix-mode-win.md)設定為高 Pod 密度，則 ``` Total IPv4 addresses available for Pods = (Number of supported IPv4 addresses in the primary interface - 1) * 16 ``` 在這裡，VPC 資源控制器將配置 ，`/28 prefixes`而不是配置次要 IPv4 地址，因此，可用 IPv4 地址的整體數量將增加 16 次。 使用上述公式，我們可以根據 m5.large 執行個體計算 Windows 工作者節點的 Pod 上限，如下所示： + 根據預設，在次要 IP 模式下執行時 - ``` 10 secondary IPv4 addresses per ENI - 1 = 9 available IPv4 addresses ``` + 使用 時 `prefix delegation`- ``` (10 secondary IPv4 addresses per ENI - 1) * 16 = 144 available IPv4 addresses ``` 如需執行個體類型可支援多少 IP 地址的詳細資訊，請參閱每個[執行個體類型每個網路界面的 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)。 另一個關鍵考量因素是網路流量的流程。使用 Windows 時，超過 100 個服務的節點會有連接埠耗盡的風險。當出現此條件時，節點會開始擲回錯誤，並顯示下列訊息： **「政策建立失敗：hcnCreateLoadBalancer 在 Win32 中失敗：指定的連接埠已存在。」** 為了解決此問題，我們利用 Direct Server Return (DSR)。DSR 是非對稱網路負載分佈的實作。換句話說，請求和回應流量會使用不同的網路路徑。此功能可加速 Pod 之間的通訊，並降低連接埠耗盡的風險。因此，我們建議您在 Windows 節點上啟用 DSR。 預設會在 Windows Server SAC EKS Optimized AMIs中啟用 DSR。對於 Windows Server 2019 LTSC EKS 最佳化 AMIs，您將需要使用以下指令碼和使用 Windows Server 2019 Full 或 Core 做為 `eksctl` nodeGroup 中的 amiFamily，在執行個體佈建期間啟用它。如需其他資訊，請參閱 [eksctl 自訂 AMI](https://eksctl.io/usage/custom-ami-support/)。 ``` nodeGroups: - name: windows-ng instanceType: c5.xlarge minSize: 1 volumeSize: 50 amiFamily: WindowsServer2019CoreContainer ssh: allow: false ``` 若要在 Windows Server 2019 及更高版本中使用 DSR，您需要在執行個體啟動期間指定下列 [https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#load-balancing-and-services](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#load-balancing-and-services) 旗標。您可以透過調整與[自我管理節點群組啟動範本](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)相關聯的使用者資料指令碼來執行此操作。 ``` [string]$EKSBinDir = "$env:ProgramFiles\Amazon\EKS" [string]$EKSBootstrapScriptName = 'Start-EKSBootstrap.ps1' [string]$EKSBootstrapScriptFile = "$EKSBinDir\$EKSBootstrapScriptName" (Get-Content $EKSBootstrapScriptFile).replace('"--proxy-mode=kernelspace",', '"--proxy-mode=kernelspace", "--feature-gates WinDSR=true", "--enable-dsr",') | Set-Content $EKSBootstrapScriptFile & $EKSBootstrapScriptFile -EKSClusterName "eks-windows" -APIServerEndpoint "https://" -Base64ClusterCA "" -DNSClusterIP "172.20.0.10" -KubeletExtraArgs "--node-labels=alpha.eksctl.io/cluster-name=eks-windows,alpha.eksctl.io/nodegroup-name=windows-ng-ltsc2019 --register-with-taints=" 3>&1 4>&1 5>&1 6>&1 ``` DSR 啟用可以依照 [Microsoft 網路部落格](https://techcommunity.microsoft.com/t5/networking-blog/direct-server-return-dsr-in-a-nutshell/ba-p/693710)和 [AWS Lab 上的 Windows 容器](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US/module1-eks/lab3-handling-mixed-clusters)中的指示進行驗證。 ![dsr](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/dsr.png) 如果保留可用的 IPv4 地址並盡量減少浪費對您的子網路至關重要，通常建議避免使用字首委派模式，如 [Windows 字首模式中所述 - 何時避免](prefix-mode-win.md#windows-prefix-avoid)。如果仍然需要使用字首委派，您可以採取步驟來最佳化子網路中的 IPv4 地址使用率。如需如何微調 IPv4 地址請求和配置程序的詳細說明，請參閱[設定字首委派的參數](prefix-mode-win.md#windows-network-conserve)。調整這些組態可協助您在保留 IPv4 地址和字首委派的 Pod 密度優勢之間取得平衡。 使用指派次要 IPv4 地址的預設設定時，目前沒有支援的組態可操作 VPC 資源控制器請求和配置 IPv4 地址的方式。更具體地說， `minimum-ip-target`和 `warm-ip-target` 僅支援字首委派模式。另請注意，在次要 IP 模式中，根據界面上的可用 IP 地址，VPC 資源控制器通常會代表您在節點上配置 3 個未使用的 IPv4 地址，以維持暖 IPs以加快 Pod 啟動時間。如果您想要將未使用的暖 IP 地址 IP 浪費降至最低，您可以瞄準在指定的 Windows 節點上排程更多 Pod，以便盡可能使用 ENI 的 IP 地址容量。更明確地說， IPs 如果節點和執行中的 Pod 已在使用 ENI 上的所有 IP 地址，您可以避免使用暖未使用的 IP。另一個解決方法可協助您解決子網路中 IP 地址可用性的限制，可能是探索[增加子網路大小](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html)，或將您的 Windows 節點分成自己的專用子網路。 此外，請務必注意 Windows 節點目前不支援 IPv6。 ## 容器網路界面 (CNI) 選項 AWSVPC CNI 是適用於 Windows 和 Linux 工作者節點的事實 CNI 外掛程式。雖然 AWSVPC CNI 滿足許多客戶的需求，但有時候您可能需要考慮替代方法，例如覆蓋網路，以避免 IP 耗盡。在這些情況下，可以使用 Calico CNI 取代 AWSVPC CNI。[Project Calico](https://www.projectcalico.org/) 是由 [Tigera](https://www.tigera.io/) 開發的開放原始碼軟體。該軟體包含可與 EKS 搭配使用的 CNI。您可以在專案 Calico EKS 安裝頁面上找到在 [EKS 中安裝 Calico CNI ](https://docs.projectcalico.org/getting-started/kubernetes/managed-public-cloud/eks)的說明。 ## 網路政策 最佳實務是從 Kubernetes 叢集上 Pod 之間的預設開放通訊模式變更為根據網路政策限制存取。開放原始碼 [Project Calico](https://www.tigera.io/tigera-products/calico/) 對同時使用 Linux 和 Windows 節點的網路政策具有強大的支援。此功能是獨立的，不依賴使用 Calico CNI。因此，我們建議您安裝 Calico 並將其用於網路政策管理。 如需在 EKS 中安裝 Calico 的說明，請參閱在 [Amazon EKS 上安裝 Calico ](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)頁面。 此外，[Amazon EKS 安全最佳實務指南 - 網路區段](https://docs.aws.amazon.com/eks/latest/best-practices/network-security.html)中提供的建議同樣適用於具有 Windows 工作者節點的 EKS 叢集，不過，Windows 目前不支援某些功能，例如「Pod 安全群組」。