**協助改進此頁面**
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 將更多 IP 位址指派給具有字首的 Amazon EKS 節點
**適用於**：包含 Amazon EC2 執行個體的 Linux 和 Windows 節點
**適用於**：公有和私有子網路
每個 Amazon EC2 執行個體都支援最大數量的彈性網路介面，以及可指派給每個網路介面的最大數量的 IP 地址。每個節點的每個網路介面都需要一個 IP 地址。所有其他可用的 IP 地址都可以指派給 `Pods`。每個 `Pod` 都需要專屬的 IP 地址。因此，您的節點可能具有可用的運算和記憶體資源，但無法容納其他 `Pods`，因為節點已耗盡要指派給 `Pods` 的 IP 位址。
您可以透過指派 IP 字首 (而不是將個別的次要 IP 位址指派給節點)，大幅增加節點可指派給 `Pods` 的 IP 位址數量。每個字首都包含多個 IP 地址。如果您未針對 IP 字首指派設定叢集，則叢集必須進行更多 Amazon EC2 應用程式介面 (API) 呼叫，才能設定 Pod 連線所需的網路介面和 IP 位址。隨著叢集規模不斷擴大，這些 API 呼叫的頻率可能會導致 Pod 和執行個體的啟動時間變得更長。這樣一來，會導致擴展延遲以滿足大型和高峰工作負載的需求，並增加成本和管理負荷，因為您需要佈建額外的叢集和 VPC 以符合擴展需求。如需詳細資訊，請參閱 GitHub 上的 [Kubernetes 可擴展性閾值](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md)。
## 與適用於 Kubernetes 功能的 Amazon VPC CNI 外掛程式相容
您可以搭配 IP 字首使用下列功能：
+ IPv4 來源網路位址轉譯 - 如需詳細資訊，請參閱 [啟用 Pod 的傳出網際網路存取](external-snat.md)。
+ 叢集、Pod 及服務的 IPv6 位址 - 如需詳細資訊，請參閱 [了解叢集、Pod 與服務的 IPv6 位址](cni-ipv6.md)。
+ 使用 Kubernetes 網路政策來限制流量 - 如需詳細資訊，請參閱 [使用 Kubernetes 網路政策限制 Pod 流量](cni-network-policy.md)。
以下清單提供了適用的 Amazon VPC CNI 外掛程式設定的相關資訊。有關每個設定的更多資訊，請參閱 GitHub 上的 [amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md)。
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_PREFIX_TARGET`
## 考量事項
使用此功能時請考慮以下事項：
+ 每種 Amazon EC2 執行個體類型都支援最大數量的 Pod。如果受管節點群組包含多個執行個體類型，叢集中執行個體的最小 Pod 數量上限會套用至叢集中的所有節點。
+ 依預設，您最多可在節點上執行 110 個 `Pods`，但您可以變更該數量。如果您變更該數量且擁有現有受管節點群組，則節點群組的下一個 AMI 或啟動範本更新會導致新的工作節點出現變更後的值。
+ 從指派 IP 地址轉換為指派 IP 字首時，建議您建立新的節點群組來增加可用 IP 地址的數量，而不是對現有節點執行輪流取代。在同時指派 IP 位址和字首的節點上執行 Pod，可能會導致公告的 IP 位址容量不一致，進而影響節點日後的工作負載。有關執行轉換的建議方式，請參閱《*Amazon EKS 最佳實務指南*》中的 [Linux 的字首委派模式](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html)。
+ 安全群組範圍為節點層級 - 如需詳細資訊，請參閱[安全群組](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)。
+ 指派給網路介面的 IP 字首支援每個節點的高 Pod 密度，且具有最佳的啟動時間。
+ IP 字首和 IP 地址與標準 Amazon EC2 彈性網路介面相關聯。需要特定安全群組的 Pod 會被指派分支網路介面的主要 IP 地址。您可以把取得 IP 位址的 Pod，或從 IP 字首的 IP 位址與在相同節點上取得分支網路介面的 Pod 混合。
+ 僅適用於具有 Linux 節點的叢集。
+ 設定附加元件以指派字首給網路介面後，您就無法將 Kubernetes 專用 Amazon VPC CNI 外掛程式附加元件降級為低於 `1.9.0` (或 `1.10.1`) 的版本，且不移除叢集中所有節點群組中的所有節點。
+ 如果您也使用 Pod 的安全群組，且 `POD_SECURITY_GROUP_ENFORCING_MODE` = `standard`、`AWS_VPC_K8S_CNI_EXTERNALSNAT` = `false`，則當 Pod 與 VPC 外部端點通訊時，將使用節點的安全群組，而不會使用您指派給 Pod 的任何安全群組。
如果您也使用 Pod 的[安全群組](security-groups-for-pods.md)，且 `POD_SECURITY_GROUP_ENFORCING_MODE` = `strict`，則當 `Pods` 與 VPC 外部端點通訊時，將使用 `Pod’s` 安全群組。
# 增加 Amazon EKS 節點的可用 IP 位址數量
您可以透過指派 IP 字首 (而不是將個別的次要 IP 位址指派給節點)，大幅增加節點可指派給 Pod 的 IP 位址數量。
## 先決條件
+ 您需要現有的叢集。若要部署叢集，請參閱 [建立 Amazon EKS 叢集](create-cluster.md)。
+ Amazon EKS 節點所在的子網路必須具有足夠的連續 `/28` (針對 `IPv4` 叢集) 或 `/80` (針對 `IPv6` 叢集) 無類別域間路由 (CIDR) 區塊。`IPv6` 叢集中只能包含 Linux 節點。如果 IP 地址分散在子網路 CIDR 中，則使用 IP 字首可能會失敗。我們建議下列作法：
+ 使用子網路 CIDR 保留，如此一來，即使保留範圍內的任何 IP 位址仍在使用中，發布後也不會重新指派 IP 位址。此舉可確保字首無需分割，即可用於配置。
+ 使用專門用於執行指派 IP 字首之工作負載的新子網路。指派 IP 字首時，Windows 和 Linux 工作負載可在同一子網路中同時執行。
+ 若要將 IP 字首指派給節點，您的節點必須是 AWS Nitro 型。非 Nitro 型執行個體會繼續分配個別的次要 IP 位址，但要指派給 Pod 的 IP 位址數量遠低於 Nitro 型執行個體。
+ **僅適用於具有節點的叢集**：如果您的叢集針對 `IPv4` 系列設定，則必須安裝 Kubernetes 專用 Amazon VPC CNI 外掛程式附加元件的版本 `1.9.0` 或更新版本。您可以使用下列命令來檢查目前版本：
```
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
```
如果您的叢集針對 `IPv6` 系列設定，則必須安裝附加元件的版本 `1.10.1`。如果您的外掛程式版本早於所需版本，則必須對其進行更新。如需詳細資訊，請參閱[使用 Amazon VPC CNI 將 IP 指派給 Pod](managing-vpc-cni.md)的更新章節。
+ **僅適用於具有 Windows 節點的叢集**
+ 您必須為您的叢集啟用 Windows 支援。如需詳細資訊，請參閱[在 EKS 叢集上部署 Windows 節點](windows-support.md)。
## 將 IP 位址字首指派給節點
設定叢集以將 IP 地址字首指派給節點。完成與節點作業系統相符的程序。
### Linux
1. 啟用參數以為 Amazon VPC CNI DaemonSet 的網路介面指派字首。當您部署叢集時，Kubernetes 專用 Amazon VPC CNI 外掛程式附加元件的版本 `1.10.1` 或更高版本將與其一起部署。如果您使用 `IPv6` 系列建立叢集，則此設定會預設設為 `true`。如果您使用 `IPv4` 系列建立叢集，則此設定會預設設為 `false`。
```
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```
**重要**
即使子網路有可用的 IP 位址，如果子網路沒有任何可用的連續 `/28` 區塊，您也會在 Kubernetes 專用 Amazon VPC CNI 外掛程式日誌中看到下列錯誤。
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
這可能是由分散在子網路上的現有次要 IP 地址的分段造成。若要解決此錯誤，請建立新的子網路並在該處啟動 Pod，或使用 Amazon EC2 子網路 CIDR 保留來保留子網路內的空間，以便與字首指派搭配使用。如需詳細資訊，請參閱《Amazon VPC 使用者指南》中的[子網路 CIDR 保留](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)。
1. 如果計劃在沒有啟動範本的情況下或使用未在其中指定 AMI ID 的啟動範本來部署受管節點群組，且您使用的是先決條件中列出的 Kubernetes 專用 Amazon VPC CNI 外掛程式版本或更新版本，則請跳至下一個步驟。受管節點群組會自動為您計算 Pod 的數量上限。
如果要部署的是自我管理節點群組，或使用其中具有指定 AMI ID 的啟動範本來部署受管節點群組，則必須決定 Amazon EKS 為節點建議的 Pod 數量上限。請遵循 中的指示，將 `--cni-prefix-delegation-enabled` 新增至步驟 3。請記下輸出，以便在稍後步驟中使用。
**重要**
受管節點群組會強制對 `maxPods` 的值執行數量上限。對於少於 30 個 vCPU 的執行個體，數量上限為 110；對於所有其他執行個體，數量上限為 250。無論是否啟用字首委派，都會套用此數量上限。
1. 如果您使用針對 `IPv6` 設定叢集，請跳到下一個步驟。
在下列其中一個選項中指定參數。要判斷哪個選項適合您，以及提供哪個值，請參閱 GitHub 上的 [WARM\$1PREFIX\$1TARGET、WARM\$1IP\$1TARGET 和 MINIMUM\$1IP\$1TARGET](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md)。
您可以用大於零的值取代 example values。
+ `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
```
+ `WARM_IP_TARGET` 或 `MINIMUM_IP_TARGET`：如果此值已設定，則其會覆寫為 `WARM_PREFIX_TARGET` 設定的任何值。
```
kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
```
```
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
```
1. 使用至少一種 Amazon EC2 Nitro Amazon Linux 2023 執行個體類型，建立下列其中一個類型的節點群組。如需 Nitro 執行個體類型的清單，請參閱《Amazon EC2 使用者指南》中的[建置在 Nitro 系統上的執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances)。Windows 不支援這項功能。對於包含 *110* 的選項，使用步驟 3 的值 (建議) 或您自己的值將其取代。
+ **自我管理** – 使用[建立自我管理的 Amazon Linux 節點](launch-workers.md)中的指示來部署節點群組。建立 CloudFormation 堆疊之前，請開啟範本檔案，並將 `UserData`中的 調整`NodeLaunchTemplate`為如下
```
...
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: ${ClusterName}
apiServerEndpoint: ${ApiServerEndpoint}
certificateAuthority: ${CertificateAuthorityData}
cidr: ${ServiceCidr}
kubelet:
config:
maxPods: 110
...
```
如果使用 `eksctl` 來建立節點群組，便可使用以下命令。
```
eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
```
+ **受管**：使用下列其中一個選項，部署節點群組：
+ **沒有啟動範本，或有啟動範本，但沒有指定 AMI ID**：完成[建立叢集的受管節點群組](create-managed-node-group.md)中的程序。受管節點群組會自動為您計算 Amazon EKS 建議的 `max-pods` 值。
+ **使用具有指定 AMI ID 的啟動範本**：在啟動範本中，指定 Amazon EKS 最佳化 AMI ID 或基於 Amazon EKS 最佳化 AMI 的自訂 AMI，然後[使用啟動範本部署節點群組](launch-templates.md)，並在啟動範本中提供下列使用者資料。此使用者資料會傳遞`NodeConfig`物件，供節點上的`nodeadm`工具讀取。如需 的詳細資訊`nodeadm`，請參閱 [nodeadm 文件](https://awslabs.github.io/amazon-eks-ami/nodeadm)。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"
--//
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
apiServerEndpoint: [.replaceable]`my-cluster`
certificateAuthority: [.replaceable]`LS0t...`
cidr: [.replaceable]`10.100.0.0/16`
name: [.replaceable]`my-cluster
kubelet:
config:
maxPods: [.replaceable]`110`
--//--
```
如果使用 `eksctl` 來建立節點群組，便可使用以下命令。
```
eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
```
如果您建立的自訂 AMI 並非基於 Amazon EKS 最佳化 AMI，則需要自行自訂建立組態。
**注意**
如果您還想要將 IP 位址指派給來自與執行個體不同子網路的 Pod，則需要在此步驟中啟用該功能。如需詳細資訊，請參閱[使用自訂聯網在替代子網路中部署 Pod](cni-custom-network.md)。
### Windows
1. 啟用 IP 字首指派。
1. 開啟 `amazon-vpc-cni` `ConfigMap` 進行編輯。
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. 將下行新增至 `data` 區段：
```
enable-windows-prefix-delegation: "true"
```
1. 儲存檔案並關閉編輯器。
1. 確認行已新增至 `ConfigMap`。
```
kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
```
如果傳回的輸出不是 `true`，則可能會出現錯誤。請嘗試再次完成該步驟。
**重要**
即使子網路有可用的 IP 位址，如果子網路沒有任何可用的連續 `/28` 區塊，您也會在 Kubernetes 專用 Amazon VPC CNI 外掛程式日誌中看到下列錯誤。
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
這可能是由分散在子網路上的現有次要 IP 地址的分段造成。若要解決此錯誤，請建立新的子網路並在該處啟動 Pod，或使用 Amazon EC2 子網路 CIDR 保留來保留子網路內的空間，以便與字首指派搭配使用。如需詳細資訊，請參閱《Amazon VPC 使用者指南》中的[子網路 CIDR 保留](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)。
1. (選用) 指定其他組態來控制叢集的預先擴展和動態擴展行為。如需詳細資訊，請參閱 GitHub 上的 [Windows 上包含字首委派模式的組態選項](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md)。
1. 開啟 `amazon-vpc-cni` `ConfigMap` 進行編輯。
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. 將範例值取代為大於零的值，並將您需要的項目新增至 的 `data`區段`ConfigMap`。如果您為 `warm-ip-target` 或 `minimum-ip-target` 設定了值，則該值會覆寫任何為 `warm-prefix-target` 設定的值。
```
warm-prefix-target: "1"
warm-ip-target: "5"
minimum-ip-target: "2"
```
1. 儲存檔案並關閉編輯器。
1. 建立 Windows 節點群組，其中至少包含一個 Amazon EC2 Nitro 執行個體類型。如需 Nitro 執行個體類型的清單，請參閱《Amazon EC2 使用者指南》中的[建置在 Nitro 系統上的執行個體](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances)。依預設，您最多可將 110 個 Pod 部署到節點。如果您要增加或減少該數量，請在引導組態的使用者資料中指定以下內容：將 *max-pods-quantity* 取代為您的 max Pod 值。
```
-KubeletExtraArgs '--max-pods=max-pods-quantity'
```
如果您要部署受管節點群組，則需要在啟動範本中新增此組態。如需詳細資訊，請參閱[使用啟動範本自訂受管節點](launch-templates.md)。如需有關 Windows 引導指令碼組態參數的詳細資訊，請參閱 [引導指令碼組態參數](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)。
## 確定最大 Pod 和可用的 IP 位址
1. 部署您的節點後，請檢視叢集中的節點。
```
kubectl get nodes
```
範例輸出如下。
```
NAME STATUS ROLES AGE VERSION
ip-192-168-22-103.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
```
1. 描述其中一個節點，判斷該節點的 `max-pods` 值以及可用 IP 地址的數量。使用上一個輸出中傳回的其中一個節點名稱中的 `IPv4` 位址取代 *192.168.30.193*。
```
kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
```
範例輸出如下。
```
pods: 110
vpc.amazonaws.com/PrivateIPv4Address: 144
```
在先前的輸出中，`110` 是 Kubernetes 將部署至節點的 Pod 數量上限，即使有 *144* 個可用的 IP 位址。