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

集群升级的最佳实践

本指南向集群管理员展示了如何计划和执行其 Amazon EKS 升级策略。它还描述了如何升级自管理节点、托管节点组、Karpenter 节点和 Fargate 节点。它不包括有关 EKS Anywhere、自我管理的 Kubernetes、AWS Outposts 或 AWS 本地区域的指南。

概述

Kubernetes 版本包括控制平面和数据平面。为确保平稳运行，控制平面和数据平面都应运行相同的 Kubernetes 次要版本，例如 1.24。虽然 AWS 管理和升级控制平面，但更新数据平面中的工作节点是您的责任。

升级之前

如果你计划在亚马逊 EKS 中升级 Kubernetes 版本，在开始升级之前，你应该制定一些重要的政策、工具和程序。

让您的集群保持最新状态

保持最新的 Kubernetes 更新对于安全高效的 EKS 环境至关重要，这反映了亚马逊 EKS 的分担责任模式。通过将这些策略集成到您的运营工作流程中，您可以将自己定位为维护最新、安全的集群，充分利用最新功能和改进。战术：

查看 EKS 发布日历

查看 EKS Kubernetes 发布日历，了解新版本何时推出以及对特定版本的支持何时结束。通常，EKS 每年发布三个次要版本的 Kubernetes，每个次要版本的支持期约为 14 个月。

此外，请查看上游 Kubernetes 的发布信息。

了解分担责任模型如何应用于集群升级

您负责启动集群控制平面和数据平面的升级。了解如何启动升级。当您启动集群升级时，AWS 会管理集群控制平面的升级。你负责升级数据平面，包括 Fargate 吊舱和插件。您必须验证和规划集群上运行的工作负载的升级，以确保集群升级后其可用性和操作不受影响

就地升级集群

EKS 支持就地集群升级策略。这样可以维护集群资源，并保持集群配置的一致性（例如，API 终端节点、OIDC、ENI、负载均衡器）。这对集群用户的干扰较小，它将使用集群中的现有工作负载和资源，而无需您重新部署工作负载或迁移外部资源（例如 DNS、存储）。

执行就地集群升级时，请务必注意，一次只能执行一次次要版本升级（例如，从 1.24 到 1.25）。

这意味着，如果您需要更新多个版本，则需要进行一系列连续升级。规划连续升级更加复杂，停机风险也更高。在这种情况下，请参阅评估 Blue/Green 集群作为就地集群升级的替代方案。

按顺序升级您的控制平面和数据平面

要升级集群，您需要采取以下操作：

使用 EKS 文档创建升级清单

EKS Kubernetes 版本文档包括每个版本的详细变更列表。为每次升级创建清单。

有关具体的 EKS 版本升级指南，请查看文档，了解每个版本的显著更改和注意事项。

使用 Kubernetes API 升级插件和组件

在升级集群之前，您应该了解所使用的 Kubernetes 组件的版本。清点集群组件，并确定直接使用 Kubernetes API 的组件。这包括关键集群组件，例如监控和日志代理、集群自动扩缩器、容器存储驱动程序（例如 EBS CSI 、E FS CSI）、入口控制器以及任何其他直接依赖于 Kubernetes API 的工作负载或插件。

kubectl get ns | grep '-system'

确定依赖于 Kubernetes API 的组件后，请查看其文档以了解版本兼容性和升级要求。例如，有关版本兼容性，请参阅 AWS 负载均衡器控制器文档。在继续群集升级之前，可能需要升级某些组件或更改配置。需要检查的一些关键组件包括 CoreDNS 、 kube-proxy 、 VPC CNI 和存储驱动程序。

集群通常包含许多使用 Kubernetes API 的工作负载，是入口控制器、持续交付系统和监控工具等工作负载功能所必需的。升级 EKS 集群时，还必须升级插件和第三方工具，以确保它们兼容。

请参阅以下常见插件示例及其相关升级文档：

升级前验证基本的 EKS 要求

AWS 需要您的账户中的某些资源才能完成升级过程。如果这些资源不存在，则无法升级集群。控制平面升级需要以下资源：

