**協助改進此頁面** 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 進行 EKS 自動模式設定 本章內容介紹如何設定 Amazon Elastic Kubernetes Service (EKS) 自動模式叢集的特定層面。儘管 EKS 自動模式可自動管理大多數基礎結構元件，但您可自訂某些功能來滿足工作負載需求。 藉助本主題中所述的組態選項，您可修改聯網設定、運算資源及負載平衡行為，同時確保自動化管理基礎結構的優勢。做出任何組態變更之前，檢閱以下章節中所述的可用選項，確定哪種方法最能滿足您的需求。 | 您想要設定的功能有哪些？ | 組態選項 | | --- | --- | | **節點聯網及儲存** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [建立 Amazon EKS 的節點類別](create-node-class.md) | | **節點運算資源** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [為 EKS 自動模式建立節點集區](create-node-pool.md) | | **靜態容量節點集區** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [EKS Auto 模式的靜態容量節點集區](auto-static-capacity.md) | | **Application Load Balancer 設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [建立 IngressClass 以設定 Application Load Balancer](auto-configure-alb.md) | | **Network Load Balancer 設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [使用服務注釋設定 Network Load Balancer](auto-configure-nlb.md) | | **儲存類別設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [建立儲存類別](create-storage-class.md) | | **控制 ODCR 用量** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [使用 EKS 自動模式控制工作負載部署至容量保留](auto-odcr.md) | | **節點進階安全性** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/settings-auto.html) | [設定節點的進階安全設定](auto-advanced-security.md) | # 建立 Amazon EKS 的節點類別 Amazon EKS 節點類別是範本，可讓您精細控制 EKS 自動模式受管節點的組態。節點類別定義套用至 EKS 叢集中節點群組的基礎結構層級設定，包括網路組態、儲存設定和資源標記。本主題闡釋如何建立和設定節點類別，以滿足您的特定操作需求。 當您需要自訂 EKS 自動模式在預設設定之外，佈建和設定 EC2 執行個體的方式時，建立節點類別可讓您精確控制關鍵基礎結構參數。例如，您可以指定私有子網路放置以增強安全性，為效能敏感的工作負載設定執行個體暫時性儲存，或套用自訂標記以進行成本分配。 ## 建立節點類別 要建立 `NodeClass`，請執行下列步驟： 1. 使用節點類別組態建立 YAML 檔案 (例如 `nodeclass.yaml`) 1. 使用 `kubectl` 將組態套用至您的叢集 1. 在節點集區組態中參考節點類別。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。 您需要已安裝並設定 `kubectl`。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。 ### 基本節點類別範例 以下是一個節點類別範例： ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: private-compute spec: subnetSelectorTerms: - tags: Name: "private-subnet" kubernetes.io/role/internal-elb: "1" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" ephemeralStorage: size: "160Gi" ``` 此 NodeClass 會增加節點上的暫時性儲存量。 透過以下方式套用此組態： ``` kubectl apply -f nodeclass.yaml ``` 接下來，在節點集區組態中參考節點類別。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。 ## 建立節點類別存取項目 如果您建立了自訂節點類別，則需要建立 EKS 存取項目以允許節點加入叢集。在當您使用內建節點類別和節點集區時，EKS 會自動建立存取項目。 如需項目存取方法的相關資訊，請參閱 [使用 EKS 存取項目授予 IAM 使用者 Kubernetes 的存取權](access-entries.md)。 為 EKS 自動模式節點類別建立存取項目時，您需要使用 `EC2` 存取項目類型。 ### 使用 CLI 建立存取項目 **要建立 EC2 節點的存取項目，並關聯 EKS Auto Node 政策：** 使用您的叢集名稱和節點角色 ARN 更新以下 CLI 命令。節點角色 ARN 在節點類別 YAML 中指定。 ``` # Create the access entry for EC2 nodes aws eks create-access-entry \ --cluster-name \ --principal-arn \ --type EC2 # Associate the auto node policy aws eks associate-access-policy \ --cluster-name \ --principal-arn \ --policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \ --access-scope type=cluster ``` ### 使用 CloudFormation 建立存取項目 **要建立 EC2 節點的存取項目，並關聯 EKS Auto Node 政策：** 使用您的叢集名稱和節點角色 ARN 更新以下 CloudFormation。節點角色 ARN 在節點類別 YAML 中指定。 ``` EKSAutoNodeRoleAccessEntry: Type: AWS::EKS::AccessEntry Properties: ClusterName: PrincipalArn: Type: "EC2" AccessPolicies: - AccessScope: Type: cluster PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy DependsOn: [ ] # previously defined in CloudFormation ``` 有關部署 CloudFormation 堆疊的資訊，請參閱 [CloudFormation 入門](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html) ## 節點類別規格 ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: my-node-class spec: # Required fields # role and instanceProfile are mutually exclusive fields. role: MyNodeRole # IAM role for EC2 instances # instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances subnetSelectorTerms: - tags: Name: "private-subnet" kubernetes.io/role/internal-elb: "1" # Alternative using direct subnet ID # - id: "subnet-0123456789abcdef0" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" # Alternative approaches: # - id: "sg-0123456789abcdef0" # - name: "eks-cluster-security-group" # Optional: Pod subnet selector for advanced networking podSubnetSelectorTerms: - tags: Name: "pod-subnet" kubernetes.io/role/pod: "1" # Alternative using direct subnet ID # - id: "subnet-0987654321fedcba0" # must include Pod security group selector also podSecurityGroupSelectorTerms: - tags: Name: "eks-pod-sg" # Alternative using direct security group ID # - id: "sg-0123456789abcdef0" # Optional: Selects on-demand capacity reservations and capacity blocks # for EKS Auto Mode to prioritize. capacityReservationSelectorTerms: - id: cr-56fac701cc1951b03 # Alternative Approaches - tags: Name: "targeted-odcr" # Optional owning account ID filter owner: "012345678901" # Optional fields snatPolicy: Random # or Disabled networkPolicy: DefaultAllow # or DefaultDeny networkPolicyEventLogs: Disabled # or Enabled ephemeralStorage: size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T iops: 3000 # Range: 3000-16000 throughput: 125 # Range: 125-1000 # Optional KMS key for encryption kmsKeyID: "arn:aws: kms:region:account:key/key-id" # Accepted formats: # KMS Key ID # KMS Key ARN # Key Alias Name # Key Alias ARN advancedNetworking: # Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass. # If not set, defaults to the MapPublicIpOnLaunch setting on the subnet. associatePublicIPAddress: false # Optional: Forward proxy, commonly requires certificateBundles as well # for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters #httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use [] noProxy: #Max 50 entries - localhost #Max 255 characters each - 127.0.0.1 #- ::1 # IPv6 localhost #- 0:0:0:0:0:0:0:1 # IPv6 localhost - 169.254.169.254 # EC2 Instance Metadata Service #- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service # Domains to exclude, put all VPC endpoints here - .internal - .eks.amazonaws.com # ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode. ipv4PrefixSize: Auto # or "32" # enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters enableV4Egress: false advancedSecurity: # Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs. fips: false # Optional: Custom certificate bundles. certificateBundles: - name: "custom-cert" data: "base64-encoded-cert-data" # Optional: Additional EC2 tags (with restrictions) tags: Environment: "production" Team: "platform" # Note: Cannot use restricted tags like: # - kubernetes.io/cluster/* # - karpenter.sh/provisioner-name # - karpenter.sh/nodepool # - karpenter.sh/nodeclaim # - karpenter.sh/managed-by # - eks.amazonaws.com/nodeclass ``` ## 考量事項 + 如果您想要確認執行個體有多少本機儲存，可以描述節點以查看暫時性儲存資源。 + **磁碟區加密** - EKS 使用設定的自訂 KMS 金鑰來加密執行個體的唯讀根磁碟區及讀取/寫入資料磁碟區。 + **取代節點 IAM 角色** - 如果您變更與 `NodeClass` 相關聯的節點 IAM 角色，則需要建立新的存取項目。EKS 在叢集建立期間會自動為節點 IAM 角色建立存取項目。節點 IAM 角色需要 `AmazonEKSAutoNodePolicy` EKS 存取政策。如需詳細資訊，請參閱[使用 EKS 存取項目授予 IAM 使用者 Kubernetes 的存取權](access-entries.md)。 + **最大 Pod 密度** - EKS 會將節點上的最大 Pod 數量限制為 110。此限制是在現有的最大 Pod 計算之後套用的。如需詳細資訊，請參閱[選擇最佳的 Amazon EC2 節點執行個體類型](choosing-instance-type.md)。 + **標籤** - 如果您想要將標籤從 Kubernetes 傳播到 EC2，需要設定其他 IAM 許可。如需詳細資訊，請參閱[了解 EKS 自動模式中的身分和存取](auto-learn-iam.md)。 + **預設節點類別** - 請勿將您的自訂節點類別命名為 `default`。這是因為 EKS 自動模式包含一個名為 `default` 的 `NodePool`，當您啟用至少一個內建 `NodeClass` 時會自動佈建該類別。如需啟用內建 `NodePools` 的詳細資訊，請參閱 [啟用或停用內建的 NodePool](set-builtin-node-pools.md)。 + **具有多個子網路的 `subnetSelectorTerms` 行為** - 如果有多個子網路符合 `subnetSelectorTerms` 條件或您按 ID 提供的子網路，EKS 自動模式會建立分佈於各個子網路中的節點。 + 如果子網路位於不同的可用區域 (AZ)，您可以使用 Kubernetes 功能，例如 [Pod 拓撲分散限制](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints)條件和[拓撲感知路由](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/)，分別將 Pod 和流量分散到各個區域。 + 如果*同一個 AZ 中*有多個子網路符合 `subnetSelectorTerms`，則 EKS 自動模式會在該可用區域中分散在各個子網路的每個節點上建立 Pod。EKS 自動模式會在相同 AZ 中其他子網路中的每個節點建立次要網路介面。它根據每個子網路中可用 IP 位址的數量進行選擇，以更高效地使用子網路。但是，您無法指定 EKS 自動模式為每個 Pod 使用的子網路；如果您需要 Pod 在特定子網路中執行，請改用 [Pod 的個別子網路和安全群組](#pod-subnet-selector)。 ## Pod 的個別子網路和安全群組 `podSubnetSelectorTerms` 和 `podSecurityGroupSelectorTerms` 欄位允許 Pod 使用與其節點不同的子網路和安全群組，以啟用進階聯網組態。兩個欄位必須一起指定。這種分離可增強對網路流量路由與安全政策的控制。 **注意** 此功能不同於 AWS VPC CNI 用於非EKS Auto Mode 運算的 [Pod 安全群組](security-groups-for-pods.md) (SGPP) 功能。EKS Auto 模式不支援 SGPP。反之，請在 `podSecurityGroupSelectorTerms`中使用 `NodeClass`，將個別的安全群組套用至 Pod 流量。安全群組適用於 `NodeClass`層級，這表示使用 `NodeClass`共用相同 Pod 安全群組之節點上的所有 Pod。 ### 運作方式 當您設定 `podSubnetSelectorTerms`和 時`podSecurityGroupSelectorTerms`： 1. 節點的主要 ENI 使用來自 和 的子網路`subnetSelectorTerms`和安全群組`securityGroupSelectorTerms`。只有節點自己的 IP 地址才會指派給此界面。 1. EKS Auto Mode 會在符合 的子網路中建立次要 ENIs`podSubnetSelectorTerms`，並`podSecurityGroupSelectorTerms`連接來自 的安全群組。根據預設，Pod IP 地址會使用 /28 字首從這些次要 ENIs 配置，並在連續字首區塊無法使用時自動回復到次要 IPs (/32)。如果在 `"32"`中`ipv4PrefixSize`將 設定為 `advancedNetworking`，則只會使用次要 IPs。 1. 中指定的安全群組`podSecurityGroupSelectorTerms`適用於 VPC 內的 Pod 流量。對於目的地為 VPC 之外的流量，Pod 會使用節點的主要 ENI （及其安全群組），因為來源網路位址轉譯 (SNAT) 會將 Pod IP 轉譯為節點 IP。您可以使用 中的 `snatPolicy` 欄位修改此行為`NodeClass`。 ### 使用案例 當您需要`podSecurityGroupSelectorTerms`時，請使用 `podSubnetSelectorTerms`和 ： + 套用不同的安全群組，分別控制節點和 Pod 的流量。 + 將基礎設施流量 node-to-node通訊） 與應用程式流量 (Pod-to-Pod通訊） 分開。 + 對節點子網路和 Pod 子網套用不同的聯網組態。 + 專門為節點流量設定反向代理或網路篩選, 而不影響 Pod 流量。使用 `advancedNetworking` 和 `certificateBundles` 來定義您的反向代理，以及代理的任何自簽署或私有憑證。 ### 範例組態 ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: advanced-networking spec: role: MyNodeRole # Subnets and security groups for EC2 instances (nodes) subnetSelectorTerms: - tags: Name: "node-subnet" kubernetes.io/role/internal-elb: "1" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" # Separate subnets and security groups for Pods podSubnetSelectorTerms: - tags: Name: "pod-subnet" kubernetes.io/role/pod: "1" podSecurityGroupSelectorTerms: - tags: Name: "eks-pod-sg" ``` ### 個別 Pod 子網路和安全群組的考量事項 + **安全群組範圍**： 的安全群組`podSecurityGroupSelectorTerms`會連接至次要 ENIs，並套用至 VPC 內的 Pod 流量。啟用 SNAT 時 （預設 `snatPolicy: Random`)，離開 VPC 的流量會轉譯為節點的主要 ENI IP 地址，因此節點的安全群組`securityGroupSelectorTerms`會套用至該流量。如果您設定 `snatPolicy: Disabled`，Pod 會針對所有流量使用自己的 IP 地址，而且您必須確保相應地設定路由和安全群組。 + **NodeClass 層級精細程度**：Pod 安全群組適用於使用 排程在節點上的所有 Pod`NodeClass`。若要將不同的安全群組套用至不同的工作負載，請建立個別 `NodeClass` 和 `NodePool` 資源，並使用污點、容錯或節點選擇器，將工作負載排程到適當的節點。 + **降低 Pod 密度**：每個節點上執行的 Pod 較少，因為節點的主要網路介面預留給節點 IP，且無法用於 Pod。 + **子網路選擇器限制**：標準`subnetSelectorTerms`和`securityGroupSelectorTerms`組態不適用於 Pod 子網路或安全群組選擇。 + **網路規劃**：確保節點和 Pod 子網路中有足夠的 IP 位址空間，以支援您的工作負載需求。 + **路由組態**：確認 Pod 子網路的路由表和網路存取控制清單 (ACL) 已正確設定，以便在節點和 Pod 子網路之間進行通訊。 + **可用區域**：確認您已在多個 AZ 中建立 Pod 子網路。如果您使用的是特定的 Pod 子網路，它必須與節點子網路 AZ 位於相同的 AZ 中。 ## Pod 的次要 IP 模式 `ipv4PrefixSize` 欄位透過僅將次要 IP 地址配置給節點來啟用進階聯網組態。此功能不會將字首 (/28) 配置給節點，而且只會維護一個次要 IP 做為 MinimalIPTarget。 ### 使用案例 當您需要以下功能時，可使用 `ipv4PrefixSize`： + **降低 IP 使用率**：每個節點只會暖機一個 IP 地址。 + **較低的 Pod 追逐率**：Pod 建立速度不是主要問題。 + **無字首分割**：字首導致的分割是使用自動模式的主要考量或封鎖程式。 ### 範例組態 ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: advanced-networking spec: role: MyNodeRole advancedNetworking: ipv4PrefixSize: "32" ``` ### 次要 IP 模式的考量事項 + **降低 Pod 建立速度**：由於只有一個次要 IP 已暖機，因此在建立更多 Pod 時，IPAM 服務需要更多時間來佈建 IPs。 ## 在 IPv4IPv6 叢集中停用 IPv6 Pod 的 IPv6 輸出。 `enableV4Egress` 欄位`true`預設為 。對於自動模式 IPv6 叢集，此功能可以停用，因此自動模式不會為 IPv6 Pod 建立僅輸出 IPv4 界面。這很重要，因為 IPv4 輸出界面不受網路政策強制執行的約束。網路政策僅在 Pod 的主要界面 (eth0) 上強制執行。 ### 使用案例 當您需要以下功能時，可使用 `enableV4Egress`： + **使用 IPv6 叢集**：預設允許 IPv4 輸出流量。 + **使用網路政策**：目前 EKS 網路政策不支援雙堆疊。停用`enableV4Egress`可防止 Pod 流量意外透過 IPv4 輸出。 ### 範例組態 ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: advanced-networking spec: role: MyNodeRole advancedNetworking: enableV4Egress: false ``` ### 停用 enableV4Egress 的考量事項 + **IPv6 叢集中的網路政策**：IPv6 叢集預設允許 IPv4 流量。設定 會`enableV4Egress: false`封鎖 IPv4 輸出流量，提供增強的安全性，特別是在與網路政策搭配使用時。 # 為 EKS 自動模式建立節點集區 Amazon EKS 節點集區提供了彈性的方式來管理 Kubernetes 叢集中的運算資源。本主題示範如何使用 Karpenter 建立和設定節點集區，這是一種有助於最佳化叢集擴展與資源使用率的節點佈建工具。透過 Karpenter 的 NodePool 資源，您可以為運算資源定義特定要求，包括執行個體類型、可用區域、架構和容量類型。 您無法修改內建 `system` 和 `general-purpose` 節點集區。您僅可以啟用或停用它們。如需詳細資訊，請參閱 [啟用或停用內建的 NodePool](set-builtin-node-pools.md)。 NodePool 規格透過各種支援的標籤和要求，允許對 EKS 叢集的運算資源進行精細控制。這些選項包括指定 EC2 執行個體類別、CPU 組態、可用區域、架構 (ARM64/AMD64) 及容量類型 (Spot 或隨需)。您還可以為 CPU 和記憶體用量設定資源限制，確保您的叢集保持在所需的操作範圍內。 EKS 自動模式利用眾所周知的 Kubernetes 標籤，提供一致且標準化的方式來識別節點特性。這些標籤遵循既定的 Kubernetes 慣例，例如用於可用區域的 `topology.kubernetes.io/zone` 和用於 CPU 架構的 `kubernetes.io/arch`。此外，EKS 特定標籤 (字首為 `eks.amazonaws.com/`) 使用 AWS 特定屬性延伸此功能，例如執行個體類型、CPU 製造商、GPU 功能和聯網規格。這種標準化的標籤系統可讓您與現有的 Kubernetes 工具無縫整合，同時提供深度 AWS 基礎結構整合。 ## 建立 NodePool 請遵循以下步驟為您的 Amazon EKS 叢集建立 NodePool： 1. 使用所需的 NodePool 組態建立名為 `nodepool.yaml` 的 YAML 檔案。您可以使用以下範例組態。 1. 將 NodePool 套用至您的叢集： ``` kubectl apply -f nodepool.yaml ``` 1. 確認已成功建立 NodePool： ``` kubectl get nodepools ``` 1. (選用) 監控 NodePool 狀態： ``` kubectl describe nodepool default ``` 確保您的 NodePool 參照了叢集中存在的有效 NodeClass。NodeClass 為您的運算資源定義了特定於 AWS 的組態。如需詳細資訊，請參閱 [建立 Amazon EKS 的節點類別](create-node-class.md)。 ## 範例 NodePool ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: my-node-pool spec: template: metadata: labels: billing-team: my-team spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m", "r"] - key: "eks.amazonaws.com/instance-cpu" operator: In values: ["4", "8", "16", "32"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-west-2a", "us-west-2b"] - key: "kubernetes.io/arch" operator: In values: ["arm64", "amd64"] limits: cpu: "1000" memory: 1000Gi ``` ## EKS 自動模式支援的標籤 EKS 自動模式支援下列眾所周知的標籤。 **注意** EKS 自動模式使用與 Karpenter 不同的標籤。與 EC2 受管執行個體相關的標籤以 `eks.amazonaws.com` 開頭。 | 標籤 | 範例 | 描述 | | --- | --- | --- | | topology.kubernetes.io/zone | us-east-2a | AWS 區域 | | node.kubernetes.io/instance-type | g4dn.8xlarge | AWS 執行個體類型 | | kubernetes.io/arch | amd64 | 架構由執行個體上的 [GOARCH 值](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58)定義 | | karpenter.sh/capacity-type | spot | 容量類型包括 `spot`、`on-demand` | | eks.amazonaws.com/instance-hypervisor | nitro | 使用特定 Hypervisor 的執行個體類型 | | eks.amazonaws.com/compute-type | auto | 識別 EKS 自動模式受管節點 | | eks.amazonaws.com/instance-encryption-in-transit-supported | true | 支援 (或不支援) 傳輸中加密的執行個體類型 | | eks.amazonaws.com/instance-category | g | 相同類別的執行個體類型，通常為產生編號之前的字串 | | eks.amazonaws.com/instance-generation | 4 | 執行個體類別內的執行個體類型產生編號 | | eks.amazonaws.com/instance-family | g4dn | 屬性類似，但資源數量不同的執行個體類型 | | eks.amazonaws.com/instance-size | 8xlarge | 資源數量類似，但屬性不同的執行個體類型 | | eks.amazonaws.com/instance-cpu | 32 | 執行個體上的 CPU 數量 | | eks.amazonaws.com/instance-cpu-manufacturer | `aws` | CPU 製造商的名稱 | | eks.amazonaws.com/instance-memory | 131072 | 執行個體上的記憶體 MiB 數 | | eks.amazonaws.com/instance-ebs-bandwidth | 9500 | 執行個體上可用 EBS 的[最大 MiB ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance)數 | | eks.amazonaws.com/instance-network-bandwidth | 131072 | 執行個體上可用的[基準兆位](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html)數 | | eks.amazonaws.com/instance-gpu-name | t4 | 執行個體上的 GPU 名稱 (如有) | | eks.amazonaws.com/instance-gpu-manufacturer | nvidia | GPU 製造商的名稱 | | eks.amazonaws.com/instance-gpu-count | 1 | 執行個體上的 GPU 數 | | eks.amazonaws.com/instance-gpu-memory | 16384 | GPU 上的記憶體 MiB 數 | | eks.amazonaws.com/instance-local-nvme | 900 | 執行個體上本機 nvme 儲存體的 GiB 數 | **注意** EKS 自動模式僅支援特定執行個體，且具有最小大小需求。如需詳細資訊，請參閱 [EKS 自動模式支援的執行個體參考](automode-learn-instances.md#auto-supported-instances)。 ## EKS 自動模式不支援的標籤 EKS 自動模式不支援以下標籤。 + EKS 自動模式僅支援 Linux + `node.kubernetes.io/windows-build` + `kubernetes.io/os` ## 停用內建節點集區 如果您建立了自訂節點集區，可以停用內建節點集區。如需詳細資訊，請參閱 [啟用或停用內建的 NodePool](set-builtin-node-pools.md)。 ## 沒有內建節點集區的叢集 您可建立沒有內建節點集區的叢集。當您的組織已建立自訂節點集區時，這會很有幫助。 **注意** 當您建立沒有內建節點集區的叢集時，`default` NodeClass 不會自動佈建。您需要建立自訂的 NodeClass。如需詳細資訊，請參閱 [建立 Amazon EKS 的節點類別](create-node-class.md)。 **概觀** 1. 建立 EKS 叢集，其 `nodePools` 和 `nodeRoleArn` 值均為空。 + 範例 eksctl `autoModeConfig`： ``` autoModeConfig: enabled: true nodePools: [] # Do not set a nodeRoleARN ``` 如需詳細資訊，請參閱[使用 eksctl CLI 建立 EKS 自動模式叢集](automode-get-started-eksctl.md) 1. 使用節點角色 ARN 建立自訂節點類別 + 如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md) 1. 為自訂節點類別建立存取項目 + 如需詳細資訊，請參閱[建立節點類別存取項目](create-node-class.md#auto-node-access-entry) 1. 如上所述，建立自訂節點集區。 ## 中斷 您可透過多種方式設定 EKS 自動模式，以透過您的 NodePool 來中斷節點。您可以使用 `spec.disruption.consolidationPolicy`、`spec.disruption.consolidateAfter` 或 `spec.template.spec.expireAfter`。您還可以透過 NodePool 的 `spec.disruption.budgets` 來限制 EKS 自動模式的中斷速率。您還可以控制時間範圍和同時中斷的節點數量。有關設定此行為的說明，請參閱 Karpenter 文件中的[中斷](https://karpenter.sh/docs/concepts/disruption/)。 您可將節點集區的中斷設定為： + 識別執行個體未得到充分利用的時間，並合併工作負載。 + 建立節點集區中斷預算，以限制因偏離、空置和合併而導致的節點終止速率。 根據預設，EKS 自動模式： + 合併未充分利用的執行個體。 + 在 336 小時後終止執行個體。 + 設定單一中斷預算為節點的 10%。 + 當新的自動模式 AMI 發布時，允許因偏離而取代節點，這大約每週發生一次。 ## 終止寬限期 當 `terminationGracePeriod` 未在 EKS Auto NodePool 上明確定義時，系統會自動將預設的 24 小時終止寬限期套用到關聯的 NodeClaim。雖然 EKS Auto 不會在其自訂 NodePool 組態中看到預設的 `terminationGracePeriod`，但他們會在 NodeClaim 上觀察到此預設值。無論寬限期是在 NodePool 上明確設定，還是在 NodeClaim 上預設，功能都保持一致，確保了叢集中可預測的節點終止行為。 # EKS Auto 模式的靜態容量節點集區 Amazon EKS Auto Mode 支援靜態容量節點集區，無論 Pod 需求為何，都能維持固定數量的節點。靜態容量節點集區適用於需要可預測容量、預留執行個體或特定合規需求的工作負載，而您需要維持一致的基礎設施使用量。 與根據 Pod 排程需求擴展的動態節點集區不同，靜態容量節點集區會維持您已設定的節點數量。 ## 設定靜態容量節點集區 若要建立靜態容量節點集區，請在 NodePool 規格中設定 `replicas` 欄位。`replicas` 欄位定義節點集區將維護的確切節點數量。如需如何設定 [範例](#static-capacity-examples)，請參閱 `replicas`。 ## 靜態容量節點集區考量事項 靜態容量節點集區有幾項重要的限制條件和行為： **組態限制：** + **無法切換模式**：在節點集區`replicas`上設定後，就無法將其移除。節點集區無法在靜態和動態模式之間切換。 + **資源限制**：限制區段僅支援 `limits.nodes` 欄位。CPU 和記憶體限制不適用。 + **無權重欄位**：由於節點選擇不是根據優先順序，因此無法在靜態容量節點集區上設定 `weight` 欄位。 **操作行為：** + **無合併**：靜態容量集區中的節點不會考慮合併。 + **擴展操作**：擴展操作會略過節點中斷預算，但仍遵守 PodDisruptionBudgets。 + **節點替換**：節點仍會根據您的組態替換成偏離 （例如 AMI 更新） 和過期。 ## 最佳實務 **容量規劃：** + 設定`limits.nodes`高於 `replicas` 以允許在節點取代操作期間暫時擴展。 + 設定限制時，請考慮節點偏離或 AMI 更新期間所需的最大容量。 **執行個體選擇：** + 當您有預留執行個體或特定硬體需求時，請使用特定執行個體類型。 + 避免在擴展期間限制執行個體可用性的過度限制需求。 **中斷管理：** + 設定適當的中斷預算，以平衡可用性與維護操作。 + 設定預算百分比時，請考慮您應用程式的節點替換公差。 **監控：** + 定期監控 `status.nodes` 欄位，以確保維持所需的容量。 + 設定實際節點計數偏離所需複本時的提醒。 **區域分佈：** + 為了實現高可用性，請將靜態容量分散到多個可用區域。 + 當您建立跨越多個可用區域的靜態容量節點集區時，EKS Auto Mode 會將節點分散到指定區域，但不保證分佈均勻。 + 若要跨可用區域進行可預測且均勻的分佈，請建立個別的靜態容量節點集區，每個集區都會使用 `topology.kubernetes.io/zone`需求固定到特定的可用區域。 + 如果您需要將 12 個節點平均分散到三個區域，請建立三個節點集區，每個節點集區各有 4 個複本，而不是一個節點集區，在三個區域各有 12 個複本。 ## 擴展靜態容量節點集區 您可以使用 `kubectl scale`命令變更靜態容量節點集區中的複本數量： ``` # Scale down to 5 nodes kubectl scale nodepool static-nodepool --replicas=5 ``` 縮減規模時，EKS Auto Mode 會正常終止節點，遵守 PodDisruptionBudgets，並允許將執行中的 Pod 重新排程到剩餘的節點。 ## 監控靜態容量節點集區 使用下列命令來監控靜態容量節點集區： ``` # View node pool status kubectl get nodepool static-nodepool # Get detailed information including current node count kubectl describe nodepool static-nodepool # Check the current number of nodes kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}' ``` `status.nodes` 欄位顯示節點集區管理的目前節點數量，在正常情況下應符合您所需的`replicas`計數。 ## 疑難排解 **未到達所需複本的節點：** + 檢查`limits.nodes`值是否足夠 + 確認您的需求不會過度限制執行個體選取 + 檢閱您正在使用的執行個體類型和區域的 AWS 服務配額 **節點替換耗時太長：** + 調整中斷預算以允許更多並行取代 + 檢查 PodDisruptionBudgets 是否阻止節點終止 **非預期的節點終止：** + 檢閱 `expireAfter`和 `terminationGracePeriod`設定 + 檢查手動節點終止或 AWS 維護事件 ## 範例 ### 基本靜態容量節點集區 ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: basic-static spec: replicas: 5 template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["m"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-west-2a"] limits: nodes: 8 # Allow scaling up to 8 during operations ``` ### 具有特定執行個體類型的靜態容量 ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: reserved-instances spec: replicas: 20 template: metadata: labels: instance-type: reserved cost-center: production spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "node.kubernetes.io/instance-type" operator: In values: ["m5.2xlarge"] # Specific instance type - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-west-2a", "us-west-2b", "us-west-2c"] limits: nodes: 25 disruption: # Conservative disruption for production workloads budgets: - nodes: 10% ``` ### 多區域靜態容量節點集區 ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: multi-zone-static spec: replicas: 12 # Will be distributed across specified zones template: metadata: labels: availability: high spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m"] - key: "eks.amazonaws.com/instance-cpu" operator: In values: ["8", "16"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-west-2a", "us-west-2b", "us-west-2c"] - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] limits: nodes: 15 disruption: budgets: - nodes: 25% ``` ### 具有容量保留的靜態容量 下列範例示範如何搭配 EC2 容量保留使用靜態容量節點集區。如需搭配 EKS Auto 模式使用 EC2 容量預留的詳細資訊，請參閱 [使用 EKS 自動模式控制工作負載部署至容量保留](auto-odcr.md)。 `NodeClass` 定義 `capacityReservationSelectorTerms` ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: capacity-reservation-nodeclass spec: role: AmazonEKSNodeRole securityGroupSelectorTerms: - id: sg-0123456789abcdef0 subnetSelectorTerms: - id: subnet-0123456789abcdef0 capacityReservationSelectorTerms: - id: cr-0123456789abcdef0 ``` `NodePool` 使用 參考上述 `NodeClass`和 `karpenter.sh/capacity-type: reserved`。 ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: static-capacity-reservation-nodepool spec: replicas: 5 limits: nodes: 8 # Allow scaling up to 8 during operations template: metadata: {} spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: capacity-reservation-nodeclass requirements: - key: karpenter.sh/capacity-type operator: In values: ['reserved'] ``` # 建立 IngressClass 以設定 Application Load Balancer EKS 自動模式會自動執行負載平衡的常規任務，包括將叢集應用程式公開至網際網路。 AWS 建議使用 Application Load Balancer (ALB) 來提供 HTTP 和 HTTPS 流量。Application Load Balancer 可根據請求的內容路由請求。如需 Application Load Balancer 的詳細資訊，請參閱[什麼是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) EKS 自動模式會建立與設定 Application Load Balancer (ALB)。例如，當您建立一個 `Ingress` Kubernetes 物件時，EKS 自動模式會建立一個負載平衡器，並將其設定為將流量路由至叢集工作負載。 **概觀** 1. 建立您想要公開到網際網路的工作負載。 1. 建立 `IngressClassParams` 資源，指定 AWS 特定組態值，例如用於 SSL/TLS 和 VPC 子網路的憑證。 1. 建立 `IngressClass` 資源，指定 EKS 自動模式將作為該資源的控制器。 1. 建立 `Ingress` 資源，將 HTTP 路徑和連接埠與叢集工作負載關聯起來。 EKS 自動模式將建立 Application Load Balancer，指向 `Ingress` 資源中指定的工作負載，並使用在 `IngressClassParams` 資源中指定的負載平衡器配置。 ## 先決條件 + Amazon EKS 叢集上已啟用 EKS 自動模式 + Kubectl 已設定為連接到您的叢集 + 您可使用 `kubectl apply -f `，將以下範例組態 YAML 檔案套用至您的叢集。 **注意** EKS 自動模式需要子網路標籤來識別公有和私有子網路。 若您使用 `eksctl` 建立叢集，則您已具備這些標籤。 了解如何 [標記 EKS 自動模式的子網路](tag-subnets-auto.md)。 ## 步驟 1：建立工作負載 首先，建立您想要公開到網際網路的工作負載。此工作負載可為任何處理 HTTP 流量的 Kubernetes 資源，例如部署或服務。 此範例使用名為 `service-2048` 的簡單 HTTP 服務，其接聽連接埠 `80`。透過套用下列資訊清單 `2048-deployment-service.yaml`，建立此服務及其部署： ``` --- apiVersion: apps/v1 kind: Deployment metadata: name: deployment-2048 spec: selector: matchLabels: app.kubernetes.io/name: app-2048 replicas: 2 template: metadata: labels: app.kubernetes.io/name: app-2048 spec: containers: - image: public.ecr.aws/l6m2t8p7/docker-2048:latest imagePullPolicy: Always name: app-2048 ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: service-2048 spec: ports: - port: 80 targetPort: 80 protocol: TCP type: NodePort selector: app.kubernetes.io/name: app-2048 ``` 將組態套用至您的叢集： ``` kubectl apply -f 2048-deployment-service.yaml ``` 上面列出的資源將在預設命名空間中建立。您可以透過執行以下命令來進行確認： ``` kubectl get all -n default ``` ## 步驟 2：建立 IngressClassParams 建立 `IngressClassParams` 物件以指定 Application Load Balancer AWS 的特定組態選項。在本範例中，我們在名為 `alb-ingressclassparams.yaml` 的檔案中，建立名為 `alb` 的 `IngressClassParams` 資源 (您將在下一步中使用)，並指定負載平衡器方案為 `internet-facing`。 ``` apiVersion: eks.amazonaws.com/v1 kind: IngressClassParams metadata: name: alb spec: scheme: internet-facing ``` 將組態套用至您的叢集： ``` kubectl apply -f alb-ingressclassparams.yaml ``` ## 步驟 3：建立 IngressClass 建立 `IngressClass`，參考名為 的檔案中`IngressClassParams`資源中設定 AWS 的特定組態值`alb-ingressclass.yaml`。請記下 `IngressClass` 的名稱。在此範例中，`IngressClass` 和 `IngressClassParams` 都命名為 `alb`。 使用 `is-default-class` 註釋來控制 `Ingress` 資源是否預設使用此類別。 ``` apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: alb annotations: # Use this annotation to set an IngressClass as Default # If an Ingress doesn't specify a class, it will use the Default ingressclass.kubernetes.io/is-default-class: "true" spec: # Configures the IngressClass to use EKS Auto Mode controller: eks.amazonaws.com/alb parameters: apiGroup: eks.amazonaws.com kind: IngressClassParams # Use the name of the IngressClassParams set in the previous step name: alb ``` 關於設定選項的詳細資訊，請參閱 [IngressClassParams 參考](#ingress-reference)。 將組態套用至您的叢集： ``` kubectl apply -f alb-ingressclass.yaml ``` ## 步驟 4：建立傳入 在名為 `alb-ingress.yaml` 的檔案中建立 `Ingress` 資源。此資源的用途是將 Application Load Balancer 上的路徑與連接埠，與您叢集中的工作負載相關聯。在此範例中，我們建立名為 `Ingress` 的資源 `2048-ingress`，將其流量路由到連接埠 80 上名為 `service-2048` 的服務。 如需關於設定資源的詳細資訊，請參閱 Kubernetes 文件中的[傳入](https://kubernetes.io/docs/concepts/services-networking/ingress/)。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: 2048-ingress spec: # this matches the name of IngressClass. # this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation ingressClassName: alb rules: - http: paths: - path: /* pathType: ImplementationSpecific backend: service: name: service-2048 port: number: 80 ``` 將組態套用至您的叢集： ``` kubectl apply -f alb-ingress.yaml ``` ## 步驟 5：檢查狀態 使用 `kubectl` 尋找 `Ingress` 的狀態。負載平衡器可能需要幾分鐘才能就緒。 使用您在上一步中設定的 `Ingress` 資源名稱。例如： ``` kubectl get ingress 2048-ingress ``` 資源就緒後，擷取負載平衡器的網域名稱。 ``` kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' ``` 要在 Web 瀏覽器中檢視服務，請檢閱 `Ingress` 救援中指定的連接埠與路徑。 ## 步驟 6：清除 要清理負載平衡器，請使用以下命令： ``` kubectl delete ingress 2048-ingress kubectl delete ingressclass alb kubectl delete ingressclassparams alb ``` EKS Auto Mode 會自動刪除您 AWS 帳戶中相關聯的負載平衡器。 ## IngressClassParams 參考 下表屬於常用組態選項的快速參考。 | 欄位 | Description | 範例值 | | --- | --- | --- | | `scheme` | 定義 ALB 是內部，還是可面向網際網路 | `internet-facing` | | `namespaceSelector` | 限制哪些命名空間可使用此 IngressClass | `environment: prod` | | `group.name` | 將多個傳入分組，以共用單一 ALB | `retail-apps` | | `ipAddressType` | 設定 ALB 的 IP 位址類型 | `dualstack` | | `subnets.ids` | 用於 ALB 部署的子網路 ID 清單 | `subnet-xxxx, subnet-yyyy` | | `subnets.tags` | 用於選擇 ALB 子網路的標籤篩選器 | `Environment: prod` | | `certificateARNs` | 要使用的 SSL 憑證 ARN | ` arn:aws: acm:region:account:certificate/id` | | `tags` | AWS 資源的自訂標籤 | `Environment: prod, Team: platform` | | `loadBalancerAttributes` | 負載平衡器特定屬性 | `idle_timeout.timeout_seconds: 60` | ## 考量事項 + 您無法使用 IngressClass 上的註釋來設定 EKS 自動模式的負載平衡器。IngressClass 組態應該透過 IngressClassParams 完成。不過，您可以在個別輸入資源上使用註釋來設定負載平衡器行為 （例如 `alb.ingress.kubernetes.io/security-group-prefix-lists`或 `alb.ingress.kubernetes.io/conditions.*`)。 + 您無法使用 EKS 自動模式來設定 [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)。 + 您必須更新叢集 IAM 角色，才能啟用從 Kubernetes 到 AWS Load Balancer資源的標籤傳播。如需詳細資訊，請參閱[EKS Auto 資源的自訂 AWS 標籤](auto-cluster-iam-role.md#tag-prop)。 + 如需將資源與 EKS Auto Mode 或 self-managed AWS Load Balancer Controller 建立關聯的資訊，請參閱 [移轉參考](migrate-auto.md#migration-reference)。 + 有關修復負載平衡器問題的資訊，請參閱 [EKS 自動模式疑難排解](auto-troubleshoot.md)。 + 有關使用 EKS 自動模式負載平衡功能的更多考量，請參閱 [Load balancing](auto-networking.md#auto-lb-consider)。 以下表格詳細比較了 EKS 自動模式中 IngressClassParams、傳入註釋和 TargetGroupBinding 組態的變更。這些資料表突顯了 EKS 自動模式的負載平衡功能與開放原始碼負載平衡器控制器之間的主要差異，包括 API 版本變更、已棄用的功能及更新的參數名稱。 ### IngressClassParams | 先前的 | 新增 | Description | | --- | --- | --- | | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 版本變更 | | `spec.certificateArn` | `spec.certificateARNs` | 支援多個憑證 ARN | | `spec.subnets.tags` | `spec.subnets.matchTags` | 變更子網路相符的結構描述 | | `spec.listeners.listenerAttributes` | 不支援 | EKS 自動模式尚不支援 | ### 傳入註釋 | 先前的 | 新增 | Description | | --- | --- | --- | | `kubernetes.io/ingress.class` | 不支援 | 在傳入物件上使用 `spec.ingressClassName` | | `alb.ingress.kubernetes.io/group.name` | 不支援 | 僅在 IngressClass 中指定群組 | | `alb.ingress.kubernetes.io/waf-acl-id` | 不支援 | 請改用 WAF v2 | | `alb.ingress.kubernetes.io/web-acl-id` | 不支援 | 請改用 WAF v2 | | `alb.ingress.kubernetes.io/shield-advanced-protection` | 不支援 | Shield 整合已停用 | | `alb.ingress.kubernetes.io/auth-type: oidc` | 不支援 | 目前不支援 OIDC 驗證類型 | ### TargetGroupBinding | 先前的 | 新增 | Description | | --- | --- | --- | | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 版本變更 | | `spec.targetType` 選用 | `spec.targetType` 必要 | 明確的目標類型規格 | | `spec.networking.ingress.from` | 不支援 | 不再支援沒有安全群組的 NLB | 若要使用自訂 TargetGroupBinding 功能，您必須使用叢集名稱的 eks：eks-cluster-name 標籤來標記目標群組，以授予控制器必要的 IAM 許可。請注意，刪除 TargetGroupBinding 資源或叢集時，控制器會刪除目標群組。 # 使用服務注釋設定 Network Load Balancer 了解如何使用 Kubernetes 服務註釋，在 Amazon EKS 中設定 Network Load Balancer (NLB)。本主題解釋了 EKS 自動模式支援用於自訂 NLB 行為的註釋，包括網際網路可存取性、運作狀態檢查、SSL/TLS 終止及 IP 目標模式。 當您在 EKS Auto Mode `LoadBalancer`中建立 類型的 Kubernetes 服務時，EKS 會根據您指定的註釋自動佈建和設定 AWS Network Load Balancer。這種宣告式方法允許您直接透過 Kubernetes 資訊清單來管理負載平衡器組態，維持基礎結構即程式碼的實踐。 EKS 自動模式預設為處理所有 LoadBalancer 類型服務的 Network Load Balancer 佈建 - 無需安裝或設定額外的控制器。`loadBalancerClass: eks.amazonaws.com/nlb` 規格被自動設定為叢集預設值，簡化了部署程序，同時保持了與現有 Kubernetes 工作負載的相容性。 **注意** EKS 自動模式需要子網路標籤來識別公有和私有子網路。 若您使用 `eksctl` 建立叢集，則您已具備這些標籤。 了解如何 [標記 EKS 自動模式的子網路](tag-subnets-auto.md)。 ## 範例服務 如需有關 Kubernetes `Service` 資源的詳細資訊，請參閱 [Kubernetes 文件中](https://kubernetes.io/docs/concepts/services-networking/service/)。 請檢閱下面的範例 `Service` 資源： ``` apiVersion: v1 kind: Service metadata: name: echoserver annotations: # Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB) service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing spec: selector: app: echoserver ports: - port: 80 targetPort: 8080 protocol: TCP type: LoadBalancer # Specify the new load balancer class for NLB as part of EKS Auto Mode feature # For clusters with Auto Mode enabled, this field can be omitted as it's the default loadBalancerClass: eks.amazonaws.com/nlb ``` ## 常用註釋 下表列出 EKS 自動模式支援的常用註釋。請注意，EKS 自動模式可能不支援所有註釋。 **提示** 下列所有註釋都需要加上字首 `service.beta.kubernetes.io/` | 欄位 | Description | 範例 | | --- | --- | --- | | `aws-load-balancer-type` | 指定負載平衡器類型。將 `external` 用於新的部署。 | `external` | | `aws-load-balancer-nlb-target-type` | 指定是將流量路由到節點執行個體，還是直接路由到 Pod IP。將 `instance` 用於標準部署，或將 `ip` 用於直接 Pod 路由。 | `instance` | | `aws-load-balancer-scheme` | 控制負載平衡器是內部或是面向網際網路。 | `internet-facing` | | `aws-load-balancer-healthcheck-protocol` | 目標群組的運作狀態檢查通訊協定。常見選項是 `TCP` (預設) 或 `HTTP`。 | `HTTP` | | `aws-load-balancer-healthcheck-path` | 使用 HTTP/HTTPS 通訊協定時，用於運作狀態檢查的 HTTP 路徑。 | `/healthz` | | `aws-load-balancer-healthcheck-port` | 用於運作狀態檢查的連接埠。可以是特定連接埠號碼或 `traffic-port`。 | `traffic-port` | | `aws-load-balancer-subnets` | 指定要在哪些子網路中建立負載平衡器。可使用子網路 ID 或名稱。 | `subnet-xxxx, subnet-yyyy` | | `aws-load-balancer-ssl-cert` | 來自 AWS Certificate Manager for HTTPS/TLS 的 SSL 憑證 ARN。 | ` arn:aws: acm:region:account:certificate/cert-id` | | `aws-load-balancer-ssl-ports` | 指定哪些連接埠應使用 SSL/TLS。 | `443, 8443` | | `load-balancer-source-ranges` | 允許存取負載平衡器的 CIDR 範圍。 | `10.0.0.0/24, 192.168.1.0/24` | | `aws-load-balancer-additional-resource-tags` | 要套用至負載平衡器和相關資源的其他 AWS 標籤。 | `Environment=prod,Team=platform` | | `aws-load-balancer-ip-address-type` | 指定負載平衡器是使用 IPv4，還是雙堆疊 (IPv4 \$1 IPv6)。 | `ipv4` 或 `dualstack` | ## 考量事項 + 您必須更新叢集 IAM 角色，才能啟用從 Kubernetes 到 AWS Load Balancer資源的標籤傳播。如需詳細資訊，請參閱[EKS Auto 資源的自訂 AWS 標籤](auto-cluster-iam-role.md#tag-prop)。 + 如需將資源與 EKS Auto Mode 或 self-managed AWS Load Balancer Controller 建立關聯的資訊，請參閱 [移轉參考](migrate-auto.md#migration-reference)。 + 有關修復負載平衡器問題的資訊，請參閱 [EKS 自動模式疑難排解](auto-troubleshoot.md)。 + 有關使用 EKS 自動模式負載平衡功能的更多考量，請參閱 [Load balancing](auto-networking.md#auto-lb-consider)。 當移轉至 EKS 自動模式進行負載平衡時，服務註釋與資源組態中需要進行多項變更。以下表格概述了先前與新實作之間的關鍵差異，包括不支援的選項和推薦的替代方案。 ### 服務註釋 | 先前的 | 新增 | Description | | --- | --- | --- | | `service.beta.kubernetes.io/load-balancer-source-ranges` | 不支援 | 在服務上使用 `spec.loadBalancerSourceRanges` | | `service.beta.kubernetes.io/aws-load-balancer-type` | 不支援 | 在服務上使用 `spec.loadBalancerClass` | | `service.beta.kubernetes.io/aws-load-balancer-internal` | 不支援 | 使用 `service.beta.kubernetes.io/aws-load-balancer-scheme` | | `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | 不支援 | 改用 `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` | | 各種負載平衡器屬性 | 不支援 | 使用 `service.beta.kubernetes.io/aws-load-balancer-attributes` | | `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | 不支援 | 改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` | | `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | 不支援 | 改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` | | `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | 不支援 | 改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` | | `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | 不支援 | 改用 `service.beta.kubernetes.io/aws-load-balancer-attributes` | 要從已棄用的負載平衡器屬性註釋移轉，請將這些設定合併至 `service.beta.kubernetes.io/aws-load-balancer-attributes` 註釋中。此註釋接受逗號分隔的鍵值對清單，用於各種負載平衡器屬性。例如，若要指定存取記錄和跨區域負載平衡，請使用下列格式： ``` service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true ``` 這種合併格式提供了一種更一致、更靈活的方式來設定負載平衡器屬性，同時減少了所需單獨注釋的數量。請檢閱您現有的服務組態，並將其更新為使用此合併格式。 ### TargetGroupBinding | 先前的 | 新增 | Description | | --- | --- | --- | | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 版本變更 | | `spec.targetType` 選用 | `spec.targetType` 必要 | 明確的目標類型規格 | | `spec.networking.ingress.from` | 不支援 | 不再支援沒有安全群組的 NLB | 注意：若要使用自訂 TargetGroupBinding 功能，您必須使用叢集名稱的`eks:eks-cluster-name`標籤來標記目標群組，以授予控制器必要的 IAM 許可。請注意，刪除 TargetGroupBinding 資源或叢集時，控制器會刪除目標群組。 # 建立儲存類別 在 Amazon EKS 自動模式中，`StorageClass` 定義了當應用程式請求持久性儲存時，如何自動佈建 Amazon EBS 磁碟區。本頁面闡釋了如何建立和設定與 Amazon EKS 自動模式協同工作的 `StorageClass`，以佈建 EBS 磁碟區。 透過設定 `StorageClass`，您可為 EBS 磁碟區指定預設設定，包括磁碟區類型、加密、IOPS 和其他儲存參數。您也可以`StorageClass`將 設定為使用 AWS KMS 金鑰進行加密管理。 EKS 自動模式不會為您建立 `StorageClass`。您必須建立 `StorageClass` 參考 `ebs.csi.eks.amazonaws.com`，以使用 EKS 自動模式的儲存功能。 首先，建立名為 `storage-class.yaml` 的檔案： ``` apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: auto-ebs-sc annotations: storageclass.kubernetes.io/is-default-class: "true" allowedTopologies: - matchLabelExpressions: - key: eks.amazonaws.com/compute-type values: - auto provisioner: ebs.csi.eks.amazonaws.com volumeBindingMode: WaitForFirstConsumer parameters: type: gp3 encrypted: "true" ``` 接著，將儲存體方案套用至您的叢集。 ``` kubectl apply -f storage-class.yaml ``` **關鍵元件：** + `provisioner: ebs.csi.eks.amazonaws.com` - 使用 EKS 自動模式 + `allowedTopologies` - 指定 `eks.amazonaws.com/compute-type:auto` 來匹配 `matchLabelExpressions`，將確保如果您的 Pod 需要使用自動模式自動佈建磁碟區，則這些 Pod 不會被排程到非自動節點上。 + `volumeBindingMode: WaitForFirstConsumer` - 延遲建立磁碟區，直至 Pod 需要磁碟區 + `type: gp3` - 指定 EBS 磁碟區類型 + `encrypted: "true"` - EBS 將加密使用此 `StorageClass` 建立的所有磁碟區。EBS 將使用預設的 `aws/ebs` 金鑰別名。如需詳細資訊，請參閱《Amazon EBS 使用者指南》中的 [Amazon EBS 加密運作方式](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html)。此值可選用的，但建議設定。 + `storageclass.kubernetes.io/is-default-class: "true"` - 依預設，Kubernetes 將使用此儲存類別，除非您在持續性磁碟區宣告上指定了不同的磁碟區類別。此值是選用的。若要從其他儲存控制器移轉，則在設定該值時要謹慎對待。 ## 使用自我管理的 KMS 金鑰加密 EBS 磁碟區 要使用自我管理的 KMS 金鑰來加密由 EKS 自動模式自動佈建的 EBS 磁碟區，您需要： 1. 建立自我管理的 KMS 金鑰。 + 如需詳細資訊，請參閱《KMS 使用者指南》中的[建立對稱加密 KMS 金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html)或 [Amazon Elastic Block Store (Amazon EBS) 如何使用 KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html)。 1. 建立一個允許存取 KMS 金鑰的新政策。 + 使用下面的範例 IAM 政策來建立該政策。插入新的自我管理 KMS 金鑰的 ARN。如需詳細資訊，請參閱《IAM 使用者指南》中的[建立角色和連接政策 （主控台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)。 AWS 1. 將政策附加到 EKS 叢集角色。 + 使用 AWS 主控台尋找 EKS 叢集角色的 ARN。角色資訊在**概覽**區段中可見。如需詳細資訊，請參閱[Amazon EKS 叢集 IAM 角色](cluster-iam-role.md)。 1. 更新 `StorageClass`，以參考 `parameters.kmsKeyId` 欄位的 KMS 金鑰 ID。 ### 自我管理 KMS IAM 政策範例 更新下方政策中的以下值： + `` – AWS 您的帳戶 ID，例如 `111122223333` + `` – 叢集 AWS 的區域，例如 `us-west-2` ``` { "Version":"2012-10-17", "Id": "key-auto-policy-3", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:CreateGrant", "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "kms:CallerAccount": "123456789012", "kms:ViaService": "ec2.us-east-1.amazonaws.com" } } } ] } ``` ### 自我管理的 KMS `StorageClass` 範例 ``` parameters: type: gp3 encrypted: "true" kmsKeyId: ``` ## `StorageClass` 參數參考 有關 Kubernetes `StorageClass` 資源的一般資訊，請參閱 Kubernetes 文件中的[儲存類別](https://kubernetes.io/docs/concepts/storage/storage-classes/)。 `StorageClass` 資源的 THe `parameters`區段是特定的 AWS。請使用下列資料表檢閱可用的選項。 | Parameters | 值 | 預設 | Description | | --- | --- | --- | --- | | "csi.storage.k8s.io/fstype" | xfs、ext2、ext3、ext4 | ext4 | 在磁碟區建立期間將被格式化的檔案系統類型。此參數有大小寫之分！ | | "type" | io1、io2、gp2、gp3、sc1、st1、Standard、sbp1、sbg1 | gp3 | EBS 磁碟區類型。 | | "iopsPerGB" | | | 每 GiB 的每秒 I/O 操作次數。可為 IO1、IO2 和 GP3 磁碟區指定。 | | "allowAutoIOPSPerGBIncrease" | true、false | false | 當 時`"true"`，當 `iopsPerGB * ` 太低而無法符合 支援的 IOPS 範圍時，CSI 驅動程式會增加磁碟區的 IOPS AWS。這可讓動態佈建總是成功，即使使用者指定的 PVC 容量或 `iopsPerGB` 值太小。另一方面，這可能會帶來額外成本，因為此類磁碟區的 IOPS 比 `iopsPerGB` 中請求的要高。 | | "iops" | | | 每秒 I/O 操作。可為 IO1、IO2 和 GP3 磁碟區指定。 | | "throughput" | | 125 | 輸送量以 MiB/秒為單位。僅在指定了 gp3 磁碟區類型時有效。 | | "encrypted" | true、false | false | 指示是否加密磁碟區。有效值為 "true" 或 "false"。 | | "blockExpress" | true、false | false | 啟用 io2 Block Express 磁碟區的建立。 | | "kmsKeyId" | | | 加密磁碟區時要使用的金鑰的完整 ARN。如果未指定， AWS 將針對磁碟區所在的區域使用預設 KMS 金鑰。如果未變更，這將是一個自動產生的金鑰，稱為 `/aws/ebs`。 | | "blockSize" | | | 格式化底層檔案系統時使用的區塊大小。僅在 Linux 節點上並使用 `ext2`、`ext3`、`ext4` 或 `xfs` 時支援。 | | "inodeSize" | | | 格式化底層檔案系統時使用的 inode 大小。僅在 Linux 節點上並使用 `ext2`、`ext3`、`ext4` 或 `xfs` 時支援。 | | "bytesPerInode" | | | 格式化底層檔案系統時使用的 `bytes-per-inode`。僅在 Linux 節點上並使用 `ext2`、`ext3`、`ext4` 時支援。 | | "numberOfInodes" | | | 格式化底層檔案系統時使用的 `number-of-inodes`。僅在 Linux 節點上並使用 `ext2`、`ext3`、`ext4` 時支援。 | | "ext4BigAlloc" | true、false | false | 透過啟用 `bigalloc` 格式化選項，將 `ext4` 檔案系統變更為使用叢集區塊配置。警告：您的節點 Linux 核心可能不完全支援 `bigalloc`。 | | "ext4ClusterSize" | | | 當啟用 `bigalloc` 功能時，格式化 `ext4` 檔案系統所使用的叢集大小。請注意：`ext4BigAlloc` 參數必須設為 true。 | 如需詳細資訊，請參閱 GitHub 上的 [AWS EBS CSI 驅動程式](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md)。 ## 考量事項 **注意** 您只能在 EKS 自動模式節點上，部署依賴於 EKS 自動模式 StorageClass 的工作負載。如果您有一個混合類型節點的叢集，需要設定您的工作負載僅在 EKS 自動模式節點上執行。如需詳細資訊，請參閱[控制工作負載是否部署在 EKS 自動模式節點上](associate-workload.md)。 EKS 自動模式的區塊儲存功能與 EBS CSI 驅動程式不同。 + 靜態佈建 + 如果您想要搭配 EKS Auto 模式使用外部建立的 EBS 磁碟區，則需要手動新增具有 金鑰`eks:eks-cluster-name`和叢集名稱值的 AWS 標籤。 + 節點啟動污點 + 您無法使用節點啟動污點功能，以在儲存功能準備就緒之前防止 Pod 排程 + 動態佈建磁碟區上的自訂標籤 + 您無法使用 extra-tag CLI 標誌來設定動態佈建 EBS 磁碟區上的自訂標籤 + 您可使用 `StorageClass` 標記來新增自訂標籤。EKS Auto Mode 會將標籤新增至相關聯的 AWS 資源。您需要更新叢集 IAM 角色以用於自訂標籤。如需詳細資訊，請參閱[EKS Auto 資源的自訂 AWS 標籤](auto-cluster-iam-role.md#tag-prop)。 + EBS 詳細效能指標 + 您無法存取 EBS 詳細效能的 Prometheus 指標 ## 安裝 CSI 快照控制器附加元件 EKS 自動模式與 CSI 快照控制器 Amazon EKS 附加元件相容。 AWS 建議您將此附加元件設定為在內建`system`節點集區上執行。 如需詳細資訊，請參閱： + [在專用執行個體上執行關鍵附加元件](critical-workload.md) + [啟用或停用內建的 NodePool](set-builtin-node-pools.md) + [啟用 CSI 磁碟區的快照功能](csi-snapshot-controller.md) ### 在系統節點集區中安裝快照控制器 1. 在 AWS 主控台中開啟您的 EKS 叢集 1. 從**附加元件**索引標籤中，選取**取得更多附加元件** 1. 選取 **CSI 快照控制器**，然後選擇**下一步** 1. 在**設定選取的附加元件設定**頁面上，選取**選用組態設定**，以檢視**附加元件組態結構描述** 1. 插入以下 yaml 以將快照控制器與 `system` 節點集區關聯。快照控制器包含對 `CriticalAddonsOnly` 污點的容錯。 ``` { "nodeSelector": { "karpenter.sh/nodepool": "system" } } ``` 1. 選取**下一步** 1. 檢閱附加元件組態，然後選取**建立** # 停用 EKS 自動模式 您可以在現有的 EKS 叢集上停用 EKS 自動模式。這是破壞性的操作。 + EKS 將終止由 EKS 自動模式操作的所有 EC2 執行個體。 + EKS 將刪除由 EKS 自動模式操作的所有負載平衡器。 + EKS **不會**刪除由 EKS 自動模式佈建的 EBS 磁碟區。 EKS 自動模式旨在完整管理其所建立的資源。手動介入可能導致 EKS 自動模式在停用時無法完全清除這些資源。例如，如果您從外部安全群組規則中參照了受管安全群組，並且在為叢集停用 EKS Auto Mode 之前忘記移除該參照，則受管安全群組將洩漏 (不會被刪除)。以下步驟說明若發生此情形，如何移除遺漏的安全群組。 ## 停用 EKS 自動模式AWS （主控台） 1. 在 AWS 管理主控台中開啟您的叢集概觀頁面。 1. 在 **EKS 自動模式**下，選取**管理** 1. 將 **EKS 自動模式**切換為 `off`。 如果在此程序結束時有任何受管安全群組未被刪除，您可使用[刪除安全群組](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html)中的說明手動將其刪除。 ## 停用 EKS 自動模式 (AWS CLI) 使用以下命令在現有叢集上停用 EKS 自動模式。 您需要安裝 `aws` CLI，並使用足夠的許可來登入以管理 EKS 叢集。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。 **注意** 運算、區塊儲存和負載平衡功能必須在同一請求中全部啟用或停用。 ``` aws eks update-cluster-config \ --name $CLUSTER_NAME \ --compute-config enabled=false \ --kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \ --storage-config '{"blockStorage":{"enabled": false}}' ``` 您可按照以下方式檢查在停用 EKS 自動模式後，是否有遺漏的 EKS 自動模式安全群組未能被刪除： ``` aws ec2 describe-security-groups \ --filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]" ``` 然後刪除安全群組： ``` aws ec2 delete-security-group --group-name= ``` # 更新 EKS 自動模式叢集的 Kubernetes 版本 本主題闡釋如何更新自動模式叢集的 Kubernetes 版本。自動模式透過處理控制平面更新與節點取代的協調來簡化版本更新程序，同時透過 Pod 中斷預算維持工作負載可用性。 升級自動模式叢集時，許多傳統上需要手動更新的元件現在作為服務的一部分進行管理。了解升級程序的自動化層面與您的責任，有助於確保叢集的版本順利轉換。 ## 了解 EKS 自動模式的更新 在您啟動控制平面升級後，EKS 自動模式會升級叢集中的節點。當節點到期時，EKS 自動模式會用新節點取代。新節點具有相應的新 Kubernetes 版本。升級節點時，EKS 自動模式會遵守 Pod 中斷預算。 此外，您不再需要更新下列元件： + Amazon VPC CNI + AWS Load Balancer 控制器 + CoreDNS + `kube-proxy` + Karpenter + AWS EBS CSI 驅動程式 EKS 自動模式會以服務功能取代這些元件。 您仍然負責更新： + 部署到您的叢集的應用程式與工作負載 + 自我管理的附加元件與控制器 + Amazon EKS 附加元件 + 了解如何 [更新 Amazon EKS 附加元件](updating-an-add-on.md) 了解[叢集升級的最佳實務](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) ## 啟動叢集更新 要開始叢集更新，請參閱 [將現有叢集更新至全新 Kubernetes 版本](update-cluster.md)。 # 啟用或停用內建的 NodePool EKS 自動模式具有兩個內建的 NodePool。您可以使用 AWS 主控台、CLI 或 API 啟用或停用這些 NodePools。 ## 內建的 NodePool 參考 + `system` + 此 NodePool 具有 `CriticalAddonsOnly` 污點。CoreDNS 等眾多 EKS 附加元件皆可容忍此污點。藉助此系統節點集區，來分隔叢集關鍵型應用程式。 + 支援 `amd64` 與 `arm64` 架構。 + `general-purpose` + 針對叢集中的一般用途工作負載，此 NodePool 提供啟動節點相關支援。 + 只能使用 `amd64` 架構。 兩個內建的 NodePool： + 使用預設的 EKS NodeClass + 只能使用隨需 EC2 容量 + 使用 C、M 及 R EC2 執行個體系列 + 要求使用第 5 代或更新版本的 EC2 執行個體 **注意** EKS 需要啟用至少一個內建的 NodePool，才能佈建「預設」NodeClass。若停用全部內建的 NodePool，需要建立自訂 NodeClass 及設定 NodePool 才能使用。若要了解 NodeClass 的相關資訊，請參閱 [建立 Amazon EKS 的節點類別](create-node-class.md)。 ## 程序 ### 先決條件 + 在您裝置上安裝和設定的最新版本 AWS 命令列界面 (AWS CLI)。若要檢查您目前的版本，請使用 `aws --version`。若要安裝最新版本，請參閱《 AWS 命令列界面使用者指南》中的使用 aws 設定[安裝](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 和[快速組態](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)。 + 使用足夠的 IAM 許可登入 CLI，以建立 AWS 資源，包括 IAM 政策、IAM 角色和 EKS 叢集。 ### 使用 CLI AWS 啟用 使用以下命令，啟用兩個內建的 NodePool： ``` aws eks update-cluster-config \ --name \ --compute-config '{ "nodeRoleArn": "", "nodePools": ["general-purpose", "system"], "enabled": true }' \ --kubernetes-network-config '{ "elasticLoadBalancing":{"enabled": true} }' \ --storage-config '{ "blockStorage":{"enabled": true} }' ``` 您可修改命令，選擇性地啟用 NodePools。 ### 使用 AWS CLI 停用 使用以下命令，停用兩個內建的 NodePool： ``` aws eks update-cluster-config \ --name \ --compute-config '{ "enabled": true, "nodePools": [] }' \ --kubernetes-network-config '{ "elasticLoadBalancing":{"enabled": true}}' \ --storage-config '{ "blockStorage":{"enabled": true} }' ``` # 控制工作負載是否部署在 EKS 自動模式節點上 在包含 EKS 自動模式的 EKS 叢集中執行工作負載時，您可能需要控制特定工作負載是否應在 EKS 自動模式節點，還是其他運算類型上執行。本主題描述如何使用節點選擇器與親和性，以確保您的工作負載被排程到預期的運算基礎結構上。 本主題中的範例示範如何使用 `eks.amazonaws.com/compute-type` 標籤，以要求或阻止工作負載部署到 EKS 自動模式節點上。這在混合模式叢集中特別有用，例如您同時執行了 EKS 自動模式和其他運算類型 (例如自我管理的 Karpenter 佈建程式或 EKS 受管節點群組) 的環境。 EKS 自動模式節點已將標籤 `eks.amazonaws.com/compute-type` 的值設定為 `auto`。您可使用此標籤來控制工作負載是否要部署到由 EKS 自動模式管理的節點。 ## 要求工作負載部署至 EKS 自動模式節點 **注意** 此 `nodeSelector` 值對於 EKS 自動模式並非必要。此 `nodeSelector` 僅在您於混合模式中執行叢集時 (即叢集中包含非 EKS 自動模式管理的節點類型時) 才相關。例如，您可能已透過 EKS 受管節點群組將靜態運算容量部署到叢集中，同時也擁有由 EKS 自動模式管理的動態運算容量。 您可將此 `nodeSelector` 新增至部署或其他工作負載中，以要求 Kubernetes 將其排程到 EKS 自動模式節點上。 ``` apiVersion: apps/v1 kind: Deployment spec: template: nodeSelector: eks.amazonaws.com/compute-type: auto ``` ## 要求工作負載不部署至 EKS 自動模式節點 您可將此 `nodeAffinity` 新增至部署或其他工作負載中，以要求 Kubernetes **不要**將其排程到 EKS 自動模式節點上。 ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - auto ``` # 在專用執行個體上執行關鍵附加元件 在本主題中，您將了解如何部署具有 `CriticalAddonsOnly` 容差的工作負載，以便 EKS 自動模式將其排程到 `system` 節點集區上。 EKS 自動模式的內建 `system` 節點集區專為在專用執行個體上執行關鍵附加元件而設計。這種隔離確保了關鍵元件擁有專用資源，並與一般工作負載隔離開，從而提升了叢集的整體穩定性與效能。 本指南示範如何透過使用 `CriticalAddonsOnly` 容差和適當的節點選擇器，將附加元件部署到 `system` 節點集區。遵循這些步驟，您可以確保您的關鍵應用程式被排程到專用的 `system` 節點上，充分利用 EKS 自動模式的專用節點集區結構所帶來的隔離與資源分配優勢。 EKS 自動模式有兩個內建節點集區：`general-purpose` 和 `system`。如需詳細資訊，請參閱 [啟用或停用內建的 NodePool](set-builtin-node-pools.md)。 `system` 節點集區的用途是將關鍵附加元件隔離到不同的節點上。節點集區佈建的 `system` 節點帶有 `CriticalAddonsOnly` Kubernetes 污點。Kubernetes 只會將具有相應容差的 Pod 排程到這些節點上。如需詳細資訊，請參閱 Kubernetes 文件中的[污點和容差](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)。 ## 先決條件 + 已啟用內建 `system` 節點集區的 EKS 自動模式叢集。如需詳細資訊，請參閱[啟用或停用內建的 NodePool](set-builtin-node-pools.md) + `kubectl` 已安裝並已設定。如需詳細資訊，請參閱 [設定以使用 Amazon EKS](setting-up.md)。 ## 程序 請檢閱以下的範例 yaml。記下下列組態： + `nodeSelector`：這會將工作負載與內建的 `system` 節點集區建立關聯。此節點集區必須透過 AWS API 啟用。如需詳細資訊，請參閱 [啟用或停用內建的 NodePool](set-builtin-node-pools.md)。 + `tolerations`：此容差用於克服 `system` 節點集區中節點上的 `CriticalAddonsOnly` 污點。 ``` apiVersion: apps/v1 kind: Deployment metadata: name: sample-app spec: replicas: 3 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: nodeSelector: karpenter.sh/nodepool: system tolerations: - key: "CriticalAddonsOnly" operator: "Exists" containers: - name: app image: nginx:latest resources: requests: cpu: "500m" memory: "512Mi" ``` 要更新工作負載使其在 `system` 節點集區上執行，您需要： 1. 更新現有工作負載，以新增上述的下列組態： + `nodeSelector` + `tolerations` 1. 使用 `kubectl apply` 將更新後的工作負載部署到您的叢集 更新工作負載之後，它將在專用節點上執行。 # 在 EKS 自動模式中使用網路政策 ## 概觀 隨著客戶使用 EKS 擴展其應用程式環境，網路流量隔離變得越來越基本，以防止未經授權存取叢集內外的資源。這在多租用戶環境中特別重要，其中多個不相關的工作負載在叢集中並排執行。Kubernetes 網路政策可讓您增強 Kubernetes 工作負載的網路安全狀態，以及其與叢集外部端點的整合。EKS Auto Mode 支援不同類型的網路政策。 ### 第 3 層和第 4 層隔離 標準 Kubernetes 網路政策會在 OSI 網路模型的第 3 層和第 4 層運作，可讓您控制 Amazon EKS 叢集內 IP 地址或連接埠層級的流量流程。 #### 使用案例 + 分割工作負載之間的網路流量，以確保只有相關的應用程式可以互相通訊。 + 使用 政策在命名空間層級隔離租用戶，以強制執行網路分離。 ### DNS 型強制執行 客戶通常會在 EKS 中部署屬於更廣泛分散式環境的工作負載，其中一些工作負載必須與叢集外部的系統和服務 （北向流量） 通訊。這些系統和服務可以 AWS 位於 AWS 雲端或外部。以網域名稱系統 (DNS) 為基礎的政策可讓您採用更穩定且可預測的方法來加強安全狀態，以防止未經授權的 Pod 存取叢集外部資源或端點。此機制不需要手動追蹤和允許列出特定 IP 地址。透過以 DNS 為基礎的方法保護資源，您還可以更靈活地更新外部基礎設施，而無需在上游伺服器和主機變更時放寬安全狀態或修改網路政策。您可以使用完整網域名稱 (FQDN) 或 DNS 網域名稱的相符模式，篩選外部端點的輸出流量。這可讓您靈活地擴展對與特定叢集外部端點相關聯的多個子網域的存取。 #### 使用案例 + 標準化以 DNS 為基礎的方法，以篩選從 Kubernetes 環境到叢集外部端點的存取。 + 安全存取多租戶環境中 AWS 的服務。 + 管理混合雲端環境中從 Pod 到內部部署工作負載的網路存取。 ### 管理員 （或叢集範圍） 規則 在某些情況下，如同多租戶案例，客戶可能需要強制執行適用於整個叢集的網路安全標準。您可以使用單一政策來集中管理叢集中不同工作負載的網路存取控制，而不重複定義和維護每個命名空間的不同政策，無論其命名空間為何。這些類型的政策可讓您擴展在第 3 層、第 4 層和使用 DNS 規則時套用之網路篩選規則的強制執行範圍。 #### 使用案例 + 集中管理 EKS 叢集中所有 （或一部分） 工作負載的網路存取控制。 + 定義整個叢集的預設網路安全狀態。 + 以更具營運效率的方式，將組織安全標準擴展到叢集的範圍。 ## 開始使用 ### 先決條件 + 已啟用 EKS 自動模式的 Amazon EKS 叢集 + kubectl 已設定為連接到您的叢集 ### 步驟 1：啟用網路政策控制器 要在 EKS 自動模式中使用網路政策，您首先需要透過將 ConfigMap 套用到您的叢集，以啟用網路政策控制器。 1. 建立名為 `enable-network-policy.yaml` 且具有下列內容的檔案： ``` apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-network-policy-controller: "true" ``` 1. 將 ConfigMap 套用至您的叢集： ``` kubectl apply -f enable-network-policy.yaml ``` ### 步驟 2：建立和測試網路政策 您的 EKS 自動模式叢集現已設定為支援 Kubernetes 網路政策。您可利用 [Amazon EKS 的網路政策的星示範](network-policy-stars-demo.md) 來測試此功能。 ### 步驟 3：調整節點類別中的網路政策代理程式組態 （選用） 您可以選擇性地建立新的節點類別，以變更節點上網路政策代理程式的預設行為，或啟用網路政策事件的記錄。若要這麼做，請依照下列步驟進行： 1. 建立或編輯節點類別 YAML 檔案 (例如 `nodeclass-network-policy.yaml`)，內容如下： ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: network-policy-config spec: # Optional: Changes default network policy behavior networkPolicy: DefaultAllow # Optional: Enables logging for network policy events networkPolicyEventLogs: Enabled # Include other Node Class configurations as needed ``` 1. 將節點類別組態套用至您的叢集： ``` kubectl apply -f nodeclass-network-policy.yaml ``` 1. 確認節點類別是否已建立： ``` kubectl get nodeclass network-policy-config ``` 1. 更新您的節點集區，使其使用此節點類別。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。 ## 其運作方式？ ### DNS 型網路政策 ![\[在 EKS Auto 中套用 DNS 型政策時的工作流程圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/apply-dns-policy-1.png) ![\[在 EKS Auto 中套用 DNS 型政策時的工作流程圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/apply-dns-policy-2.png) 1. 平台團隊會將 DNS 型政策套用至 EKS 叢集。 1. 網路政策控制器負責監控叢集內政策的建立，然後協調政策端點。在此使用案例中，網路政策控制器會指示節點代理程式，根據所建立政策中允許列出的網域來篩選 DNS 請求。允許使用 FQDN 或符合 Kubernetes 資源組態中定義模式的網域名稱來列出網域名稱。 1. 工作負載 嘗試解析叢集外部端點的 IP。DNS 請求會先經過代理，根據透過網路政策套用的允許清單來篩選這類請求。 1. 一旦 DNS 請求通過 DNS 篩選條件允許清單，它會代理至 CoreDNS， 1. CoreDNS 會接著將請求傳送至外部 DNS 解析程式 (Amazon Route 53 Resolver)，以取得網域名稱後方的 IP 地址清單。 1. 回應 DNS 請求時，會傳回具有 TTL 的已解析 IPs。然後，這些 IPs會寫入 eBPF 映射中，用於執行 IP 層的下一個步驟。 1. 然後，連接至 Pod 實物界面的 eBPF 探查會根據適當的規則，篩選從工作負載 A 到叢集外部端點的輸出流量。這可確保 Pod 只能將叢集外部流量傳送到允許所列網域IPs。這些 IPs 的有效性是以從外部 DNS 解析程式 (Amazon Route 53 Resolver) 擷取的 TTL 為基礎。 #### 使用應用程式網路政策 `ApplicationNetworkPolicy` 結合了標準 Kubernetes 網路政策的功能，以及使用單一自訂資源定義 (CRD) 在命名空間層級進行 DNS 型篩選。因此， `ApplicationNetworkPolicy`可用於： 1. 使用 IP 區塊和連接埠號碼，定義網路堆疊第 3 層和第 4 層的限制。 1. 定義在網路堆疊第 7 層操作的規則，並讓您根據 FQDNs篩選流量。 **重要** 使用 定義的 DNS 型規則`ApplicationNetworkPolicy`僅適用於在 EKS Auto Mode 啟動的 EC2 執行個體中執行的工作負載。 `ApplicationNetworkPolicy`支援標準 Kubernetes 的所有欄位`NetworkPolicy`，以及用於輸出規則的額外 FQDN 篩選條件。 **警告** 請勿將相同的名稱用於相同命名空間`NetworkPolicy`內的 `ApplicationNetworkPolicy`和 。如果名稱衝突，產生的`PolicyEndpoints`物件可能無法正確反映任一政策。接受這兩個資源不會發生錯誤，導致此問題難以診斷。 若要解決命名衝突，請重新命名 `ApplicationNetworkPolicy`或 ，`NetworkPolicy`使其在命名空間中是唯一的，然後驗證對應的`PolicyEndpoints`物件是否已正確更新。 #### 範例 EKS Auto Mode 叢集中有工作負載，需要與具有 DNS 名稱的負載平衡器後方的應用程式內部部署通訊。您可以使用下列網路政策來達成此目的： ``` apiVersion: networking.k8s.aws/v1alpha1 kind: ApplicationNetworkPolicy metadata: name: my-onprem-app-egress namespace: galaxy spec: podSelector: matchLabels: role: backend policyTypes: - Egress egress: - to: - domainNames: - "myapp.mydomain.com" ports: - protocol: TCP port: 8080 ``` 在 Kubernetes 網路層級，這將允許從標記為 的「galaxy」命名空間中的任何 Pod 輸出`role: backend`，以連接到 TCP 連接埠 8080 上的網域名稱 **myapp.mydomain.com**。此外，您需要為從 VPC 到公司資料中心的輸出流量設定網路連線。 ![\[EKS Auto 中工作負載與內部部署應用程式通訊的圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/eks-auto-to-on-prem.png) ### 管理員 （或叢集） 網路政策 ![\[EKS 網路政策的評估順序圖解\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/evaluation-order.png) #### 使用叢集網路政策 使用 時`ClusterNetworkPolicy`，會先評估管理員層政策，且無法覆寫。評估管理員層政策後，會使用標準命名空間範圍政策來執行套用的網路分割規則。這可以透過使用 `ApplicationNetworkPolicy`或 來完成`NetworkPolicy`。最後，將強制執行定義叢集工作負載預設網路限制的基準層規則。如有需要，命名空間範圍政策**可以**覆寫這些基準層規則。 #### 範例 叢集中有您要隔離其他租用戶工作負載的應用程式。您可以明確封鎖來自其他命名空間的叢集流量，以防止網路存取敏感工作負載命名空間。 ``` apiVersion: networking.k8s.aws/v1alpha1 kind: ClusterNetworkPolicy metadata: name: protect-sensitive-workload spec: tier: Admin priority: 10 subject: namespaces: matchLabels: kubernetes.io/metadata.name: earth ingress: - action: Deny from: - namespaces: matchLabels: {} # Match all namespaces. name: select-all-deny-all ``` ## 考量事項 ### 了解政策評估順序 EKS 中支援的網路政策功能會以特定順序評估，以確保可預測且安全的流量管理。因此，請務必了解評估流程，為您的環境設計有效的網路安全狀態。 1. **管理員層政策 （先評估）**：所有管理員層 ClusterNetworkPolicies 都會在任何其他政策之前進行評估。在管理員層中，政策會依優先順序處理 （優先順序最低的數字優先）。動作類型會決定接下來會發生的情況。 + **拒絕動作 （最高優先順序）**：當具有拒絕動作的管理員政策符合流量時，無論任何其他政策為何，都會立即封鎖該流量。不會處理其他 ClusterNetworkPolicy 或 NetworkPolicy 規則。這可確保命名空間層級政策不會覆寫整個組織的安全控制。 + **允許動作**：評估拒絕規則之後，具有允許動作的管理員政策會依優先順序 （優先順序最低的數字優先） 處理。當允許動作相符時，系統會接受流量，而不會進行進一步的政策評估。這些政策可以根據標籤選擇器授予多個命名空間的存取權，從而集中控制哪些工作負載可以存取特定資源。 + **傳遞動作**：在管理員層政策中傳遞動作，將決策委派給較低的層。當流量符合通過規則時，評估會略過該流量的所有剩餘管理員層規則，並直接進入 NetworkPolicy 層。這可讓管理員將特定流量模式的控制明確委派給應用程式團隊。例如，您可以使用傳遞規則將命名空間內流量管理委派給命名空間管理員，同時對外部存取維持嚴格的控制。 1. **網路政策層**：如果沒有管理員層政策與拒絕或允許相符，或者傳遞動作相符，則會接著評估命名空間範圍的 ApplicationNetworkPolicy 和傳統 NetworkPolicy 資源。這些政策可在個別命名空間內提供精細的控制，並由應用程式團隊管理。命名空間範圍政策只能比管理員政策更嚴格。他們無法覆寫管理員政策的拒絕決策，但可以進一步限制管理員政策允許或傳遞的流量。 1. **基準層管理員政策**：如果沒有管理員或命名空間範圍的政策符合流量，則會評估基準層 ClusterNetworkPolicies。這些提供可由命名空間範圍政策覆寫的預設安全狀態，允許管理員設定整個組織的預設值，同時為團隊提供視需要自訂的彈性。基準政策會依優先順序 （優先順序最低的數字優先） 進行評估。 1. **預設拒絕 （如果沒有政策相符）**：此deny-by-default行為可確保只允許明確允許的連線，並維持強大的安全狀態。 ### 套用最低權限原則 + **從限制性政策開始，並視需要逐步新增許可** - 首先在叢集層級實作deny-by-default政策，然後在驗證合法連線需求時逐步新增允許規則。這種方法會強制團隊明確地證明每個外部連線，建立更安全且可稽核的環境。 + **定期稽核並移除未使用的政策規則** - 網路政策會隨著應用程式演進而隨著時間累積，留下過時規則，不必要的擴展攻擊面。實作定期審查程序，以識別和移除不再需要的政策規則，確保您的安全狀態保持緊密且可維護。 + **盡可能使用特定的網域名稱，而不是廣泛的模式** - 雖然萬用字元模式`*.amazonaws.com`可提供便利性，但它們也會授予對各種服務的存取權。可行時，請指定 之類的確切網域名稱`s3.us-west-2.amazonaws.com`，以限制僅存取應用程式所需的特定服務，降低工作負載受損時橫向移動的風險。 ### 在 EKS 中使用 DNS 型政策 + 使用 定義的 DNS 型規則`ApplicationNetworkPolicy`僅適用於在 EKS Auto Mode 啟動 EC2 執行個體中執行的工作負載。如果您執行混合模式叢集 （包含 EKS Auto 和非 EKS Auto 工作者節點），您的 DNS 型規則僅在 EKS Auto 模式工作者節點 (EC2 受管執行個體） 中有效。 ### 驗證您的 DNS 政策 + **使用模擬生產網路拓撲的預備叢集進行測試** - 您的預備環境應該複寫生產的網路架構、外部相依性和連線模式，以確保準確的政策測試。這包括相符的 VPC 組態、DNS 解析行為，以及對生產工作負載所需的相同外部服務的存取。 + **實作關鍵網路路徑的自動化測試** - 建置自動化測試，以驗證 CI/CD 管道中必要外部服務的連線能力。這些測試應驗證在封鎖未經授權的連線時是否允許合法流量流程，提供持續驗證，讓您的網路政策隨著基礎設施發展維持正確的安全狀態。 + 在**政策變更後監控應用程式行為** - 在將新的或修改的網路政策部署至生產環境之後，請密切監控應用程式日誌、錯誤率和效能指標，以快速識別任何連線問題。建立明確的轉返程序，以便在政策變更造成非預期的應用程式行為或服務中斷時，快速還原政策變更。 ### 與 Amazon Route 53 DNS 防火牆的互動 啟動流量時，EKS Admin 和 Network 政策會先在 Pod 層級進行評估。如果 EKS 網路政策允許輸出至特定網域，則 Pod 會執行到達 Route 53 Resolver 的 DNS 查詢。此時會評估 Route 53 DNS 防火牆規則。如果 DNS 防火牆封鎖網域查詢，DNS 解析會失敗，而且即使 EKS 網路政策允許，也無法建立連線。這會建立互補的安全層：EKS DNS 型網路政策為應用程式特定的存取要求和多租用戶安全界限提供 Pod 層級的輸出控制，而 DNS 防火牆為已知惡意網域提供 VPC 整體保護，並強制執行整個組織的封鎖清單。 # 標記 EKS 自動模式的子網路 如果您使用 EKS Auto Mode 的負載平衡功能，則需要將 AWS 標籤新增至 VPC 子網路。 ## 背景介紹 這些標籤可辨識與叢集關聯的子網路，且更重要的是辨識子網路為公有還是私有。 公有子網路可透過網際網路閘道直接存取網際網路。其適用於負載平衡器等需要公開存取的資源。 私有子網路不可直接存取網際網路，且針對傳出流量會使用 NAT 閘道。其適用於不需要公有 IP 的 EKS 節點等內部資源。 如需了解 NAT 閘道及網際網路閘道的相關詳細資訊，請參閱《Amazon Virtual Private Cloud (VPC) 使用者指南》中的[連線 VPC 與其他網路](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html)。 ## 需求 目前，EKS 自動模式用於負載平衡的子網路，需要具有以下其中一個標籤。 ### 公有子網路 公有子網路適用於面向網際網路的負載平衡器。這些子網路必須具有以下標籤： | 金鑰 | 值 | | --- | --- | | `kubernetes.io/role/elb` | `1` 或 `` | ### 私有子網路 私有子網路適用於內部負載平衡器。這些子網路必須具有以下標籤： | 金鑰 | 值 | | --- | --- | | `kubernetes.io/role/internal-elb` | `1` 或 `` | ## 程序 開始操作之前，辨識哪些子網路為公有 (透過網際網路閘道存取) 及哪些為私有 (使用 NAT 閘道)。修改 VPC 資源需要許可。 ### AWS 管理主控台 1. 開啟 Amazon VPC 主控台並導覽至**子網路**。 1. 選取要標記的子網路。 1. 選擇**標籤**索引標籤，然後選取**新增標籤**。 1. 新增適當的標籤： + 針對公有子網路：Key=`kubernetes.io/role/elb` + 針對私有子網路：Key=`kubernetes.io/role/internal-elb` 1. 將**值**設定為 `1`或保持空白。 1. 儲存並重複其餘子網路。 ### AWS CLI 針對公有子網路： ``` aws ec2 create-tags \ --resources subnet-ID \ --tags Key=kubernetes.io/role/elb,Value=1 ``` 針對私有子網路： ``` aws ec2 create-tags \ --resources subnet-ID \ --tags Key=kubernetes.io/role/internal-elb,Value=1 ``` 使用實際的子網路 ID 取代 `subnet-ID`。 # 透過 kubectl debug 從 Kubernetes 節點產生 CIS 合規報告 本主題說明如何使用 `kubectl debug` 命令，為 Amazon EKS 節點產生 CIS (Center for Internet Security) 合規報告。此命令可讓您在 Kubernetes 節點上暫時建立偵錯容器，並透過 `apiclient` 工具執行 CIS 合規檢查。`apiclient` 工具是 Bottlerocket OS 的一部分，而 Bottlerocket OS 是 EKS 自動模式節點所使用的作業系統。 ## 先決條件 開始前，請確保您具備以下條件： + 可存取 Amazon EKS 叢集，且已設定 `kubectl` (版本必須至少為 v1.32.0；可輸入 `kubectl version` 進行檢查)。 + 具備適當的 IAM 許可以進行節點偵錯。 + 有效的設定檔，可允許執行偵錯作業 (如 `sysadmin`)。 如需有關搭配 `kubectl` 使用偵錯設定檔的詳細資訊，請參閱 Kubernetes 文件中的[套用設定檔時對 Pod 或節點進行偵錯](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles)。 ## 程序 1. 決定您要執行報告的節點 AWS 執行個體 ID。使用下列命令列出叢集中的節點。執行個體 ID 可在名稱欄位中找到，且開頭為 `i-`： ``` kubectl get nodes ``` ``` NAME STATUS ROLES AGE VERSION i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd ``` 1. 執行下列命令，並將 `` 取代為您要查詢的節點的執行個體 ID： ``` kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text" ``` 此命令的組成部分包括： + `kubectl debug node/`：在指定的 EC2 執行個體 ID 上建立偵錯工作階段。 + `-it`：配置 TTY (命令列 Shell)，並保持 stdin 開啟以支援互動式使用。 + `--profile=sysadmin`：使用具備適當許可的指定 `kubectl` 設定檔。 + `--image=public.ecr.aws/amazonlinux/amazonlinux:2023`：使用 `amazonlinux:2023` 作為偵錯的容器映像。 + `bash -c "…​"`：在 bash shell 中執行下列命令： + `yum install -q -y util-linux-core`：以安靜模式安裝所需的公用程式套件。 + `nsenter -t 1 -m`：執行 `nsenter` 以輸入主機程序 (PID 1) 的命名空間。 + `apiclient report cis --level 1 --format text`：執行等級 1 的 CIS 合規報告，並以文字格式輸出結果。 1. 檢閱報告的文字輸出。 ## 解譯輸出 此命令會產生文字格式的報告，顯示各項 CIS 控制項的合規狀態。輸出內容包括： + 個別的 CIS 控制項 ID + 每個控制項的描述 + 每項檢查的通過、失敗或略過狀態 + 解釋任何合規問題的詳細資訊 以下是在 Bottlerocket 執行個體上執行報告後的輸出範例： ``` Benchmark name: CIS Bottlerocket Benchmark Version: v1.0.0 Reference: https://www.cisecurity.org/benchmark/bottlerocket Benchmark level: 1 Start time: 2025-04-11T01:40:39.055623436Z [SKIP] 1.2.1 Ensure software update repositories are configured (Manual) [PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic) [PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic) [PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic) [PASS] 1.5.1 Ensure SELinux is configured (Automatic) [SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual) [PASS] 2.1.1.1 Ensure chrony is configured (Automatic) [PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic) [PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic) [PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic) [SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual) [SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual) [PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic) [PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic) Passed: 11 Failed: 0 Skipped: 4 Total checks: 15 ``` 如需關於基準的資訊，請參閱 Center for Internet Security (CIS) 的 [Kubernetes 基準](https://www.cisecurity.org/benchmark/kubernetes/)。 ## 相關資源 + [Bottlerocket 作業系統文件中的 Bottlerocket CIS 基準](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/)。 + Kubernetes 文件中的[偵錯執行中的 Pod](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/)。 + Center for Internet Security (CIS) 的 [Kubernetes 基準](https://www.cisecurity.org/benchmark/kubernetes/)。 # 為 EKS 自動模式啟用含客戶自管 KMS 金鑰的 EBS 磁碟區加密 您可使用客戶管理的 KMS 金鑰來加密 EKS 自動模式執行個體的暫時性根磁碟區。 Amazon EKS Auto Mode 使用服務連結角色，在管理 Kubernetes 叢集的加密 EBS 磁碟區 AWS 時，將許可委派給其他服務。本主題描述在為 EKS 自動模式指定客戶管理金鑰以進行 Amazon EBS 加密時，所需設定的金鑰政策。 考量： + EKS Auto Mode 不需要額外的授權，即可使用預設 AWS 受管金鑰來保護您帳戶中的加密磁碟區。 + 本主題涵蓋加密暫時性磁碟區，即 EC2 執行個體的根磁碟區。有關加密用於工作負載的資料磁碟區的更多資訊，請參閱 [建立儲存類別](create-storage-class.md)。 ## 概觀 當 EKS Auto Mode 啟動執行個體時，下列 AWS KMS 金鑰可用於 Amazon EBS 根磁碟區加密： + ** AWS 受管金鑰** – 在您的帳戶中由 Amazon EBS 建立、擁有和管理的加密金鑰。這是新帳戶的預設加密金鑰。 + **客戶受管金鑰** – 您所建立、擁有和管理的自訂加密金鑰。 **注意** 金鑰必須為對稱金鑰。Amazon EBS 不支援非對稱客戶受管金鑰。 ## 步驟 1：設定金鑰政策 您的 KMS 金鑰必須具有金鑰政策，允許 EKS 自動模式使用透過客戶受管金鑰加密的 Amazon EBS 磁碟區來啟動執行個體。 使用下列結構設定您的金鑰政策： **注意** 此政策僅包含 EKS 自動模式所需的許可。如果其他身分需要使用金鑰或管理授予，金鑰政策可能需要額外授權。 ``` { "Version":"2012-10-17", "Id": "MyKeyPolicy", "Statement": [ { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/ClusterServiceRole" ] }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*" }, { "Sid": "Allow attachment of persistent resources", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/ClusterServiceRole" ] }, "Action": [ "kms:CreateGrant", "kms:ListGrants", "kms:RevokeGrant" ], "Resource": "*", "Condition": { "Bool": { "kms:GrantIsForAWSResource": "true" } } } ] } ``` 請務必將 取代``為您實際 AWS 的帳戶 ID。 在設定金鑰政策時： + `ClusterServiceRole` 必須擁有必要的 IAM 許可，才能使用 KMS 金鑰進行加密操作 + `kms:GrantIsForAWSResource` 條件可確保只能為 AWS 服務建立授予 ## 步驟 2：使用您的客戶管理金鑰設定 NodeClass 設定金鑰政策後，在 EKS 自動模式 NodeClass 組態中參考 KMS 金鑰： ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: my-node-class spec: # Insert existing configuration ephemeralStorage: size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T iops: 3000 # Range: 3000-16000 throughput: 125 # Range: 125-1000 # KMS key for encryption kmsKeyID: "arn:aws: kms:::key/" ``` 使用您的實際值取代預留位置的值： + `` 您的 AWS 區域 + `` 使用 AWS 您的帳戶 ID + 將 `` 取代為您的 KMS 金鑰 ID 您可使用下列任何格式指定 KMS 金鑰： + KMS 金鑰 ID：`1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d` + KMS 金鑰 ARN：` arn:aws: kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d` + 金鑰別名名稱：`alias/eks-auto-mode-key` + 金鑰別名 ARN：` arn:aws: kms:us-west-2:111122223333:alias/eks-auto-mode-key` 使用 kubectl 套用 NodeClass 組態： ``` kubectl apply -f nodeclass.yaml ``` ## 相關資源 + [建立 Amazon EKS 的節點類別](create-node-class.md) + 在 AWS Key Management Service 開發人員指南中檢視詳細資訊 + [金鑰政策中 AWS 服務的許可](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html) + [變更金鑰政策](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) + [AWS KMS 中的授予](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) # 更新 EKS 自動模式的組織控制 某些組織控制項可能會阻止 EKS 自動模式正常運作。如果是這種情況，您必須更新這些控制項，以允許 EKS 自動模式擁有代表您管理 EC2 執行個體所需的許可。 EKS 自動模式使用服務角色來啟動恢復 EKS 自動模式節點的 EC2 執行個體。服務角色是在您帳戶中建立的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)，服務會擔任此角色以代表您執行操作。[服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) 始終適用於使用服務角色執行的操作。這能讓 SCP 限制自動模式的操作。最常見的情況是利用 SCP 來限制可以啟動的 Amazon Machine Image (AMI)。為了讓 EKS 自動模式能夠運作，請修改 SCP 以允許從 EKS 自動模式帳戶啟動 AMI。 您也可使用 [EC2 允許的 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) 功能來限制其他帳戶中 AMI 的可見性。若您使用此功能，必須擴展映像標準，以同時包含感興趣區域中的 EKS 自動模式 AMI 帳戶。 ## 僅允許 EKS 自動模式 AMI 而封鎖所有其他 AMI 的範例 SCP 下面的 SCP 會阻止呼叫 `ec2:RunInstances`，除非 AMI 屬於 us-west-2 或 us-east-1 區域的 EKS 自動模式 AMI 帳戶。 **注意** 請**勿**使用 `ec2:Owner` 內容索引鍵。Amazon 擁有 EKS 自動模式 AMI 帳戶，此索引鍵的值一律為 `amazon`。若構建的 SCP 允許在 `ec2:Owner` 為 `amazon` 時啟動 AMI，將會允許啟動任何 Amazon 擁有的 AMI，而非僅限 EKS 自動模式專用的 AMI。\$1 ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAMI", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:*:ec2:*::image/ami-*", "Condition": { "StringNotEquals": { "aws:ResourceAccount": [ "767397842682", "992382739861" ] } } } ] } ``` ## EKS 自動模式 AMI 帳戶 AWS 帳戶因區域主機 EKS Auto Mode 公有 AMIs 而異。 | | | | --- |--- | | AWS 區域 | 帳戶 | | af-south-1 | 471112993317 | | ap-east-1 | 590183728416 | | ap-east-2 | 381492200852 | | ap-northeast-1 | 851725346105 | | ap-northeast-2 | 992382805010 | | ap-northeast-3 | 891377407544 | | ap-south-1 | 975049899075 | | ap-south-2 | 590183737426 | | ap-southeast-1 | 339712723301 | | ap-southeast-2 | 058264376476 | | ap-southeast-3 | 471112941769 | | ap-southeast-4 | 590183863144 | | ap-southeast-5 | 654654202513 | | ap-southeast-6 | 905418310314 | | ap-southeast-7 | 533267217478 | | ca-central-1 | 992382439851 | | ca-west-1 | 767397959864 | | eu-central-1 | 891376953411 | | eu-central-2 | 381492036002 | | eu-north-1 | 339712696471 | | eu-south-1 | 975049955519 | | eu-south-2 | 471112620929 | | eu-west-1 | 381492008532 | | eu-west-2 | 590184142468 | | eu-west-3 | 891376969258 | | il-central-1 | 590183797093 | | me-central-1 | 637423494195 | | me-south-1 | 905418070398 | | mx-central-1 | 211125506622 | | sa-east-1 | 339712709251 | | us-east-1 | 992382739861 | | us-east-2 | 975050179949 | | us-west-1 | 975050035094 | | us-west-2 | 767397842682 | | us-gov-east-1 | 446077414359 | | us-gov-west-1 | 446098668741 | ## 關聯公有 IP 位址 當呼叫 `ec2:RunInstances` 時，執行個體啟動的 `AssociatePublicIpAddress` 欄位是由啟動該執行個體的子網路類型自動決定的。SCP 可能被用來強制要求此值必須明確設定為 false，不論所啟動至的子網路類型為何。在這種情況下，可以將 NodeClass 欄位 `spec.advancedNetworking.associatePublicIPAddress` 也設定為 false，以滿足 SCP 的要求。 ``` { "Sid": "DenyPublicEC2IPAddesses", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:aws:ec2:*:*:network-interface/*", "Condition": { "BoolIfExists": { "ec2:AssociatePublicIpAddress": "true" } } } ``` # 使用 EKS 自動模式控制工作負載部署至容量保留 您可以控制工作負載部署至[容量保留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html)的方式。EKS 自動模式支援 EC2 隨需容量保留 (ODCR) 和適用於 ML 的 EC2 容量區塊。 **提示** 根據預設，EKS Auto Mode 可以透過開放比對在開放 ODCRs 中啟動，但不會排定它們的優先順序。透過開放比對啟動的執行個體會標記為 `karpenter.sh/capacity-type: on-demand`，而不是 `reserved`。若要排定 ODCR 用量的優先順序，並讓執行個體標記為 `karpenter.sh/capacity-type: reserved`，請在 NodeClass 定義`capacityReservationSelectorTerms`中設定 。ML 的容量區塊一律需要`capacityReservationSelectorTerms`且不會自動使用。 ## EC2 隨需容量保留 (ODCR) EC2 隨需容量保留 (ODCR) 可讓您在特定可用區域中，為 Amazon EC2 執行個體保留任何期限的運算容量。使用 EKS 自動模式時，您可能希望控制您的 Kubernetes 工作負載是否部署到這些保留執行個體上，以最大化預購容量的利用率，或確保關鍵工作負載能夠存取保證的資源。 預設情況下，EKS 自動模式會自動啟動到開放的 ODCR 中。但是，透過在 NodeClass 上設定 `capacityReservationSelectorTerms`，您可以明確控制您的工作負載使用哪些 ODCR。透過已設定 ODCR 佈建的節點會帶有 `karpenter.sh/capacity-type: reserved` 標籤，且其優先順序高於隨需與 Spot 執行個體。啟用此功能後，EKS 自動模式將不再自動使用開放的 ODCR，必須透過 NodeClass 明確選取這些 ODCR，讓您能精確控制叢集中容量保留的使用情況。 **警告** 若您在叢集中的某個 NodeClass 上設定 `capacityReservationSelectorTerms`，則 EKS 自動模式將不再為叢集中*任何* NodeClass 自動使用開放的 ODCR。 ### 範例 NodeClass ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass spec: # Optional: Selects upon on-demand capacity reservations and capacity blocks # for EKS Auto Mode to prioritize. capacityReservationSelectorTerms: - id: cr-56fac701cc1951b03 # Alternative Approaches - tags: app: "my-app" # Optional owning account ID filter owner: "012345678901" ``` 此範例 NodeClass 示範了兩種選取 ODCR 的方式。第一種方式透過 ODCR 的 ID (`cr-56fac701cc1951b03`) 直接參考特定 ODCR。第二種方式使用基於標籤的選取邏輯，目標為帶有 `Name: "targeted-odcr"` 標籤的 ODCR。您也可以選擇性地依擁有保留 AWS 的帳戶進行篩選，這在跨帳戶案例或處理共用容量保留時特別有用。 ## ML 的 EC2 容量區塊 ML 的容量區塊可讓您為日後預留基於 GPU 的加速運算執行個體，以支援短時間的機器學習 (ML) 工作負載。容量區塊內執行的執行個體會在 Amazon EC2 UltraCluster 內自動放置於鄰近位置，以實現低延遲、Pb 級的非阻塞式聯網。 有關支援的平台和執行個體類型的詳細資訊，請參閱 EC2 使用者指南中的 [ML 的容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)。 您可以建立使用 ML 的容量區塊的 EKS 自動模式 NodeClass，類似於 ODCR (先前說明)。 以下範例定義會建立了三個資源： 1. 一個引用您的容量區塊保留的 NodeClass 1. 一個使用該 NodeClass 並套用污點的 NodePool 1. 一個容忍該污點並請求 GPU 資源的 Pod 規格 ### 範例 NodeClass 此 NodeClass 透過其保留 ID 引用特定 ML 的容量區塊。您可從 EC2 主控台取得此 ID。 ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: gpu spec: # Specify your Capacity Block reservation ID capacityReservationSelectorTerms: - id: cr-56fac701cc1951b03 ``` 如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md)。 ### NodePool 範例 此 NodePool 引用了 `gpu` NodeClass 並指定了重要組態： + 它透過設定 `karpenter.sh/capacity-type: reserved` **僅**使用預留容量 + 它請求適合 ML 工作負載的特定 GPU 執行個體系列 + 它會套用 `nvidia.com/gpu` 污點，確保僅 GPU 工作負載會排程至這些節點 ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: gpu requirements: - key: eks.amazonaws.com/instance-family operator: In values: - g6 - p4d - p4de - p5 - p5e - p5en - p6 - p6-b200 - key: karpenter.sh/capacity-type operator: In values: - reserved # Enable other capacity types # - on-demand # - spot taints: - effect: NoSchedule key: nvidia.com/gpu ``` 如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。 ### 範例 Pod 此範例 Pod 示範了如何設定要在容量區塊節點上執行的工作負載： + 它使用 **nodeSelector**，以特定 GPU 類型為目標 (此處為 H200 GPU) + 它包含對 NodePool 所套用 `nvidia.com/gpu` 污點的**容差** + 它使用 `nvidia.com/gpu` 資源類型明確**請求 GPU 資源** ``` apiVersion: v1 kind: Pod metadata: name: nvidia-smi spec: nodeSelector: # Select specific GPU type - uncomment as needed # eks.amazonaws.com/instance-gpu-name: l4 # eks.amazonaws.com/instance-gpu-name: a100 eks.amazonaws.com/instance-gpu-name: h200 # eks.amazonaws.com/instance-gpu-name: b200 eks.amazonaws.com/compute-type: auto restartPolicy: OnFailure containers: - name: nvidia-smi image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal args: - "nvidia-smi" resources: requests: # Uncomment if needed # memory: "30Gi" # cpu: "3500m" nvidia.com/gpu: 1 limits: # Uncomment if needed # memory: "30Gi" nvidia.com/gpu: 1 tolerations: - key: nvidia.com/gpu effect: NoSchedule operator: Exists ``` 如需詳細資訊，請參閱 Kubernetes 文件中的 [Pod](https://kubernetes.io/docs/concepts/workloads/pods/)。 ### 相關資源 + 《Amazon EC2 使用者指南》中的 [ML 的容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) + 《Amazon EC2 使用者指南》中的[尋找和購買容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) + [管理 Amazon EKS 上 AI/ML 工作負載的運算資源](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html) + 《EKS 最佳實務指南》中的 [GPU 資源最佳化和成本管理](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) # 將 EKS Auto Mode 節點部署至 Local Zones EKS Auto Mode 透過自動節點佈建提供簡化的叢集管理。 AWS 本機區域可將 AWS 基礎設施擴展到更接近最終使用者的地理位置，從而減少延遲敏感應用程式的延遲。本指南會逐步解說將 EKS Auto Mode 節點部署至 AWS Local Zones 的程序，讓您針對特定地理區域的使用者執行具有較低延遲的容器化應用程式。 本指南也示範如何使用 Kubernetes 污點和容錯，以確保只有特定工作負載會在 Local Zone 節點上執行，協助您控制成本並最佳化資源用量。 ## 先決條件 開始將 EKS Auto Mode 節點部署到 Local Zones 之前，請確定您已備妥下列先決條件： + [現有的 EKS 自動模式叢集](create-auto.md) + [選擇加入您 AWS 帳戶中的本機區域](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone) ## 步驟 1：建立本機區域子網路 將 EKS Auto Mode 節點部署到 Local Zone 的第一步是在該 Local Zone 中建立子網路。此子網路為您的節點提供網路基礎設施，並允許它們與您的其餘 VPC 通訊。遵循[建立本機區域子網路](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet)指示 （在 AWS 本機區域使用者指南中），在您選擇的本機區域中建立子網路。 **提示** 請記下本機區域子網路的名稱。 ## 步驟 2：為本機區域子網路建立 NodeClass 建立本機區域子網路之後，您需要定義參考此子網路的 NodeClass。NodeClass 是一種 Kubernetes 自訂資源，可指定節點的基礎設施屬性，包括要使用的子網路、安全群組和儲存組態。在下面的範例中，我們建立名為 "local-zone" 的 NodeClass，根據其名稱以本機區域子網路為目標。您也可以使用子網路 ID。您需要調整此組態以鎖定您的 Local Zone 子網路。 如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md)。 ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: local-zone spec: subnetSelectorTerms: - id: ``` ## 步驟 3：使用 NodeClass 和 Taint 建立 NodePool 設定 NodeClass 後，您現在需要建立使用此 NodeClass 的 NodePool。NodePool 會定義節點的運算特性，包括執行個體類型。NodePool 使用 NodeClass 做為參考，以判斷在何處啟動執行個體。 在以下範例中，我們會建立參考 "local-zone" NodeClass 的 NodePool。我們也會將污點新增至節點，以確保只有具有相符公差的 Pod 才能排程在這些 Local Zone 節點上。這對 Local Zone 節點特別重要，這通常具有較高的成本，並且只能由特別受益於降低延遲的工作負載使用。 如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。 ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: my-node-pool spec: template: metadata: labels: node-type: local-zone spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: local-zone taints: - key: "aws.amazon.com/local-zone" value: "true" effect: NoSchedule requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m", "r"] - key: "eks.amazonaws.com/instance-cpu" operator: In values: ["4", "8", "16", "32"] ``` 具有金鑰`aws.amazon.com/local-zone`和效果的污點`NoSchedule`可確保在這些節點上不會排程沒有相符公差的 Pod。這可防止定期工作負載意外在 Local Zone 中執行，這可能會導致意外的成本。 ## 步驟 4：部署具有公差和節點親和性的工作負載 若要最佳控制本機區域節點上的工作負載置放，請同時使用污點/容錯和節點親和性。此合併方法提供下列優點： 1. **成本控制**：污點可確保只有具有明確公差的 Pod 可以使用可能昂貴的 Local Zone 資源。 1. **保證配置**：節點親和性可確保對延遲敏感的應用程式僅在本機區域執行，而不是在一般叢集節點上執行。 以下是設定為在 Local Zone 節點上特別執行的部署範例： ``` apiVersion: apps/v1 kind: Deployment metadata: name: low-latency-app namespace: default spec: replicas: 2 selector: matchLabels: app: low-latency-app template: metadata: labels: app: low-latency-app spec: tolerations: - key: "aws.amazon.com/local-zone" operator: "Equal" value: "true" effect: "NoSchedule" affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "node-type" operator: "In" values: ["local-zone"] containers: - name: application image: my-low-latency-app:latest resources: limits: cpu: "1" memory: "1Gi" requests: cpu: "500m" memory: "512Mi" ``` 此部署有兩個金鑰排程組態： 1. **容錯允許**在具有`aws.amazon.com/local-zone`污點的節點上排程 Pod。 1. **節點親和性**要求可確保這些 Pod 只會在標籤為 的節點上執行`node-type: local-zone`。 這些共同確保您的延遲敏感應用程式僅在 Local Zone 節點上執行，且一般應用程式不會使用 Local Zone 資源，除非明確設定這樣做。 ## 步驟 5：使用 AWS 主控台驗證 設定 NodeClass、NodePool 和 部署之後，您應該驗證節點是否如預期佈建在 Local Zone，以及工作負載是否在其上執行。您可以使用 AWS 管理主控台來驗證 EC2 執行個體是否在正確的本機區域子網路中啟動。 此外，您可以使用 檢查 Kubernetes 節點清單`kubectl get nodes -o wide`，以確認節點使用正確的標籤和污點來加入您的叢集： ``` kubectl get nodes -o wide kubectl describe node | grep -A 5 Taints ``` 您也可以確認您的工作負載 Pod 已排程在 Local Zone 節點上： ``` kubectl get pods -o wide ``` 此方法可確保只會在這些節點上排定特別容忍 Local Zone 污點的工作負載，協助您控制成本並最有效地使用 Local Zone 資源。 # 設定節點的進階安全設定 本主題說明如何使用節點類別中的`advancedSecurity`規格來設定 Amazon EKS Auto Mode 節點的進階安全設定。 ## 先決條件 開始前，請確保您具備以下條件： + 一個 Amazon EKS 自動模式叢集。如需詳細資訊，請參閱[使用 Amazon EKS 自動模式建立叢集](create-auto.md)。 + `kubectl` 已安裝並已設定。如需詳細資訊，請參閱[設定以使用 Amazon EKS](setting-up.md)。 + 了解節點類別組態。如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md)。 ## 設定進階安全設定 若要設定節點的進階安全設定，請在節點類別規格中設定`advancedSecurity`欄位： ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: security-hardened spec: role: MyNodeRole subnetSelectorTerms: - tags: Name: "private-subnet" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" advancedSecurity: # Enable FIPS-compliant AMIs (US regions only) fips: true # Configure kernel lockdown mode kernelLockdown: "integrity" ``` 套用此組態： ``` kubectl apply -f nodeclass.yaml ``` 在您的節點集區組態中參考此節點類別。如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。 ## 欄位描述 + `fips` （布林值，選用）：設為 時`true`， 會使用具有 FIPS 140-2 驗證密碼編譯模組的 AMIs 佈建節點。此設定會選取符合 FIPS 標準的 AMIs；客戶負責管理其合規要求。如需詳細資訊，請參閱 [AWS FIPS 合規](https://aws.amazon.com/compliance/fips/)。預設：`false`。 + `kernelLockdown` （字串，選用）：控制核心鎖定安全模組模式。接受的值： + `integrity`：封鎖覆寫核心記憶體或修改核心程式碼的方法。防止未簽署的核心模組載入。 + `none`：停用核心鎖定保護。 如需詳細資訊，請參閱 [Linux 核心鎖定文件](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html)。 ## 考量事項 + FIPS 相容的 AMIs 適用於 AWS 美國東部/西部、 AWS GovCloud (US) 和 AWS 加拿大 （中部/西部） 區域。如需詳細資訊，請參閱 [AWS FIPS 合規](https://aws.amazon.com/compliance/fips/)。 + 使用 時`kernelLockdown: "integrity"`，請確保您的工作負載不需要載入未簽署的核心模組或修改核心記憶體。 ## 相關資源 + [建立 Amazon EKS 的節點類別](create-node-class.md) - 完成節點類別組態指南 + [為 EKS 自動模式建立節點集區](create-node-pool.md) - 節點集區組態