EKS 自动模式中的静态容量节点池 - Amazon EKS
基本示例配置静态容量节点池静态容量节点池限制扩展静态容量节点池监控静态容量节点池示例配置最佳实践问题排查
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

帮助改进此页面

要帮助改进本用户指南，请选择位于每个页面右侧窗格中的在 GitHub 上编辑此页面链接。

EKS 自动模式中的静态容量节点池

Amazon EKS 自动模式支持静态容量节点池，无论容器组（pod）需求如何，这些节点池都保持固定数量的节点。如果工作负载需要可预测容量、预留实例，或需要保持稳定的基础设施占用空间以满足特定合规性要求，静态容量节点池非常有用。

与基于容器组（pod）调度要求进行扩展的动态节点池不同，静态容量节点池会保留您配置的节点数量。

基本示例

这是一个简单的静态容量节点池，其中维持了 5 个节点：

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: my-static-nodepool
spec:
  replicas: 5  # Maintain exactly 5 nodes

  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["m", "c"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b"]

  limits:
    nodes: 8

配置静态容量节点池

要创建静态容量节点池，请在 NodePool 规范中设置 replicas 字段。replicas 字段定义节点池将维持的确切节点数。

静态容量节点池限制

静态容量节点池有几个重要的限制和行为：

配置限制：

  • 无法切换模式：一旦在节点池上设置了 replicas，就无法将其移除。节点池无法在静态和动态模式之间切换。

  • 有限的资源限制：限制部分中仅支持 limits.nodes 字段。CPU 和内存限制不适用。

  • 无权重字段：由于节点选择不是基于优先级，因此无法在静态容量节点池上设置 weight 字段。

操作行为：

  • 无整合：静态容量池中的节点不会根据利用率被纳入整合范围。

  • 扩展操作：扩展操作会绕过节点中断预算，但仍然遵守 PodDisruptionBudgets。

  • 节点更换：节点仍会因偏差（例如 AMI 更新）或因过期而被替换，具体方式取决于您的配置。

扩展静态容量节点池

您可以使用 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 数量相匹配。

示例配置

基本静态容量节点池

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%

最佳实践

容量规划。

  • 将 limits.nodes 设置为高于 replicas，以允许在节点替换操作期间进行临时扩展。

  • 设置限制时，请考虑节点偏差或 AMI 更新期间所需的最大容量。

实例选择：

  • 如果您有预留实例或特定的硬件要求，请使用特定的实例类型。

  • 避免要求过于严格，因为这可能会限制扩展期间的实例可用性。

中断管理：

  • 配置适当的中断预算，以平衡可用性与维护操作。

  • 在设置预算百分比时，请考虑应用程序对节点替换的容忍度。

监控

  • 定期监控 status.nodes 字段，确保保持所需容量。

  • 设置警报，以了解实际节点数何时偏离所需的副本。

可用区分布：

  • 为了实现高可用性，请在多个可用区之间分布静态容量。

  • 当您创建跨多个可用区的静态容量节点池时，EKS 自动模式会将节点分布到指定可用区，但不能保证分布均匀。

  • 为了在可用区之间实现可预测且均匀的分布，请创建单独的静态容量节点池，每个节点池都根据 topology.kubernetes.io/zone 要求固定到特定的可用区。

  • 如果您需要在 3 个可用区中均匀分布 12 个节点，请创建 3 个节点池，每个节点池包含 4 个副本，而不是在 3 个可用区中仅创建 1 个节点池，其中共 12 个副本。

问题排查

节点未到达所需的副本数：

  • 检查 limits.nodes 值是否足够

  • 确认您的要求不会过度限制实例选择

  • 查看您正在使用的实例类型和区域的 Amazon 服务配额

节点替换花费的时间太长：

  • 调整中断预算，允许更多并发替换

  • 检查 PodDisruptionBudgets 是否阻止了节点终止

节点意外终止：

  • 检查 expireAfter 和 terminationGracePeriod 设置

  • 检查是否存在手动节点终止或 Amazon 维护事件