View a markdown version of this page

EKS 数据平面 - Amazon EKS
建议

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

EKS 数据平面

要运行高可用性和弹性的应用程序，您需要一个高可用性和弹性的数据平面。弹性数据平面确保 Kubernetes 可以自动扩展和修复您的应用程序。弹性数据平面由两个或更多工作节点组成，可以随着工作负载而增长和缩小，并自动从故障中恢复。

对于使用 EKS 的工作节点，您有多种选择：EK S 自动模式托管节点、 EC2 实例和 Fargate 。

EKS 自动模式提供了通往弹性数据平面的最简单途径。自动模式将 AWS 对 Kubernetes 集群的管理扩展到集群本身之外，从而允许 AWS 设置和管理基础设施，使您的工作负载能够顺利运行。随着 Kubernetes 扩展 Pod，自动模式会自动向上或向下扩展数据平面，并不断确保集群中节点的大小适当、经济实惠，适合当前运行的工作负载。

如果您选择 EC2 实例，则可以自己管理工作节点或使用 EKS 托管节点组。你可以让集群混合使用自动模式、托管、自我管理的工作节点和 Fargate。

Fargate 在隔离的计算环境中运行每个 Pod。在 Fargate 上运行的每个 Pod 都有自己的工作节点。随着 Kubernetes 扩展 pod，Fargate 会自动缩放数据平面。您可以使用水平 pod 自动扩缩器来扩展数据平面和工作负载。

扩展 EC2 工作节点的首选方式（如果不使用由 AWS 自动执行的 EKS 自动模式）是使用 Karpenter 、K ubernetes 集群自动扩缩器或 EC2 Auto Scaling 组。 https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html

建议

将工作节点和工作负载分散到多个可用区

您可以通过在多个可用区中运行工作节点和 Pod 来保护工作负载免受单个可用区出现故障的影响。您可以使用您在其中创建节点的子网来控制创建工作节点的可用区。

跨可用区分布 Pod 的推荐方法是对 Pod 使用拓扑分布约束。 Auto-scaling EKS 自动模式和 Karpenter 等功能可以识别拓扑分布限制，并将自动在正确的可用区中启动节点以满足您的约束。

如果可能，下面的部署将容器分散到各个可用区，如果不是，则让这些 pod 无论如何都能运行：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          whenUnsatisfiable: ScheduleAnyway
          topologyKey: topology.kubernetes.io/zone
          labelSelector:
            matchLabels:
              app: web-server
      containers:
      - name: web-app
        image: nginx
        resources:
          requests:
            cpu: 1
注意

kube-scheduler只能通过带有这些标签的节点知道拓扑域。如果将上述部署部署到节点仅位于单个区域的集群，则所有 Pod 都将在这些节点上调度，因为kube-scheduler他们不知道其他区域。为了使这种拓扑分布在调度器中按预期运行，节点必须已经存在于所有区域中。拓扑分布约束的minDomains属性用于向调度器告知符合条件的域的数量，即使那里有节点正在运行以避免此问题。

警告

如果无法whenUnsatisfiable满足拓扑分布限制，则设置为DoNotSchedule将导致 pod 无法调度。只有当 pod 最好不运行而不是违反拓扑分布限制时，才应设置它。

在旧版本的 Kubernetes 上，你可以使用容器反关联性规则在多个可用区中调度 Pod。下面的清单告知 Kubernetes 调度器更倾向于在不同的可用区中调度 pod。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
  labels:
    app: web-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: failure-domain.beta.kubernetes.io/zone
            weight: 100
      containers:
      - name: web-app
        image: nginx
警告

不要要求将容器调度到不同的可用区中，否则，部署中的容器数量永远不会超过可用区的数量。

使用 EBS 卷时，确保能够在每个可用区启动节点

如果您使用 Amazon EBS 提供永久卷，则需要确保容器和关联的 EBS 卷位于同一个可用区。Pod 无法访问位于不同可用区的 EBS-backed 永久卷。Kubernetes 调度器根据工作节点上的标签知道工作节点位于哪个可用区，并且将始终调度需要与该卷位于同一个可用区中的 EBS 卷的 Pod。但是，如果卷所在的可用区中没有可用的工作节点，则无法调度 Pod。

如果使用 EKS 自动模式或 Karpenter，则需要确保在每个可用区 NodeClass 中选择子网。如果使用托管节点组，则需要确保在每个可用区中都有一个节点组。

EBS 存储功能内置于 EKS 自动模式中，但如果使用 Karpenter 或托管节点组，还需要安装 EBS CSI。