验证可用的 IP 地址

为了升级集群，Amazon EKS 需要您在创建集群时指定的子网中的最多 5 个可用的 IP 地址。

要验证您的子网是否有足够的 IP 地址来升级集群，您可以运行以下命令：

CLUSTER=<cluster name>
aws ec2 describe-subnets --subnet-ids \
  $(aws eks describe-cluster --name ${CLUSTER} \
  --query 'cluster.resourcesVpcConfig.subnetIds' \
  --output text) \
  --query 'Subnets[*].[SubnetId,AvailabilityZone,AvailableIpAddressCount]' \
  --output table

----------------------------------------------------
|                  DescribeSubnets                 |
+---------------------------+--------------+-------+
|  subnet-067fa8ee8476abbd6 |  us-east-1a  |  8184 |
|  subnet-0056f7403b17d2b43 |  us-east-1b  |  8153 |
|  subnet-09586f8fb3addbc8c |  us-east-1a  |  8120 |
|  subnet-047f3d276a22c6bce |  us-east-1b  |  8184 |
+---------------------------+--------------+-------+

VPC CNI 指标助手可用于为 VPC 指标创建 CloudWatch 控制面板。如果您在创建集群时最初指定的子网中的 IP 地址不足，Amazon EKS 建议您在开始 Kubernetes 版本升级之前使用 UpdateClusterConfiguration “” API 更新集群子网。请验证将向您提供的新子网：

如果现有 VPC CIDR 区块中的 IP 地址用完，请考虑关联额外的 CIDR 块。AWS 允许将其他 CIDR 区块与您现有的集群 VPC 关联，从而有效地扩展您的 IP 地址池。这种扩展可以通过引入额外的私有 IP 范围（RFC 1918）或在必要时引入公有 IP 范围（非 RFC 1918）来实现。您必须添加新的 VPC CIDR 区块并允许 VPC 刷新完成，然后亚马逊 EKS 才能使用新的 CIDR。之后，您可以根据新设置的 CIDR 区块向 VPC 更新子网。

验证 EKS IAM 角色

要验证 IAM 角色是否可用且您的账户中有正确的代入角色策略，您可以运行以下命令：

CLUSTER=<cluster name>
ROLE_ARN=$(aws eks describe-cluster --name ${CLUSTER} \
  --query 'cluster.roleArn' --output text)
