**帮助改进此页面** 要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。 # 配置 EKS 自动模式设置 本章介绍如何配置 Amazon Elastic Kubernetes Service（EKS）自动模式集群的特定方面。虽然 EKS 自动模式会自动管理大多数基础设施组件，不过您也可以自定义某些功能来满足工作负载的要求。 使用本主题中介绍的配置选项，您可以修改联网设置、计算资源和负载均衡行为，同时继续享受自动化基础设施管理的优势。在进行任何配置更改之前，请检查以下各节中的可用选项，以确定哪种方法最适合您的需求。 | 您要配置哪些功能？ | 配置选项 | | --- | --- | | **节点联网和存储** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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_cn/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_cn/eks/latest/userguide/settings-auto.html) | [EKS Auto Mode 中的静态容量节点池](auto-static-capacity.md) | | **应用程序负载均衡器设置** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/settings-auto.html) | [创建 IngressClass 以配置应用程序负载均衡器](auto-configure-alb.md) | | **网络负载均衡器设置** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/settings-auto.html) | [使用服务注释配置网络负载均衡器](auto-configure-nlb.md) | | **存储类设置** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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_cn/eks/latest/userguide/settings-auto.html) | [使用 EKS 自动模式控制将工作负载部署到容量预留中](auto-odcr.md) | | **节点高级安全性** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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" ``` 此节点类增加了节点上的临时存储量。 使用以下命令应用此配置： ``` kubectl apply -f nodeclass.yaml ``` 然后在节点池配置中引用该节点类。有关更多信息，请参阅 [为 EKS 自动模式创建节点池](create-node-pool.md)。 ## 创建节点类访问条目 如果您创建自定义节点类，则需要创建 EKS 访问条目以允许节点加入集群。如果您使用内置节点类和节点池，EKS 会自动创建访问条目。 有关访问条目工作原理的信息，请参阅[使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限](access-entries.md)。 为 EKS 自动模式节点类创建访问条目时，需要使用 `EC2` 访问条目类型。 ### 使用 CLI 创建访问条目 **要为 EC2 节点创建访问条目并关联 EKS 自动节点策略，请执行以下操作：** 使用集群名称和节点角色 ARN 更新以下 CLI 命令。在节点类 YAML 中指定节点角色 ARN。 ``` # 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 自动节点策略，请执行以下操作：** 使用集群名称和节点角色 ARN 更新以下 CloudFormation。在节点类 YAML 中指定节点角色 ARN。 ``` 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 中，一个节点上最多可以有 110 个容器组（pod）。此限制将在计算现有最大容器组（pod）数量之后应用。有关更多信息，请参阅 [选择最优的 Amazon EC2 节点实例类型](choosing-instance-type.md)。 + **标签** – 如果要将标签从 Kubernetes 传播到 EC2，则需要配置额外的 IAM 权限。有关更多信息，请参阅 [了解 EKS 自动模式中的身份和访问权限](auto-learn-iam.md)。 + **默认节点类** – 不要将自定义节点类命名为 `default`。这是因为 EKS 自动模式包含一个名为 `default` 的 `NodeClass`，您启用至少一个内置 `NodePool` 时，系统会自动预置该节点类。有关启用内置 `NodePools` 的信息，请参阅[启用或禁用内置节点池](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）和流量。 + 如果*同一个可用区中*有多个子网与 `subnetSelectorTerms` 匹配，则 EKS 自动模式会在分布在该可用区子网中的每个节点上创建容器组（pod）。EKS 自动模式在同一可用区内其他子网中的每个节点上创建辅助网络接口。它根据每个子网中可用 IP 地址的数量进行选择，以便更高效地使用子网。但是，您无法指定 EKS 自动模式为每个容器组（pod）使用哪个子网；如果您需要容器组（pod）在特定子网中运行，请改用 [为容器组（pod）配置独立的子网和安全组](#pod-subnet-selector)。 ## 为容器组（pod）配置独立的子网和安全组 `podSubnetSelectorTerms` 和 `podSecurityGroupSelectorTerms` 字段允许容器组（pod）在与其节点不同的子网和安全组中运行，从而实现高级联网配置。两个字段必须同时指定。这种分离增强了对网络流量路由和安全策略的控制。 **注意** 此功能不同于用于非 EKS Auto Mode 计算环境中与 AWS VPC CNI 配合使用的[容器组（pod）安全组](security-groups-for-pods.md)（SGPP）功能。EKS Auto Mode 不支持 SGPP。如需为容器组（pod）流量应用不同的安全组，请改用 `NodeClass` 中的 `podSecurityGroupSelectorTerms`。安全组在 `NodeClass` 级别生效，这意味着使用该 `NodeClass` 的节点上的所有容器组（pod）共享相同的容器组（pod）安全组。 ### 工作原理 在配置 `podSubnetSelectorTerms` 和 `podSecurityGroupSelectorTerms` 时： 1. 节点的主要 ENI 使用来自 `subnetSelectorTerms` 和 `securityGroupSelectorTerms` 的子网与安全组。该接口仅分配节点自身的 IP 地址。 1. EKS Auto Mode 在与 `podSubnetSelectorTerms` 匹配的子网中创建辅助 ENI，并附加 `podSecurityGroupSelectorTerms` 中的安全组。默认情况下，容器组（pod）IP 地址从这些辅助 ENI 中以 /28 前缀分配，当连续前缀块不可用时，自动回退到辅助 IP（/32）。如果 `advancedNetworking` 中的 `ipv4PrefixSize` 设置为 `"32"`，则仅使用辅助 IP。 1. `podSecurityGroupSelectorTerms` 中指定的安全组适用于 VPC 内的容器组（pod）流量。对于发往 VPC 之外的流量，Pod 使用节点的主 ENI（及其安全组），因为源网络地址转换 (SNAT) 会将容器组（pod）IP 转换为节点 IP。您可以通过 `NodeClass` 中的 `snatPolicy` 字段修改此行为。 ### 使用案例 在以下场景中，使用 `podSubnetSelectorTerms` 和 `podSecurityGroupSelectorTerms`： + 应用不同的安全组分别控制节点和容器组（pod）的流量。 + 需要将基础设施流量（节点间通信）与应用流量（容器组（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` 中的安全组附加到辅助 ENI，适用于 VPC 内的容器组（pod）流量。当 SNAT 启用时（默认 `snatPolicy: Random`），离开 VPC 的流量会转换为节点主 ENI 的 IP 地址，因此节点的 `securityGroupSelectorTerms` 安全组将应用于此类流量。如果您设置 `snatPolicy: Disabled`，容器组（pod）将使用自己的 IP 地址来处理所有流量，此时必须确保路由和安全组已相应配置。 + **NodeClass 级别的粒度**：容器组（pod）安全组适用于调度到使用 `NodeClass` 的节点上的所有容器组（pod） 如需为不同工作负载应用不同的安全组，请创建独立的 `NodeClass` 和 `NodePool` 资源，并使用污点、容忍度或节点选择器将工作负载调度到合适的节点。 + **降低容器组（pod）密度**：每个节点上可运行的容器组（pod）数量减少，因为节点的主网络接口预留给节点 IP，无法用于容器组（pod）。 + **子网选择器限制**：标准 `subnetSelectorTerms` 和 `securityGroupSelectorTerms` 配置不适用于容器组（pod）子网或安全组选择。 + **网络规划**：确保节点和容器组（pod）子网中有足够的 IP 地址空间，以满足工作负载需求。 + **路由配置**：验证容器组（pod）子网的路由表和网络访问控制列表（ACL）是否已针对节点和容器组（pod）子网之间的通信进行正确配置。 + **可用区**：确认已跨多个可用区创建容器组（pod）子网。如果您使用的是特定容器组（pod）子网，则该子网必须与节点子网可用区位于同一可用区中。 ## 容器组（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，因此 IPAM 服务需要更多时间在创建更多容器组（pod）时预置 IP。 ## 在 IPv6 集群中禁用 IPv6 容器组（pod）的 IPv4 出口。 默认情况下，`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 是一种有助于优化集群扩展和资源利用率的节点预置工具。借助 Karpenter 的节点池资源，您可以定义计算资源的具体要求，包括实例类型、可用区、架构和容量类型。 您无法修改内置的 `system` 和 `general-purpose` 节点池，只能启用或禁用这些节点池。有关更多信息，请参阅 [启用或禁用内置节点池](set-builtin-node-pools.md)。 借助节点池规范，您可以通过各种受支持的标签和要求对 EKS 集群的计算资源进行精细控制。其中包括用于指定 EC2 实例类别、CPU 配置、可用区、架构（ARM64/AMD64）和容量类型（竞价型或按需型）的选项。您还可以设置有关 CPU 和内存使用量的资源限制，确保集群始终遵守所需的运行界限。 EKS 自动模式利用通用的 Kubernetes 标签，从而通过一致和标准化的方法来标识节点特征。这些标签（例如用于可用区的 `topology.kubernetes.io/zone` 标签和用于 CPU 架构的 `kubernetes.io/arch` 标签）都遵循约定的 Kubernetes 规范。此外，特定于 EKS 的标签（前缀为 `eks.amazonaws.com/`）通过实例类型、CPU 制造商、GPU 功能和联网规范等 AWS 特定属性进一步扩展了此功能。这种标准化的标记系统有利于与现有 Kubernetes 工具的无缝集成，同时实现深入的 AWS 基础设施集成。 ## 创建节点池 按照以下步骤为 Amazon EKS 集群创建节点池： 1. 创建一个包含所需节点池配置的 YAML 文件并将其命名为 `nodepool.yaml`。您可以使用以下示例配置。 1. 将节点池应用到集群： ``` kubectl apply -f nodepool.yaml ``` 1. 验证节点池是否已成功创建： ``` kubectl get nodepools ``` 1. （可选）监控节点池状态： ``` kubectl describe nodepool default ``` 确认节点池引用了集群中存在的有效节点类。节点类定义了计算资源的 AWS 特定配置。有关更多信息，请参阅 [为 Amazon EKS 创建节点类](create-node-class.md)。 ## 示例节点池 ``` 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 | 使用特定虚拟机监控程序的实例类型 | | eks.amazonaws.com/compute-type | 自动 | 标识 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 | 实例内存兆比字节数 | | eks.amazonaws.com/instance-ebs-bandwidth | 9500 | 实例可用 EBS 最大[兆比特](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 | CPU 制造商的名称 | | eks.amazonaws.com/instance-gpu-count | 1 | 实例 GPU 数量 | | eks.amazonaws.com/instance-gpu-memory | 16384 | GPU 内存兆比字节数 | | eks.amazonaws.com/instance-local-nvme | 900 | 实例本地 nvme 存储空间千兆比字节数 | **注意** EKS 自动模式仅支持某些实例，并对最小大小有要求。有关更多信息，请参阅 [EKS 自动模式支持的实例参考](automode-learn-instances.md#auto-supported-instances)。 ## 不受 EKS 自动模式支持的标签 EKS 自动模式不支持以下标签。 + EKS 自动模式仅支持 Linux + `node.kubernetes.io/windows-build` + `kubernetes.io/os` ## 禁用内置节点池 如果创建自定义节点池，则可以禁用内置节点池。有关更多信息，请参阅 [启用或禁用内置节点池](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 文档中的 [Disruption](https://karpenter.sh/docs/concepts/disruption/)。 您可就以下目的配置节点池中断功能： + 发现实例未得到充分利用的情况，据此整合工作负载。 + 创建节点池中断预算，对偏移、空置和整合导致的节点终止进行速率限制。 EKS 自动模式默认会： + 整合未得到充分利用的实例。 + 在 336 小时后终止实例。 + 将单个中断预算设置为 10% 的节点。 + 允许在发布新的自动模式 AMI（约每周一次）时由于漂移而更换节点。 ## 终止宽限期 如果未在 EKS Auto NodePool 上明确定义 `terminationGracePeriod`，系统会自动对关联的 NodeClaim 应用默认的 24 小时终止宽限期。虽然 EKS Auto 客户不会在其自定义 NodePool 配置中看到默认的 `terminationGracePeriod`，但他们会在 NodeClaim 上看到这个默认值。无论是在 NodePool 上明确设置了宽限期还是在 NodeClaim 上设置了默认宽限期，该功能都保持一致，从而确保整个集群中的节点终止行为可预测。 # EKS Auto Mode 中的静态容量节点池 Amazon EKS Auto Mode 支持静态容量节点池，无论容器组（pod）需求如何，这些节点池都保持固定数量的节点。如果工作负载需要可预测容量、预留实例，或需要保持稳定的基础设施占用空间以满足特定合规性要求，静态容量节点池非常有用。 与基于容器组（pod）调度要求进行扩展的动态节点池不同，静态容量节点池会保留您配置的节点数量。 ## 配置静态容量节点池 要创建静态容量节点池，请在 NodePool 规范中设置 `replicas` 字段。`replicas` 字段定义节点池将维持的确切节点数。有关如何配置 `replicas` 的信息，请参阅 [示例](#static-capacity-examples)。 ## 静态容量节点池限制 静态容量节点池有几个重要的限制和行为： **配置限制：** + **无法切换模式**：一旦在节点池上设置了 `replicas`，就无法将其移除。节点池无法在静态和动态模式之间切换。 + **有限的资源限制**：限制部分中仅支持 `limits.nodes` 字段。CPU 和内存限制不适用。 + **无权重字段**：由于节点选择不是基于优先级，因此无法在静态容量节点池上设置 `weight` 字段。 **操作行为：** + **无整合**：静态容量池中的节点不考虑整合。 + **扩展操作**：扩展操作会绕过节点中断预算，但仍然遵守 PodDisruptionBudgets。 + **节点更换**：节点仍会因偏差（例如 AMI 更新）或因过期而被替换，具体方式取决于您的配置。 ## 最佳实践 **容量规划：** + 将 `limits.nodes` 设置为高于 `replicas`，以允许在节点替换操作期间进行临时扩展。 + 设置限制时，请考虑节点偏差或 AMI 更新期间所需的最大容量。 **实例选择：** + 如果您有预留实例或特定的硬件要求，请使用特定的实例类型。 + 避免要求过于严格，因为这可能会限制扩展期间的实例可用性。 **中断管理：** + 配置适当的中断预算，以平衡可用性与维护操作。 + 在设置预算百分比时，请考虑应用程序对节点替换的容忍度。 **监控：** + 定期监控 `status.nodes` 字段，确保保持所需容量。 + 设置警报，以了解实际节点数何时偏离所需的副本。 **可用区分布：** + 为了实现高可用性，请在多个可用区之间分布静态容量。 + 当您创建跨多个可用区的静态容量节点池时，EKS Auto Mode 会将节点分布到指定可用区，但不能保证分布均匀。 + 为了在可用区之间实现可预测且均匀的分布，请创建单独的静态容量节点池，每个节点池都根据 `topology.kubernetes.io/zone` 要求固定到特定的可用区。 + 如果您需要在 3 个可用区中均匀分布 12 个节点，请创建 3 个节点池，每个节点池包含 4 个副本，而不是在 3 个可用区中仅创建 1 个节点池，其中共 12 个副本。 ## 扩展静态容量节点池 您可以使用 `kubectl scale` 命令更改静态容量节点池中的副本数量： ``` # Scale down to 5 nodes kubectl scale nodepool static-nodepool --replicas=5 ``` 进行缩减时，EKS 自动模式将正常终止节点，同时遵守 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 Mode 中使用 EC2 容量预留的更多信息，请参阅 [使用 EKS 自动模式控制将工作负载部署到容量预留中](auto-odcr.md)。 定义 `capacityReservationSelectorTerms` 的 `NodeClass` ``` 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 ``` 引用上述 `NodeClass` 并使用 `karpenter.sh/capacity-type: reserved` 的 `NodePool` ``` 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 以配置应用程序负载均衡器 EKS 自动模式可自动执行例行负载均衡任务，包括向互联网公开集群应用程序等。 AWS 建议使用应用程序负载均衡器（ALB）来处理 HTTP 和 HTTPS 流量。应用程序负载均衡器可以根据请求的内容进行路由。有关应用程序负载均衡器的更多信息，请参阅 [What is Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) EKS 自动模式会创建和配置应用程序负载均衡器（ALB）。例如，EKS 自动模式会在您创建 `Ingress` Kubernetes 对象时创建一个负载均衡器，并配置为使用该负载均衡器来路由指向集群工作负载的流量。 **概述** 1. 创建您希望向互联网公开的工作负载。 1. 创建一个 `IngressClassParams` 资源并指定 AWS 特定的配置值，例如用于 SSL/TLS 和 VPC 子网的证书。 1. 创建一个 `IngressClass` 资源并将 EKS 自动模式指定为该资源的控制器。 1. 创建一个 `Ingress` 资源，以将某个 HTTP 路径和端口与集群工作负载关联。 EKS 自动模式将使用 `IngressClassParams` 资源中指定的负载均衡器配置，创建一个指向 `Ingress` 资源中指定工作负载的应用程序负载均衡器。 ## 先决条件 + 在 Amazon EKS 集群上启用 EKS 自动模式 + 配置好 Kubectl 以连接到集群 + 您可以使用 `kubectl apply -f ` 将以下示例配置 YAML 文件应用到集群。 **注意** EKS 自动模式需要子网标签来标识公有子网和私有子网。 如果使用 `eksctl` 创建集群，则已包含这些标签。 了解如何[为 EKS 自动模式的子网添加标签](tag-subnets-auto.md)。 ## 第 1 步：创建工作负载 首先，创建您希望向互联网公开的工作负载。这可以是任何提供 HTTP 流量的 Kubernetes 资源，例如部署或服务。 此示例使用一个名为 `service-2048`、在端口 `80` 上侦听的简单 HTTP 服务。通过应用以下 `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` 对象来指定应用程序负载均衡器的 AWS 特定配置选项。在本示例中，我们创建了一个名为 `alb` 的 `IngressClassParams` 资源（您将在下一步中使用该资源），该资源在名为 `alb-ingressclassparams.yaml` 的文件中将负载均衡器方案指定为 `internet-facing`。 ``` apiVersion: eks.amazonaws.com/v1 kind: IngressClassParams metadata: name: alb spec: scheme: internet-facing ``` 将配置应用到您的集群： ``` kubectl apply -f alb-ingressclassparams.yaml ``` ## 第 3 步：创建 IngressClass 在名为 `alb-ingressclass.yaml` 的文件中创建 `IngressClass`，它引用 `IngressClassParams` 资源中设置的 AWS 特定配置值。记下 `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 步：创建 Ingress 在名为 `alb-ingress.yaml` 的文件中创建 `Ingress` 资源。此资源的用途是将应用程序负载均衡器上的路径和端口关联到集群中的工作负载。在本示例中，我们创建了一个名为 `2048-ingress` 的 `Ingress` 资源，该资源将流量路由到端口 80 上名为 `service-2048` 的服务。 有关如何配置此资源的更多信息，请参阅 Kubernetes 文档中的 [Ingress](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 自动模式会自动删除您的 AWS 账户中关联的负载均衡器。 ## IngressClassParams 参考 下表列举了常用配置选项的快速参考。 | 字段 | 说明 | 示例值 | | --- | --- | --- | | `scheme` | 定义 ALB 是内部专用还是面向互联网 | `internet-facing` | | `namespaceSelector` | 限定可以使用此 IngressClass 的命名空间 | `environment: prod` | | `group.name` | 将多个 Ingress 分组以共享单个 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 完成。但您可以在单个 Ingress 资源上使用注解来配置负载均衡器的行为（例如 `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 负载均衡器资源。有关更多信息，请参阅 [EKS 自动模式资源的自定义 AWS 标签](auto-learn-iam.md#tag-prop)。 + 有关将资源关联到 EKS 自动模式或自主管理型 AWS 负载均衡器控制器的信息，请参阅[迁移参考](migrate-auto.md#migration-reference)。 + 有关修复负载均衡器问题的信息，请参阅 [EKS 自动模式故障排除](auto-troubleshoot.md)。 + 有关使用 EKS 自动模式的负载均衡功能时的其他注意事项，请参阅[负载均衡](auto-networking.md#auto-lb-consider)。 以下表格详细比较了 EKS 自动模式的 IngressClassParams、Ingress 注释和 TargetGroupBinding 配置的更改。这些表格重点介绍了 EKS 自动模式的负载均衡功能与开源负载均衡器控制器之间的主要区别，包括 API 版本更改、已弃用的功能和更新后的参数名称等。 ### IngressClassParams | 旧版 | New | 说明 | | --- | --- | --- | | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API 版本更改 | | `spec.certificateArn` | `spec.certificateARNs` | 支持多个证书 ARN | | `spec.subnets.tags` | `spec.subnets.matchTags` | 更改了子网匹配架构 | | `spec.listeners.listenerAttributes` | 不支持 | 尚未得到 EKS 自动模式的支持 | ### Ingress 注释 | 旧版 | New | 说明 | | --- | --- | --- | | `kubernetes.io/ingress.class` | 不支持 | 在 Ingress 对象上使用 `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 | 旧版 | New | 说明 | | --- | --- | --- | | `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 资源或集群被删除时，控制器将删除目标组。 # 使用服务注释配置网络负载均衡器 了解如何使用 Kubernetes 服务注释在 Amazon EKS 中配置网络负载均衡器（NLB）。本主题介绍 EKS 自动模式支持的用于自定义 NLB 行为的注释，包括互联网可访问性、运行状况检查、SSL/TLS 终止和 IP 目标模式。 在 EKS 自动模式下创建类型为 `LoadBalancer` 的 Kubernetes 服务时，EKS 会根据您指定的注释自动预置和配置 AWS 网络负载均衡器。借助这种声明式方法，您可以直接通过 Kubernetes 清单来管理负载均衡器配置，确保遵循基础设施即代码实践。 对于所有 LoadBalancer 类型的服务，EKS 自动模式会默认处理网络负载均衡器预置，无需额外的控制器安装或配置。`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/` | 字段 | 说明 | 示例 | | --- | --- | --- | | `aws-load-balancer-type` | 指定负载均衡器类型。新部署请使用 `external`。 | `external` | | `aws-load-balancer-nlb-target-type` | 指定是将流量路由到节点实例还是直接路由到容器组 IP。标准部署请使用 `instance`，直接路由到容器组请使用 `ip`。 | `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 Certication Manager 的适用于 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 负载均衡器资源。有关更多信息，请参阅 [EKS 自动模式资源的自定义 AWS 标签](auto-learn-iam.md#tag-prop)。 + 有关将资源关联到 EKS 自动模式或自主管理型 AWS 负载均衡器控制器的信息，请参阅[迁移参考](migrate-auto.md#migration-reference)。 + 有关修复负载均衡器问题的信息，请参阅 [EKS 自动模式故障排除](auto-troubleshoot.md)。 + 有关使用 EKS 自动模式的负载均衡功能时的其他注意事项，请参阅[负载均衡](auto-networking.md#auto-lb-consider)。 将负载均衡模式迁移到 EKS 自动模式进时，需要对服务注释和资源配置进行一些更改。下表总结了旧版和新版实现之间的主要区别，包括不支持的选项和建议的替代方案。 ### 服务注释 | 旧版 | New | 说明 | | --- | --- | --- | | `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 | 旧版 | New | 说明 | | --- | --- | --- | | `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`。您必须创建引用 `ebs.csi.eks.amazonaws.com` 的 `StorageClass`，才能使用 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` – 将卷的创建延迟到容器组需要时 + `type: gp3` – 指定 EBS 卷类型 + `encrypted: "true"` – EBS 将对使用该 `StorageClass` 创建的所有卷进行加密。EBS 将使用默认的 `aws/ebs` 密钥别名。有关更多信息，请参阅《Amazon EBS 用户指南》中的 [How Amazon EBS encryption works](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 用户指南》中的 [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) 或 [How Amazon Elastic Block Store (Amazon EBS) uses KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html)。 1. 创建一个允许访问该 KMS 密钥的新策略。 + 使用以下 IAM 策略示例来创建策略。插入新的自主管理型 KMS 密钥的 ARN。有关更多信息，请参阅《AWS IAM 用户指南》中的[创建角色并附加策略（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)。 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` 资源的 `parameters` 部分特定于 AWS。请使用下表来查看可用的选项。 | Parameters | 值 | 默认值 | 说明 | | --- | --- | --- | --- | | "csi.storage.k8s.io/fstype" | xfs、ext2、ext3、ext4 | ext4 | 将在创建卷时进行格式化的文件系统类型。此参数区分大小写！ | | "type" | io1、io2、gp2、gp3、sc1、st1、标准、sbp1、sbg1 | gp3 | EBS 卷类型。 | | "iopsPerGB" | | | 每 GiB 每秒 I/O 读写操作次数。可以为 IO1、IO2 和 GP3 卷指定。 | | "allowAutoIOPSPerGBIncrease" | true，false | false | 如果为 `"true"`，CSI 驱动程序将在 `iopsPerGB * ` 太小而无法达到 AWS 支持的 IOPS 范围时增加卷的 IOPS。这可确保动态预置始终会成功，即使用户指定的 PVC 容量或 `iopsPerGB` 值太小。不过这可能会带来额外的成本，因为此类卷的 IOPS 高于 `iopsPerGB` 中请求的值。 | | "iops" | | | 每秒 I/O 读写操作次数。可以为 IO1、IO2 和 GP3 卷指定。 | | "throughput" | | 125 | 吞吐量以 MiB/s 为单位。仅在指定 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" | | | 格式化底层文件系统时要使用的索引节点大小。仅支持 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 Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md)。 ## 注意事项 **注意** 您只能根据 EKS 自动模式节点上的 EKS 自动模式 StorageClasses 部署工作负载。如果您的集群包含混合类型的节点，则需要将工作负载配置为仅在 EKS 自动模式节点上运行。有关更多信息，请参阅 [控制工作负载是否部署在 EKS 自动模式节点上](associate-workload.md)。 EKS 自动模式的块存储功能与 EBS CSI 驱动程序不同。 + 静态预置 + 要将外部创建的 EBS 卷与 EKS 自动模式结合使用，需要手动添加键为 `eks:eks-cluster-name`，值为集群名称的 AWS 标签。 + 节点启动污点 + 在存储容量准备就绪之前，不能使用节点启动污点功能来阻止容器组调度 + 动态预置卷上的自定义标签 + 不能使用 extra-tag CLI 标志在动态预置 EBS 卷上配置自定义标签 + 可以使用 `StorageClass` 标记功能来添加自定义标签。EKS 自动模式将为关联的 AWS 资源添加标签。您需要更新自定义标签的集群 IAM 角色。有关更多信息，请参阅 [EKS 自动模式资源的自定义 AWS 标签](auto-learn-iam.md#tag-prop)。 + EBS 详细性能指标 + 您无法访问 Prometheus 指标来了解 EBS 的详细性能 ## 安装 CSI 快照控制器附加组件 EKS 自动模式与 CSI 快照控制器 Amazon EKS 附加组件兼容。 AWS 建议将此附加组件配置为在内置的 `system` 节点池上运行。 有关更多信息，请参阅： + [在专用实例上运行关键附加组件](critical-workload.md) + [启用或禁用内置节点池](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 自动模式之前忘记移除该引用，则托管式安全组将会泄露（不会被删除）。以下步骤介绍了在发生安全组泄露时如何移除泄露的安全组。 ## 禁用 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 版本。自动模式通过处理控制面板更新与节点替换之间的协调来简化版本更新过程，同时通过容器组中断预算来保持工作负载的可用性。 在升级自动模式集群时，许多传统上需要手动更新的组件现在都作为服务的一部分进行管理。了解升级过程的自动化方面以及您需要负责的方面，有助于确保集群顺利完成版本过渡。 ## 了解使用 EKS 自动模式时的更新 启动控制面板升级后，EKS 自动模式将升级集群中的节点。节点过期后，EKS 自动模式会将其替换为新节点。新节点具有相应的新 Kubernetes 版本。EKS 自动模式会在升级节点时观察容器组中断预算。 此外，您不再需要更新组件，例如： + Amazon VPC CNI + AWS Load Balancer Controller + 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)。 # 启用或禁用内置节点池 EKS 自动模式有两个内置节点池。您可以使用 AWS 控制台、CLI 或 API 启用或禁用这些节点池。 ## 内置节点池参考 + `system` + 此节点池有一个 `CriticalAddonsOnly` 污点。许多 EKS 附加组件（例如 CoreDNS）都容忍此污点。使用此系统节点池来隔离集群关键型应用程序。 + 同时支持 `amd64` 和 `arm64` 架构。 + `general-purpose` + 此节点池提供了为集群中的通用型工作负载启动节点的支持。 + 仅使用 `amd64` 架构。 同时启用两个内置节点池： + 使用默认的 EKS 节点类 + 仅使用按需型 EC2 容量 + 使用 C、M 和 R EC2 实例系列 + 需要第 5 代或更高版本的 EC2 实例 **注意** EKS 需要启用至少一个内置节点池才能配置“默认”节点类。如果禁用所有内置节点池，则需要创建自定义节点类并配置节点池才能使用它。有关节点类的更多信息，请参阅[为 Amazon EKS 创建节点类](create-node-class.md)。 ## 过程 ### 先决条件 + 已在您的设备上安装并配置了最新版本的 AWS 命令行界面（AWS CLI）。要查看当前版本，请使用 `aws --version`。要安装最新版本，请参阅《AWS 命令行界面用户指南》中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)。 + 使用创建 AWS 资源所需的充分 IAM 权限登录 CLI，包括 IAM 策略、IAM 角色和 EKS 集群等。 ### 使用 AWS CLI 启用 使用以下命令同时启用两个内置节点池： ``` 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} }' ``` 您可以修改命令以有选择地启用节点池。 ### 使用 AWS CLI 禁用 使用以下命令同时禁用两个内置节点池： ``` 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` 节点池。通过执行这些步骤，您可以利用 EKS 自动模式专用节点池结构提供的隔离和资源分配优势，确保将关键应用程序调度到专用的 `system` 节点上。 EKS 自动模式有以下两个内置节点池：`general-purpose` 和 `system`。有关更多信息，请参阅 [启用或禁用内置节点池](set-builtin-node-pools.md)。 `system` 节点池的作用是将关键附加组件隔离到不同的节点上。`system` 节点池预置的节点有一个 `CriticalAddonsOnly` Kubernetes 污点。Kubernetes 仅在具有对应的容忍度时才会将容器组调度到这些节点上。有关更多信息，请参阅 Kubernetes 文档中的[污点和容忍度](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)。 ## 先决条件 + 启用内置 `system` 节点池的 EKS 自动模式集群。有关更多信息，请参阅 [启用或禁用内置节点池](set-builtin-node-pools.md) + 安装并配置了 `kubectl`。有关更多信息，请参阅 [进行设置以使用 Amazon EKS](setting-up.md)。 ## 过程 参阅下面的示例 yaml。请注意以下配置： + `nodeSelector` – 这会将工作负载关联到内置的 `system` 节点池。必须使用 AWS API 启用此节点池。有关更多信息，请参阅 [启用或禁用内置节点池](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 自动模式支持不同类型的网络策略。 ### 第 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 的网络策略的 Stars 演示](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 自动模式中应用基于 DNS 的策略时的工作流程示意图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/apply-dns-policy-1.png) ![\[在 EKS 自动模式中应用基于 DNS 的策略时的工作流程示意图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/apply-dns-policy-2.png) 1. 平台团队将基于 DNS 的策略应用于 EKS 集群。 1. 网络策略控制器负责监控集群内策略的创建情况，然后协调策略端点。在此使用案例中，网络策略控制器指示节点代理根据创建的策略中的允许列表域筛选 DNS 请求。使用 FQDN 或与 Kubernetes 资源配置中定义的模式相匹配的域名，将域名列入允许名单。 1. 工作负载 A 尝试解析集群外部端点的 IP。DNS 请求首先通过代理，该代理根据通过网络策略应用的允许列表筛选此类请求。 1. 一旦 DNS 请求通过 DNS 筛选器允许列表，就会被传输到 CoreDNS， 1. 反过来，CoreDNS 会将请求发送到外部 DNS 解析器（Amazon Route 53 Resolver），获取域名背后的 IP 地址列表。 1. 已解析的 IP 连同 TTL 都将在对 DNS 请求的响应中返回。然后，将这些 IP 写入 eBPF 映射中，该映射用于 IP 层执行的下一步。 1. 随后，连接到容器组（pod）veth 接口的 eBPF 探测器将根据现有规则筛选从工作负载 A 到集群外部端点的出口流量。这可确保容器组（pod）只能向已加入允许列表的域 IP 发送集群外部流量。这些 IP 的有效性取决于从外部 DNS 解析器（Amazon Route 53 Resolver）检索到的 TTL。 #### 使用应用程序网络策略 `ApplicationNetworkPolicy` 使用单个自定义资源定义（CRD）在命名空间级别将标准 Kubernetes 网络策略的功能与基于 DNS 的筛选相结合。因此，`ApplicationNetworkPolicy` 可以用于： 1. 使用 IP 块和端口号定义网络堆栈第 3 层和第 4 层的限制。 1. 定义网络堆栈第 7 层运行的规则，并允许您基于 FQDN 筛选流量。 **重要** 使用 `ApplicationNetworkPolicy` 定义的基于 DNS 的规则仅适用于在 EKS Auto Mode 启动的 EC2 实例中运行的工作负载。 `ApplicationNetworkPolicy` 支持标准 Kubernetes `NetworkPolicy` 的所有字段，并为出站规则提供了额外的 FQDN 筛选器。 **警告** 请勿在同一命名空间内为 `ApplicationNetworkPolicy` 和 `NetworkPolicy` 使用相同的名称。如果名称冲突，生成的 `PolicyEndpoints` 对象可能无法正确反映任一策略。这两个资源都会正常接受而不报错，因此该问题难以诊断。 要解决命名冲突，请重命名 `ApplicationNetworkPolicy` 或 `NetworkPolicy`，使其在命名空间内唯一，然后验证对应的 `PolicyEndpoints` 对象是否已正确更新。 #### 示例 您的 EKS 自动模式集群中有一个工作负载，需要与带有 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 网络级别，这将允许来自标有 `role: backend` 的“galaxy”命名空间中的任何容器组（pod）的出口，通过 TCP 端口 8080 连接到域名 **myapp.mydomain.com**。此外，您还需要为从 VPC 到公司数据中心的出口流量设置网络连接。 ![\[EKS 自动模式中的工作负载与本地应用程序通信示意图\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/eks-auto-to-on-prem.png) ### 管理员（或集群）网络策略 ![\[EKS 中的网络策略评估顺序示意图\]](http://docs.aws.amazon.com/zh_cn/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 进行评估，然后再评估任何其他策略。在管理员层中，策略按优先级顺序处理（优先级序号最小者优先）。操作类型决定了接下来的操作。 + **Deny 操作（优先级最高）**：当具有 Deny 操作的管理员策略与流量匹配时，无论采用何种其他策略，该流量都会立即被阻止。不再处理其他 ClusterNetworkPolicy 或 NetworkPolicy 规则。这样可以确保组织范围的安全控制不会被命名空间级别的策略所覆盖。 + **Allow 操作**：评估 Deny 规则后，将按优先级顺序处理具有 Allow 操作的管理员策略（优先级序号最小者优先）。当 Allow 操作匹配时，流量将被接受，并且不再进行进一步的策略评估。这些策略可以根据标签选择器授予跨多个命名空间的访问权限，从而集中控制哪些工作负载可以访问特定资源。 + **Pass 操作**：管理员层策略中的 Pass 操作将决策委托给较低层级。当流量与 Pass 规则匹配时，评估将跳过该流量的所有剩余管理层规则，直接进入 NetworkPolicy 层。这允许管理员将某些流量模式的控制权明确委托给应用程序团队。例如，您可以使用 Pass 规则将命名空间内的流量管理委托给命名空间管理员，同时保持对外部访问权限的严格控制。 1. **网络策略层**：如果没有与 Deny 或 Allow 匹配的管理员层策略，或者匹配了 Pass 操作，则接下来将评估命名空间范围的 ApplicationNetworkPolicy 和传统 NetworkPolicy 资源。这些策略在各个命名空间内提供精细的控制，并由应用程序团队管理。命名空间范围的策略只能比管理员策略更严格。它们无法覆盖管理员策略的 Deny 决策，但可以进一步限制管理员策略允许或通过的流量。 1. **基准层管理员策略**：如果没有管理员或命名空间范围的策略与流量匹配，则会评估基准层 ClusterNetworkPolicies。它们提供了可以被命名空间范围的策略覆盖的默认安全状况，允许管理员设置组织范围的默认值，同时让团队可以灵活地根据需要进行自定义。基准策略按优先级顺序进行评估（优先级序号最小者优先）。 1. **默认拒绝（如果没有匹配的策略）**：这种默认拒绝行为可确保仅允许明确允许的连接，从而保持稳固的安全状况。 ### 应用最低权限原则 + **从限制性策略开始，然后根据需要逐步添加权限**：首先在集群级别实施默认拒绝策略，然后在验证合法的连接要求时，逐步添加允许规则。这种方法迫使团队明确证明每个外部连接的合理性，从而打造更加安全且可审计的环境。 + **定期审计并删除未使用的策略规则**：随着应用程序的发展，网络策略可能会随着时间的推移而积累，所留下的过时规则会不必要地扩大攻击面。实施定期审查流程，以确定并删除不再需要的策略规则，确保您的安全状况保持严密且可维护。 + **尽可能使用特定的域名而不是宽泛的模式**：虽然像 `*.amazonaws.com` 这类通配符模式提供了便利，但这也会授予对各种服务的访问权限。只要可行，请指定如 `s3.us-west-2.amazonaws.com` 等确切的域名，仅允许访问应用程序所需的特定服务，从而降低工作负载遭盗用时横向移动的风险。 ### 在 EKS 中使用基于 DNS 的策略 + 使用 `ApplicationNetworkPolicy` 定义的基于 DNS 的规则仅适用于在 EKS 自动模式启动的 EC2 实例中运行的工作负载。如果您运行的是混合模式集群（由 EKS 自动模式和非 EKS 自动模式 Worker 节点组成），则基于 DNS 的规则仅在 EKS 自动模式 Worker 节点（EC2 托管实例）中有效。 ### 验证 DNS 策略 + **使用与生产网络拓扑结构相同的暂存集群进行测试**：您的暂存环境应复制生产的网络架构、外部依赖关系和连接模式，确保进行准确的策略测试。这包括相同的 VPC 配置、DNS 解析行为以及访问生产工作负载所需的相同外部服务。 + **对关键网络路径实施自动测试**：构建自动化测试，验证与基本外部服务的连接（作为 CI/CD 管道的一部分）。这些测试应验证在阻止未经授权的连接的同时是否允许合法的流量，从而持续验证随着基础设施的演变，您的网络策略是否仍能保持理想的安全状况。 + **在策略更改后监控应用程序行为**：将新的或经修改的网络策略部署到生产环境后，密切监控应用程序日志、错误率和性能指标，以此快速识别任何连接问题。制定明确的回滚程序，以便在策略更改导致意外应用程序行为或服务中断时可以快速还原这些更改。 ### 与 Amazon Route 53 DNS 防火墙互动 当流量启动时，首先在容器组（pod）级别评估 EKS 管理员和网络策略。如果 EKS 网络策略允许出口到特定域，则该容器组（pod）随后会执行 DNS 查询，其随后会到达 Route 53 解析器。此时，将对 Route 53 的 DNS 防火墙规则进行评估。如果 DNS 防火墙阻止域查询，那么即使 EKS 网络策略允许 DNS 解析失败，也无法建立连接。这创建了互补的安全层：基于 EKS DNS 的网络策略为应用程序特定的访问要求和多租户安全边界提供容器组（pod）级别的出口控制，而 DNS 防火墙则提供 VPC 范围内针对已知恶意域的保护，并强制执行组织范围的阻止名单。 # 为 EKS 自动模式的子网添加标签 如果您使用 EKS 自动模式的负载均衡功能，则需要向 VPC 子网添加 AWS 标签。 ## 背景 这些标签可将子网标识为与集群相关联，更重要的是能标识出子网是公有子网还是私有子网。 公有子网可以通过互联网网关直接访问互联网。此类子网用于需要可公开访问的资源，例如负载均衡器。 私有子网无法直接访问互联网，需使用 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 ``` 将 `subnet-ID` 替换为您的实际子网 ID。 # 使用 kubectl debug 从 Kubernetes 节点生成 CIS 合规性报告 本主题介绍如何使用 `kubectl debug` 命令，为 Amazon EKS 节点生成 CIS（Center for Internet Security）合规性报告。该命令允许您在 Kubernetes 节点上临时创建调试容器，并使用 `apiclient` 工具运行 CIS 合规性检查。`apiclient` 工具是 Bottlerocket 操作系统（EKS 自动模式节点使用的操作系统）中的一部分。 ## 先决条件 在开始之前，请确保您满足以下条件： + 访问已配置 `kubectl` 的 Amazon EKS 集群（版本必须至少为 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 Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)。 ## 相关资源 + Bottlerocket 操作系统文档中的 [Bottlerocket CIS Benchmark](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 Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) # 在 EKS 自动模式下使用客户自主管理型 KMS 密钥启用 EBS 卷加密 您可以使用客户自主管理型 KMS 密钥对 EKS 自动模式实例的临时根卷进行加密。 在管理 Kubernetes 集群的加密 EBS 卷时，Amazon EKS 自动模式使用服务相关角色向其他 AWS 服务委派权限。本主题介绍当您为 Amazon EBS 加密指定客户自主管理型密钥时，如何设置所需的密钥策略。 注意事项： + EKS 自动模式无需额外授权，即可使用默认的 AWS 托管式密钥来保护您账户中的加密卷。 + 本主题介绍加密临时卷，即 EC2 实例的根卷。有关加密用于工作负载的数据卷的更多信息，请参阅[创建存储类](create-storage-class.md)。 ## 概述 以下 AWS KMS 密钥可在 EKS 自动模式启动实例时用于加密 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` 必须具有使用该 KMS 密钥执行加密操作所需的 IAM 权限 + `kms:GrantIsForAWSResource` 条件可确保只能为 AWS 服务创建授权 ## 第 2 步：使用客户自主管理型密钥配置节点类 配置密钥策略后，在 EKS 自动模式的节点类配置中引用该 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 应用节点类配置： ``` 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 来限制可以启动的亚马逊机器映像（AMI）。要使 EKS 自动模式可以正常工作，请修改 SCP 以允许从 EKS 自动模式账户启动 AMI。 您还可以使用 [EC2 允许的 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) 功能来限制其他账户中 AMI 的可见性。如果您使用此功能，则必须扩展映像标准，以包含感兴趣区域中的 EKS 自动模式 AMI 账户。 ## 示例 SCP：阻止除 EKS 自动模式 AMI 外的所有 AMI 除非 AMI 属于 us-west-2 或 us-east-1 的 EKS 自动模式 AMI 账户，否则以下 SCP 会阻止调用 `ec2:RunInstances`。 **注意** 切**勿**使用 `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 自动模式公有 AMI。 | | | | --- |--- | | AWS 区域 | Account | | 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）和适用于机器学习的 EC2 容量块。 **提示** 默认情况下，EKS Auto Mode 可以通过开放匹配在开放 ODCR 中启动实例，但不会优先考虑这些 ODCR。通过开放匹配启动的实例会被标记为 `karpenter.sh/capacity-type: on-demand`，而不是 `reserved`。要优先使用 ODCR 并标记实例 `karpenter.sh/capacity-type: reserved`，请在 NodeClass 定义中配置 `capacityReservationSelectorTerms`。机器学习容量块始终需要 `capacityReservationSelectorTerms`，并且不会自动使用。 ## EC2 按需容量预留（ODCR） 通过使用 EC2 按需容量预留（ODCR），您可以在特定可用区中为 Amazon EC2 实例预留计算容量达任意持续时间。使用 EKS 自动模式时，您可能想要控制是否将 Kubernetes 工作负载部署到这些预留实例上，以最大限度地利用预先购买的容量，或确保关键工作负载能够访问有保障的资源。 默认情况下，EKS 自动模式会在开放式 ODCR 中自动启动。但是，通过在 NodeClass 上配置 `capacityReservationSelectorTerms`，您可以显式控制工作负载使用的 ODCR。使用已配置的 ODCR 预置的节点将具有 `karpenter.sh/capacity-type: reserved` 并优先于按需和竞价型节点。启用此功能后，EKS 自动模式将不再自动使用开放式 ODCR – 其必须由 NodeClass 显式选择，这样您就可以精确控制集群中的容量预留使用情况。 **警告** 如果在集群中的 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 的方法。第一种方法通过其 ID（`cr-56fac701cc1951b03`）直接引用特定 ODCR。第二种方法使用基于标签的选择，目标是带有标签 `Name: "targeted-odcr"` 的 ODCR。您还可以选择按拥有预留的 AWS 账户进行筛选，这在跨账户场景或使用共享容量预留时特别有用。 ## 适用于机器学习的 EC2 容量块 机器学习容量块允许您在未来预留基于 GPU 的加速型计算实例，以支持短期机器学习（ML）工作负载。在容量块内运行的实例会自动紧密放置在 Amazon EC2 UltraClusters 中，以实现低延迟、PB 级非阻塞联网。 有关受支持的平台和实例类型的更多信息，请参阅《EC2 用户指南》中的 [ML 容量块](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)。 您可以创建使用机器学习容量块的 EKS 自动模式 NodeClass，类似于 ODCR（如前所述）。 以下示例定义创建了三个资源： 1. 引用容量块预留的 NodeClass 1. 使用 NodeClass 并应用污点的 NodePool 1. 可以容忍污点并请求 GPU 资源的容器组（pod）规范 ### 示例 NodeClass 此 NodeClass 通过其预留 ID 来引用特定机器学习容量块。您可以从 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` 来使用预留容量 + 其请求适用于机器学习工作负载的特定 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 上人工智能/机器学习工作负载的计算资源](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 自动模式节点部署到 Local Zones EKS 自动模式通过自动节点预置简化了集群管理。AWSLocal Zones 将 AWS 基础设施扩展到离最终用户更近的地理位置，从而减少延迟敏感型应用程序的延迟。本指南将引导您完成将 EKS 自动模式节点部署到 AWS Local Zones 的过程，您随后便能以更低的延迟为特定地理区域的用户运行容器化应用程序。 本指南还演示了如何使用 Kubernetes 污点和容忍度来确保只有特定的工作负载在 Local Zone 节点上运行，从而帮助您控制成本和优化资源使用。 ## 先决条件 在开始将 EKS 自动模式节点部署 Local Zones 之前，请确保已满足以下先决条件： + [现有的 EKS 自动模式集群](create-auto.md) + [在您的 AWS 账户中已选择加入 Local Zone](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone) ## 步骤 1：创建 Local Zone 子网 将 EKS 自动模式节点部署到 Local Zone 的第一步是在该 Local Zone 中创建子网。该子网为您的节点提供网络基础设施，并允许它们与 VPC 的其余部分进行通信。按照《AWS Local Zones 用户指南》中的[创建 Local Zone 子网](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet)说明，在您选择的 Local Zone 中创建子网。 **提示** 记下您的 Local Zone 子网的名称。 ## 步骤 2：为 Local Zone 子网创建 NodeClass 创建 Local Zone 子网后，您需要定义一个引用该子网的 NodeClass。NodeClass 是一种 Kubernetes 自定义资源，用于指定节点的基础设施属性，包括要使用的子网、安全组和存储配置。在下面的示例中，我们创建了一个名为“local-zone”的 NodeClass，它根据 Local Zone 子网的名称对其进行定位。您也可以使用子网 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 和污点创建 NodePool 配置好 NodeClass 后，您现在需要创建一个使用此 NodeClass 的 NodePool。NodePool 定义节点的计算特征，包括实例类型。NodePool 使用 NodeClass 作为参考，以确定在何处启动实例。 在下面的示例中，我们创建了一个引用“local-zone”NodeClass 的 NodePool。我们还将污点添加到节点，确保只有容忍度匹配的容器组（pod）才能在这些 Local Zone 节点上被调度。这对于 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：部署具有容忍度和节点亲和性的工作负载 要对 Local Zone 节点上的工作负载放置进行最佳控制，请同时使用污点/容忍度和节点亲和性。此组合方法具有以下优势： 1. **成本控制**：污点可确保只有具有明确容忍度的容器组（pod）才能使用可能较为昂贵的 Local Zone 资源。 1. **保证放置**：节点亲和性可确保您的延迟敏感型应用程序仅在 Local Zone 中运行，而不是在常规集群节点上运行。 以下是配置为专门在 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. **容忍度**允许将容器组（pod）在带有 `aws.amazon.com/local-zone` 污点的节点上调度。 1. **节点亲和性**要求可确保这些容器组（pod）只能在带有 `node-type: local-zone` 标签的节点上运行。 它们共同确保您的延迟敏感型应用程序仅在 Local Zone 节点上运行，并且除非明确配置为使用 Local Zone 资源，否则常规应用程序不会消耗 Local Zone 资源。 ## 步骤 5：使用 AWS 控制台验证 设置 NodeClass、NodePool 和 Deployments 后，您应验证节点是否按预期在 Local Zone 中预置，并且您的工作负载是否正在这些节点上运行。您可以使用 AWS 管理控制台验证 EC2 实例是否在正确的 Local Zone 子网中启动。 此外，您可以使用 `kubectl get nodes -o wide` 查看 Kubernetes 节点列表，确认这些节点是否以正确的标签和污点加入集群： ``` 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 自动模式节点配置高级安全设置。 ## 先决条件 在开始之前，请确保您满足以下条件： + 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 验证的加密模块的 AMI 预置节点。此设置选择符合 FIPS 的 AMI；客户需负责管理其相关的合规性要求。有关更多信息，请参阅 [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 的 AMI 在 AWS 美国东部/西部、AWS GovCloud（美国）和 AWS 加拿大（中部/西部）区域可用。有关更多信息，请参阅 [AWS FIPS 合规性](https://aws.amazon.com/compliance/fips/)。 + 使用 `kernelLockdown: "integrity"` 时，请确保您的工作负载不需要加载未签名的内核模块或修改内核内存。 ## 相关资源 + [为 Amazon EKS 创建节点类](create-node-class.md)：完整的节点类配置指南 + [为 EKS 自动模式创建节点池](create-node-pool.md)：节点池配置