使用 EKS 自动模式管理工作节点

EKS 自动模式通过以最小的运营开销提供生产就绪集群来简化 EKS 管理。自动模式负责根据集群中运行的 Pod 向上或向下扩展节点的数量。节点会自动获得最新的软件补丁和修复，更新是根据配置的中NodePool断设置和 Pod 中断预算执行的。

运行节点监控代理

节点监控代理通过发布 Kubernetes 事件和更新节点的状态状态来监控和应对节点运行状况问题。节点监控代理包含在 EKS 自动模式节点中，对于不受自动模式管理的节点，可以作为 EKS 插件安装。

EKS 自动模式、托管节点组和 Karpenter 都能够检测节点监控代理报告的致命节点状况，并在出现这些情况时自动修复这些节点。

实现 QoS

对于关键应用程序，可以考虑为 Pod 中的容器定义 requests = limits。这将确保在另一个 Pod 请求资源时容器不会被杀死。

最佳做法是对所有容器实施 CPU 和内存限制，因为这样可以防止容器无意中消耗系统资源，从而影响其他托管进程的可用性。

为所有工作负载配置和调整资源 Requests/Limits 大小

一些一般指导可以应用于确定资源请求的大小和工作负载限制：

  • 不要指定 CPU 的资源限制。在没有限制的情况下，请求充当容器获得的相对 CPU 时间的权重。这使您的工作负载能够使用完整的 CPU，而不会出现人为限制或饥饿。

  • 对于非 CPU 资源，配置 requests = limits 提供了最可预测的行为。如果requests！=limits，容器的 QoS 也从 “保证” 降低为 Burstable，因此在节点压力下更有可能被驱逐。https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/

  • 对于非 CPU 资源，请勿指定比请求大得多的限制。相对于配置越大 limitsrequests，节点过度占用的可能性就越大，从而导致工作负载中断的几率很高。

  • 在使用 Karpenter 或 Cluster 等节点自动扩展解决方案时，正确大小的请求尤为重要。 AutoScaler 这些工具会查看您的工作负载请求，以确定要配置的节点的数量和大小。如果您的请求过小且限制更大，则如果您的工作负载紧密地打包在节点上，则可能会发现工作负载被驱逐或OOM终止。

确定资源请求可能很困难，但是像 Vertic al Pod Autoscaler 这样的工具可以通过观察运行时容器资源的使用情况来帮助你 “调整请求的大小”。其他可能有助于确定请求大小的工具包括：

为命名空间配置资源配额

命名空间适用于众多用户分散在多个团队或项目中的环境。它们提供了名称范围，也是在多个团队、项目、工作负载之间划分集群资源的一种方式。您可以限制命名空间中的总资源消耗。该ResourceQuota对象可以按类型限制可以在命名空间中创建的对象数量，以及该项目中的资源可能消耗的计算资源总量。您可以限制在给定命名空间中可以请求的存储 and/or 计算（CPU 和内存）资源的总和。

如果为 CPU 和内存等计算资源的命名空间启用了资源配额，则用户必须为该命名空间中的每个容器指定请求或限制。

考虑为每个命名空间配置配额。考虑使用自动LimitRanges将预配置的限制应用于命名空间内的容器。

限制命名空间内容器资源的使用

资源配额有助于限制命名空间可以使用的资源量。该LimitRange对象可以帮助您实现容器可以请求的最小和最大资源。使用LimitRange可以为容器设置默认请求和限制，如果设置计算资源限制不是组织中的标准做法，这会很有用。顾名思义，LimitRange可以强制命名空间中每个 Pod 或容器的最小和最大计算资源使用量。此外，在命名空间 PersistentVolumeClaim 中强制执行每个的最小和最大存储请求。

考虑结合使用ResourceQuota来LimitRange在容器和命名空间级别强制执行限制。设置这些限制将确保容器或命名空间不会影响集群中其他租户使用的资源。

使用 NodeLocal DNSCache

您可以通过运行 DNS NodeLocal Cache 来提高集群 DN S 性能。此功能在群集节点上以以下方式运行 DNS 缓存代理DaemonSet。所有 pod 都使用节点上运行的 DNS 缓存代理来解析名称，而不是使用kube-dns服务。此功能自动包含在 EKS 自动模式中。

配置自动扩展 CoreDNS

提高集群 DNS 性能的另一种方法是启用 CoreDNS Pod 的内置自动扩展功能。

此功能持续监控集群状态，包括节点和 CPU 内核的数量。控制器会根据这些信息，动态调整 EKS 集群中 CoreDNS 部署的副本数量。