aws iam get-role --role-name ${ROLE_ARN##*/} \
  --query 'Role.AssumeRolePolicyDocument'

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

迁移到 EKS Add-ons

亚马逊 EKS 会自动安装插件，例如适用于 Kubernetes 的 Amazon VPC CNI 插件和每个集群的 CoreDNS。kube-proxyAdd-ons 可以自行管理，也可以作为亚马逊 EKS Add-ons 安装。亚马逊 EKS Add-ons 是使用 EKS API 管理插件的另一种方式。

您可以使用 Amazon EKS Add-ons 通过单个命令更新版本。例如：

aws eks update-addon —cluster-name my-cluster —addon-name vpc-cni —addon-version version-number \
--service-account-role-arn arn:aws:iam::111122223333:role/role-name —configuration-values '{}' —resolve-conflicts PRESERVE

通过以下方式检查你是否 Add-ons 有 EKS：

aws eks list-addons --cluster-name <cluster name>

详细了解哪些组件可用作 EKS Add-ons 以及如何开始。

学习如何向 EKS 提供自定义配置 Add-on。

在升级控制平面之前，识别并修复已删除的 API 使用情况

在升级 EKS 控制平面之前，您应该确定已移除的 API 的 API 使用情况。为此，我们建议使用可以检查正在运行的集群或静态渲染的 Kubernetes 清单文件的工具。

对静态清单文件进行检查通常更准确。如果针对实时集群运行，这些工具可能会返回误报。

过时的 Kubernetes API 并不意味着该 API 已被移除。您应该查看 Kubernetes 弃用政策，以了解移除 API 会如何影响您的工作负载。

集群见解

集群见解是一项功能，可提供有关可能影响将 EKS 集群升级到更新版本的 Kubernetes 的能力的问题的发现。这些发现由亚马逊 EKS 策划和管理，并就如何修复这些发现提供了建议。通过利用集群见解，您可以最大限度地减少升级到新的 Kubernetes 版本所花费的精力。

要查看 EKS 集群的见解，您可以运行以下命令：

aws eks list-insights --region <region-code> --cluster-name <my-cluster>

{
    "insights": [
        {
            "category": "UPGRADE_READINESS",
            "name": "Deprecated APIs removed in Kubernetes v1.29",
            "insightStatus": {
                "status": "PASSING",
                "reason": "No deprecated API usage detected within the last 30 days."
            },
            "kubernetesVersion": "1.29",
            "lastTransitionTime": 1698774710.0,
            "lastRefreshTime": 1700157422.0,
            "id": "123e4567-e89b-42d3-a456-579642341238",
            "description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes v1.29. Upgrading your cluster before migrating to the updated APIs supported by v1.29 could cause application impact."
        }
    ]
}

要获得有关收到的见解的更具描述性的输出，可以运行以下命令：

aws eks describe-insight --region <region-code> --id <insight-id> --cluster-name <my-cluster>

您还可以选择在亚马逊 EKS 控制台中查看见解。从集群列表中选择您的集群后，见解结果位于Upgrade Insights选项卡下方。

如果您发现了集群洞察力"status": ERROR，则必须在执行集群升级之前解决问题。运行该aws eks describe-insight命令，该命令将共享以下补救建议：

受影响的资源：

"resources": [
      {
        "insightStatus": {
          "status": "ERROR"
        },
        "kubernetesResourceUri": "/apis/policy/v1beta1/podsecuritypolicies/null"
      }
]

API 已弃用：

"deprecationDetails": [
      {
        "usage": "/apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas",
        "replacedWith": "/apis/flowcontrol.apiserver.k8s.io/v1beta3/flowschemas",
        "stopServingVersion": "1.29",
        "clientStats": [],
        "startServingReplacementVersion": "1.26"
      }
]

建议采取的行动：

"recommendation": "Update manifests and API clients to use newer Kubernetes APIs if applicable before upgrading to Kubernetes v1.26."

通过 EKS 控制台或 CLI 利用集群洞察有助于加快成功升级 EKS 集群版本的过程。通过以下资源了解更多信息：* 官方 EKS 文档 * 集群见解发布博客。

Kube-no-trouble

Kube-no-trouble是一个带有命令的开源命令行实用程序kubent。当你在没有任何参数kubent的情况下运行时，它将使用你当前的 KubeConfig上下文扫描集群并打印一份报告，其中包含哪些API将被弃用和删除。

kubent

4:17PM INF >>> Kube No Trouble `kubent` <<<
4:17PM INF version 0.7.0 (git sha d1bb4e5fd6550b533b2013671aa8419d923ee042)
4:17PM INF Initializing collectors and retrieving data
4:17PM INF Target K8s version is 1.24.8-eks-ffeb93d
4:l INF Retrieved 93 resources from collector name=Cluster
4:17PM INF Retrieved 16 resources from collector name="Helm v3"
4:17PM INF Loaded ruleset name=custom.rego.tmpl
4:17PM INF Loaded ruleset name=deprecated-1-16.rego
4:17PM INF Loaded ruleset name=deprecated-1-22.rego
4:17PM INF Loaded ruleset name=deprecated-1-25.rego
4:17PM INF Loaded ruleset name=deprecated-1-26.rego
4:17PM INF Loaded ruleset name=deprecated-future.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.25 <<<
------------------------------------------------------------------------------------------
KIND                NAMESPACE     NAME             API_VERSION      REPLACE_WITH (SINCE)
PodSecurityPolicy   <undefined>   eks.privileged   policy/v1beta1   <removed> (1.21.0)

它也可以用来扫描静态清单文件和 helm 包。建议kubent作为持续集成 (CI) 流程的一部分运行，以便在部署清单之前发现问题。扫描清单也比扫描实时集群更准确。

Kube-no-trouble 提供具有相应权限的示例服务帐户和角色以扫描集群。

冥王星

另一个选项是 pluto，它类似于，kubent因为它支持扫描实时集群、清单文件、头盔图表，并且可以在 CI 流程中包含一个 GitHub 操作。

pluto detect-all-in-cluster

NAME             KIND                VERSION          REPLACEMENT   REMOVED   DEPRECATED   REPL AVAIL
eks.privileged   PodSecurityPolicy   policy/v1beta1                 false     true         true

资源

要在升级之前验证您的集群是否不使用过时的 API，您应该监控：

kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

apiserver_requested_deprecated_apis{group="policy",removed_release="1.25",resource="podsecuritypolicies",subresource="",version="v1beta1"} 1

CLUSTER="<cluster_name>"
QUERY_ID=$(aws logs start-query \
 --log-group-name /aws/eks/${CLUSTER}/cluster \
 --start-time $(date -u --date="-30 minutes" "+%s") # or date -v-30M "+%s" on MacOS \
 --end-time $(date "+%s") \
 --query-string 'fields @message | filter `annotations.k8s.io/deprecated`="true"' \
 --query queryId --output text)

echo "Query started (query id: $QUERY_ID), please hold ..." && sleep 5 # give it some time to query

aws logs get-query-results --query-id $QUERY_ID

如果使用过时的 API，它将输出行数：

{
    "results": [
        [
            {
                "field": "@message",
                "value": "{\"kind\":\"Event\",\"apiVersion\":\"audit.k8s.io/v1\",\"level\":\"Request\",\"auditID\":\"8f7883c6-b3d5-42d7-967a-1121c6f22f01\",\"stage\":\"ResponseComplete\",\"requestURI\":\"/apis/policy/v1beta1/podsecuritypolicies?allowWatchBookmarks=true\\u0026resourceVersion=4131\\u0026timeout=9m19s\\u0026timeoutSeconds=559\\u0026watch=true\",\"verb\":\"watch\",\"user\":{\"username\":\"system:apiserver\",\"uid\":\"8aabfade-da52-47da-83b4-46b16cab30fa\",\"groups\":[\"system:masters\"]},\"sourceIPs\":[\"::1\"],\"userAgent\":\"kube-apiserver/v1.24.16 (linux/amd64) kubernetes/af930c1\",\"objectRef\":{\"resource\":\"podsecuritypolicies\",\"apiGroup\":\"policy\",\"apiVersion\":\"v1beta1\"},\"responseStatus\":{\"metadata\":{},\"code\":200},\"requestReceivedTimestamp\":\"2023-10-04T12:36:11.849075Z\",\"stageTimestamp\":\"2023-10-04T12:45:30.850483Z\",\"annotations\":{\"authorization.k8s.io/decision\":\"allow\",\"authorization.k8s.io/reason\":\"\",\"k8s.io/deprecated\":\"true\",\"k8s.io/removed-release\":\"1.25\"}}"
            },
[...]

更新 Kubernetes 工作负载。使用 kubectl-convert 更新清单

确定哪些工作负载和清单需要更新后，可能需要更改清单文件中的资源类型（例如，更改PodSecurityPolicies 为 PodSecurityStandards）。这将需要更新资源规格并根据正在替代的资源进行更多研究。

如果资源类型保持不变但需要更新 API 版本，则可以使用该kubectl-convert命令自动转换清单文件。例如，将较旧的部署转换为apps/v1。有关更多信息，请参阅在 Kubernetes 网站上安装 kubectl 转换插件。

kubectl-convert -f <file> --output-version <group>/<version>

配置 PodDisruptionBudgets 和拓扑结构SpreadConstraints 以确保数据平面升级期间工作负载的可用性

确保您的工作负载具有正确的PodDisruptionBudgets拓扑结构 SpreadConstraints，以确保数据平面升级期间工作负载的可用性。并非每个工作负载都需要相同级别的可用性，因此您需要验证工作负载的规模和要求。

确保工作负载分布在多个可用区域和多台主机上，拓扑分布可以提高工作负载自动迁移到新数据平面而不会发生意外事件的信心。

以下是工作负载示例，该工作负载将始终有 80% 的可用副本，并将副本分布在区域和主机上

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp
spec:
  minAvailable: "80%"
  selector:
    matchLabels:
      app: myapp
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 10
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
        name: myapp
        resources:
          requests:
            cpu: "1"
            memory: 256M
      topologySpreadConstraints:
      - labelSelector:
          matchLabels:
            app: host-zone-spread
        maxSkew: 2
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
      - labelSelector:
          matchLabels:
            app: host-zone-spread
        maxSkew: 2
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule

AWS Resili ence Hub 已将亚马逊弹性 Kubernetes 服务（亚马逊 EKS）添加为支持资源。Resilience Hub 提供了一个定义、验证和跟踪应用程序弹性的单一平台，这样您就可以避免软件、基础设施或运营中断造成的不必要停机。

使用托管节点组或 Karpenter 来简化数据平面升级

托管节点组和Karpenter都简化了节点升级，但它们采用了不同的方法。

托管节点组可自动配置节点和生命周期管理。这意味着您可以通过单个操作创建、自动更新或终止节点。

在默认配置中，Karpenter 使用最新的兼容的 EKS 优化 AMI 自动创建新节点。随着 EKS 发布更新的 EKS 优化 AMI 或集群升级，Karpenter 将自动开始使用这些镜像。Karpenter 还实现了节点过期来更新节点。

可以将 Karpenter 配置为使用自定义 AMI。如果您在 Karpenter 中使用自定义 AMI，则应对 kubelet 的版本负责。

确认与现有节点和控制平面的版本兼容性

在继续在 Amazon EKS 中升级 Kubernetes 之前，确保托管节点组、自管理节点和控制平面之间的兼容性至关重要。兼容性由你使用的 Kubernetes 版本决定，它会根据不同的场景而有所不同。战术：

为 Karpenter 托管节点启用节点到期时间

Karpenter 实现节点升级的一种方法是使用节点到期的概念。这减少了节点升级所需的规划。当您在配置器SecondsUntilExpired 中为 ttl 设置值时，这会激活节点到期。当节点在几秒钟内达到规定的年龄后，它们将被安全地排空和删除。即使它们正在使用也是如此，允许您使用新配置的升级实例替换节点。替换节点时，Karpenter 使用最新 EKS-optimized 的 AMI。有关更多信息，请参阅 Karpenter 网站上的干扰。

Karpenter 不会自动为该值添加抖动。为防止工作负载过度中断，请定义容器中断预算，如 Kubernetes 文档中所示。

如果您在配置器SecondsUntilExpired 上配置 ttl，则这适用于与供应器关联的现有节点。

对 Karpenter 托管节点使用漂移功能

Karpenter 的漂移功能可以自动升级 Karpenter-provisioned 节点，使其与 EKS 控制平面保持同步。目前需要使用功能门启用 Karpenter Drift。Karpenter 的默认配置使用最新的 EKS-Optimized AMI，其主要和次要版本与 EKS 集群的控制平面相同。

EKS 集群升级完成后，Karpenter 的 Drift 功能将检测到 Karpenter-provisioned 节点正在使用先前集群版本 EKS-Optimized 的 AMI，并自动封锁、排空和替换这些节点。要支持 Pod 迁移到新节点，请遵循 Kubernetes 最佳实践，设置适当的 pod 资源配额并使用 p od 中断预算 (PDB)。Karpenter 的取消配置将根据 pod 资源请求预启动替换节点，并在取消配置节点时遵守 PDB。

使用 eksctl 自动升级自管理节点组

自管理节点组是在您的账户中部署并连接到 EKS 服务之外的集群的 EC2 实例。它们通常由某种形式的自动化工具进行部署和管理。要升级自我管理的节点组，你应该参考你的工具文档。

例如，eksctl 支持删除和排空自管理节点。

一些常用工具包括：

升级之前备份集群

新版本的 Kubernetes 为您的亚马逊 EKS 集群带来了重大变化。您可以在 7 天内回滚升级，但我们建议您在升级之前备份集群。

您可以使用 AWS Backup（一项完全托管的服务）备份您的集群。您还可以使用社区支持的开源工具 Velero 。

请注意，您只能为 EKS 目前支持的 Kubernetes 版本创建新集群。如果您的集群当前运行的版本仍受支持且升级失败，则可以使用原始版本创建新集群并恢复数据平面。请注意，包括 IAM 在内的 AWS 资源不包含在备份中。你需要重新创建这些资源。

升级控制平面后重启 Fargate 部署

要升级 Fargate 数据平面节点，你需要重新部署工作负载。您可以通过列出所有带有-o wide选项的 pod 来确定哪些工作负载正在 fargate 节点上运行。任何以开头的节点名称都fargate-需要在集群中重新部署。

评估 Blue/Green 集群作为就地集群升级的替代方案

一些客户更喜欢采取 blue/green 升级策略。这可能有好处，但也包括应考虑的缺点。

优势包括：

一些缺点包括：

尽管这种策略是可能的，但它比就地升级更昂贵，并且需要更多时间进行协调和工作负载迁移。在某些情况下可能是必需的，应仔细规划。

有了高度的自动化和声明式系统 GitOps，这可能更容易做到。您需要对有状态的工作负载采取额外的预防措施，以便将数据备份并迁移到新集群。

查看以下博客文章以获取更多信息：

跟踪 Kubernetes 项目中计划中的重大变更——提前思考

不要只看下一个版本。在 Kubernetes 的新版本发布时对其进行审查，并确定主要变化。例如，一些应用程序直接使用了 docker API，Kubernetes 中删除了对 Docker 容器运行时接口 (CRI)（也称为 Dockershim）的支持。1.24这种变化需要更多时间来准备。

查看您要升级到的版本的所有记录变更，并记下所有必需的升级步骤。此外，请注意任何特定于 Amazon EKS 托管集群的要求或程序。

有关功能移除的具体指南

在 1.25 版本中移除 Dockershim-使用 Docker 套接字检测器 (DDS)

适用于 1.25 的 EKS 优化 AMI 不再包括对 Dockershim 的支持。如果你依赖于 Dockershim，例如你正在安装 Docker 套接字，则需要在将工作节点升级到 1.25 之前删除这些依赖关系。

在升级到 1.25 之前，找出你依赖于 Docker 套接字的实例。我们建议使用 Docker Socket (DDS) 检测器，这是一个 kubectl 插件。。

PodSecurityPolicy 在 1.25 版本中移除-迁移到 Pod 安全标准或策略即代码解决方案

PodSecurityPolicy在 Kubernetes 1.21 中已弃用，并已在 Kubernetes 1.25 中移除。如果您在集群 PodSecurityPolicy 中使用，则必须先迁移到内置的 Kubernetes Pod 安全标准 (PSS) 或策略即代码解决方案，然后才能将集群升级到 1.25 版，以避免工作负载中断。

AWS 在 EKS 文档中发布了详细的常见问题解答。

查看 Pod 安全标准 (PSS) 和 Pod 安全准入 (PSA) 最佳实践。

查看 Kubernetes 网站上的 “PodSecurityPolicy弃用” 博客文章。

在 1.23 版本中弃用 In-Tree 存储驱动程序-迁移到容器存储接口 (CSI) 驱动程序

容器存储接口 (CSI) 旨在帮助 Kubernetes 取代其现有的树内存储驱动程序机制。默认情况下，Amazon EBS Container Storage Interface (CSI) 迁移功能在 Amazon EKS 1.23 和更高版本的集群上处于启用状态。如果您的容器在某个版本1.22或更早版本的集群上运行，则必须先安装 Amazon EBS CSI 驱动程序，然后才能将集群更新到版本，1.23以避免服务中断。

查看亚马逊 EBS CSI 迁移常见问题解答。

其他资源

ClowdHaus EKS 升级指南

ClowdHaus EKS 升级指南是一个 CLI，用于帮助升级亚马逊 EKS 集群。它可以在升级之前分析集群中是否存在任何需要修复的潜在问题。

GoNoGo

GoNoGo是一个 alpha 阶段工具，用于确定集群插件的升级信心。