Amazon EKS 集群升级指南

Amazon Elastic Kubernetes Service (Amazon EKS) 是一项完全托管的 Kubernetes 服务。您可利用该服务轻松地在 AWS 上运行 Kubernetes，而无需安装、操作和维护您自己的 Kubernetes 控制平面。Amazon EKS 经认证与 Kubernetes 一致，因此上游 Kubernetes 上运行的现有应用程序可与 Amazon EKS 兼容。出于其安全性、可靠性和可扩展性，EKS 是运行 Kubernetes 的最佳平台。

Kubernetes 项目发展迅速，提供了新功能、设计更新和错误修复。社区大约每三个月发布新的 Kubernetes 次要版本，为了支持 Kubernetes 版本 Kubernetes 社区，Amazon EKS 致力于在任何给定时间支持至少四个生产就绪的 Kubernetes 版本。

以下 Kubernetes 版本目前可用于 Amazon EKS 中的新集群：

• 1.18.8
• 1.17.9
• 1.16.13
• 1.15.11
• 1.14.9

每个版本在 Amazon EKS 上发布后大约 14 个月将停止支持。如果账户中的任何集群在即将结束支持时仍运行该版本，Amazon EKS 将通过 AWS Personal Health Dashboard 发送通知。通知将包括终止支持的日期,即自通知之日起至少 60 天。在终止支持之日,您将无法再使用不受支持的版本创建新的 Amazon EKS 集群。现有集群将通过支持结束日期后逐步部署过程自动升级到最早的支持版本。

以下为目前版本的发布日期以及终止支持日期：

完整列表请参考Amazon EKS Kubernetes 版本。

当您现有的 Amazon EKS集群版本即将终止支持，或是发布了新的 Kubernetes 版本可用时，建议您将集群升级至新版本，使您可以利用最新的 Kubernetes 功能以及 Amazon EKS 配置和安全补丁的更新。Amazon EKS 为 Kubernetes 和 Amazon EKS 平台版本执行托管的就地集群升级，Kubernetes 版本升级可就地完成，因而您无需创建新集群或将应用程序迁移至新集群，简化了集群操作。

升级 Amazon EKS 集群 Kubernetes 版本的操作步骤请参考用户指南。

本文中的场景基于深圳店匠科技有限公司在AWS上构建的Shoplazza 店匠跨境电商独立站海外销售平台，该平台使用Amazon EKS搭建Kubernetes集群服务，在集群升级过程中保障了应用的高可用。店匠作为跨境电商行业领先技术和品牌服务公司，借助AWS全球强大的基础设施及先进服务，为全球用户提供了最佳的用户体验。详细架构请参考AWS案例研究：赋能云上电商，AWS助力Shoplazza店匠从0到1轻松出海。

本文在EKS文档的基础上，整理了用户在生产环境的升级操作实践，为其他用户的集群升级操作提供参考。

场景概述

由于 Amazon EKS 运行高度可用的控制平面，因此，一次操作只能升级一个次要版本，如需升级多个版本，请按版本顺序做多次升级操作。

Amazon EKS数据平面可以选择自管理节点组或托管节点组，托管节点组为 Amazon EKS集群自动进行节点的预配置和生命周期管理，且没有额外的费用。从 Kubernetes 版本 1.14 开始，在 Amazon EKS 集群上支持托管节点组。现有集群可升级到版本 1.14 或更高版本来利用此功能。

本文中执行升级操作的Amazon EKS集群环境如下：

Amazon EKS集群升级前：运行1.13版本，使用自管理节点组。

Amazon EKS集群升级操作：

• 13版本升级至 1.14版本，将自管理节点组迁移至托管节点组；
• 14 版本升级至1.15版本；
• 15 版本升级至1.16版本；
• 16 版本升级至1.17版本；
• 17 版本升级至1.18版本；

Amazon EKS集群升级后：运行 1.18版本，使用托管节点组。

升级概述

每一个版本的升级操作，操作子步骤都基本一致：

• 更新 Amazon EKS 控制平面
• 更新集群中使用的 Kubernetes组件
• 更新Amazon EKS数据平面

在最后一个子步骤更新Amazon EKS数据平面的操作时，无论是自管理节点组还是托管节点组，都有两种选择：

• 在现有节点组上执行就地升级
• 创建新节点组，替换旧节点组

在现在节点组上执行就地升级，需要在当前的节点组关联的 Auto Scaling 组上，使用新版本的AMI增加新节点，taint旧节点，将Pod从旧节点转移至新节点上，直至将所有Pod从旧节点移除，最后删除旧节点。自管理节点组的就地升级请参考更新现有节点组，托管节点组的就地升级请参考更新托管节点组。

创建新节点组，替换旧节点组，将先创建新版本的节点组，taint旧节点组里的节点，对旧节点组执行drain操作，或是手动将Pod从旧节点组转移至新节点组，直至将所有Pod从旧节点组移除，最后删除旧节点组。自管理节点组的替换更新请参考迁移至新的节点组。

节点组的选择建议使用托管节点组替换自管理节点组，托管节点组可进行自动更新，详细步骤请参考托管节点组更新行为。在托管节点组更新过程中，Amazon EKS 将随机选择节点组中的taint节点，并从其中移出所有 Pod。因此在托管节点组更新方式选择上，如果业务接受托管节点组的默认更新行为，例如无状态类应用，建议选择在现有托管节点组上执行就地升级；如果需要对更新行为有更精确的控制，例如管理类应用以及StatefulSet等有状态类应用，应用有部署顺序依赖关系，应用有对指定可用区依赖关系，建议使用创建新托管节点组，替换老托管节点组的更新方式，手动控制迁移。在同一个Amazon EKS集群内，可以有多个节点组分别部署了不同的应用，建议不同节点组里的应用类型，选择独立的更新方式。

本文中的Amazon EKS单个集群里包含了多个节点组。在操作每个版本升级时，同时使用了在现有节点组上执行就地升级，以及创建新节点组替换旧节点组的升级方式。

Amazon EKS集群更新操作可使用eksctl、AWS 管理控制台 或 AWS CLI ，不同工具在各操作步骤有差异，本文中的更新操作使用了AWS管理控制台。以下为各版本更新的详细步骤。

1.13 版本升级至 1.14版本

升级至1.14版本前，请先了解Kubernetes社区公告1.14版本的更新日志，以及AWS更新说明Amazon EKS 现已支持 Kubernetes 1.14 版。

1. 确认当前版本

控制平面的版本信息，在管理控制台上可直接查看，也可使用以下命令查看：

kubectl version --short

托管节点组的版本信息，在管理控制台上可直接查看，也可通过以下命令获取：

kubectl get nodes

2. 升级条件检查

确认启用Pod 安全策略准入控制器，可使用以下命令检查默认策略：

kubectl get psp eks.privileged

如果收到错误，请参阅安装或恢复默认 Pod 安全策略，然后再继续操作。

3. 更新控制平面

当前使用老版本的控制平面，在管理控制台上会提示更新，点击更新将控制平面版本更新至 1.14。

在更新过程中，新版本 API 服务器会替换老版本 API 服务器，请尽量避免API操作，直至更新操作完成。

4. 更新集群组件

当集群控制平面更新时，Amazon EKS 不修改您的任何 Kubernetes 组件。因此在更新控制平面后，建议您将所有使用到的组件更新为适配新Kubernetes 版本的兼容版本。针对Kubernetes 1.14版本，其默认组件以及适配的兼容版本如下：

将集群中使用的未在上表中列出的其他附加组件也一并列出，并安排好更新顺序。以上默认组件更新顺序依次为KubeProxy, DNS, CNI。

4.1 更新KubeProxy 组件

检查当前kube-proxy的镜像版本：

kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

将 kube-proxy 更新到建议的版本（将<kubeproxy_image>替换为上表中KubeProxy对应的更新地址，将地址中<region_code>替换为集群所在的区域代码，如us-west-2）：

kubectl set image daemonset.apps/kube-proxy \
    -n kube-system \
    kube-proxy=<kubeproxy_image>

4.2 更新DNS组件

检查集群的 DNS 提供商：

kubectl get pod -n kube-system -l k8s-app=kube-dns

请参考不同DNS提供商的组件更新方式。

针对默认的CoreDNS组件, 检查集群的 coredns 部署的当前版本：

kubectl describe deployment coredns --namespace kube-system | grep Image | cut -d "/" -f 3

如果当前版本早于 1.5.0，需要修改 coredns 的配置映射以使用 forward 插件，而不是 proxy 插件。使用以下命令打开 configmap。

kubectl edit configmap coredns -n kube-system

将以下行中的 proxy 替换为 forward。保存该文件并退出编辑器。

proxy . /etc/resolv.conf

将 coredns 更新到建议的版本（将<region_code>替换为集群所在的区域代码

，如us-west-2）：

kubectl set image --namespace kube-system deployment.apps/coredns \
            coredns=602401143452.dkr.ecr.<region_code>.amazonaws.com/eks/coredns:v1.6.6

4.3 更新CNI组件

检查当前Amazon VPC CNI 的版本：

kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

下载CNI清单文件：

curl -o aws-k8s-cni.yaml https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni.yaml

将下载的aws-k8s-cni.yaml文件中的区域代码（默认为us-west-2）替换为集群所在区域代码（将<region_code>替换为集群所在的区域代码）：

sed -i -e 's/us-west-2/<region_code>/' aws-k8s-cni.yaml

将修改后的清单文件应用于集群：

kubectl apply -f aws-k8s-cni.yaml

4.4 更新其它组件

集群中的其它组件也一并需要更新为适配新Kubernetes 版本的兼容版本。

例如Cluster Autoscaler组件。更新步骤为：

打开 Cluster Autoscaler 版本列表页面，找到与集群的 Kubernetes 主版本和次要版本相匹配的版本，将映像标签设置为相匹配的版本（可将 us 替换为 <asia> 或 <eu>）：

kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=us.gcr.io/k8s-artifacts-prod/autoscaling/cluster-autoscaler:v1.14.8

5. 更新数据平面

当前集群版本1.13中使用了自管理节点组。在此次升级过程中，将创建新版本1.14的托管节点组，把应用从自管理节点组迁移至新托管节点组，然后删除旧节点组。

5.1 更新前检查

如果集群使用了Cluster Autoscaler组件，请将部署向下扩展到 0 个副本以避免相互冲突的扩展操作。

kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system

5.2 创建新版本托管节点组

从 Kubernetes 版本 1.14开始，在 Amazon EKS 集群上支持托管节点组。请根据应用需求创建托管节点组。

创建托管节点组时，默认将使用默认的启动模板，也可以选择自定义的启动模板，请参考托管节点组的启动模板支持。需要注意的是：使用了自定义启动模板的托管节点组，无法在当前节点组进行滚动更新操作。

为了区分新版本节点组以及不同，建议为节点组添加Kubernetes标记，例如版本类标记lifecycle=1.14，例如应用类型标记app=statefulset，例如应用名称标记app=appName等。

在管理控制台上观察节点组状态，直到状态显示为活动。也可通过以下命令检查节点是否达到Ready状态：

kubectl get nodes

如已为不同节点组添加标记，可通过标记筛选指定版本节点：

kubectl get nodes --label-columns=lifecycle --selector=lifecycle=1.15

如集群中有应用流量是通过Service或Ingress自动创建的ELB导入的，新节点组实例会被自动添加至ELB目标组里。如果集群中有应用流量是通过手动创建的ELB导入的，需要手动将新节点组实例添加到ELB目标组里。

如发现新建托管节点组无法与API Server通信，无法采集节点metrics data，kubectl top node获取不到数据等现象，请确认集群控制平面与节点间的安全组是否开放443/10250端口。参考 Amazon EKS 安全组注意事项，修改默认集群安全组允许所需的端口。

5.3 对旧版本节点组执行Taint操作

为防止任务继续被调度到旧节点上，对每个旧节点执行Taint操作（替换<kubelet_version>为旧节点版本，1.13）：

kubectl get nodes | grep v<kubelet_version> | awk '{print $1 " key=value:NoSchedule"}' | xargs kubectl taint nodes                                           

5.4 将应用从旧版本节点组迁移至新版本节点组

根据不同业务的可用性要求，以及不同的流量接入设计，可采取不同策略对应用做迁移。迁移策略包括：

• 对旧节点上的Pod做驱逐操作，将Pod驱逐至新节点上。
• 对deployment做重启控制，将Pod迁移至新节点上。
• 扩展deployment数量，在新节点上启动额外新Pod。

建议根据应用类型，选取一种适合的升级策略。

以下通过对旧节点的Pod做驱逐的方式，将Pod驱逐至新节点上。

需要对每个旧节点执行drain操作，确认旧节点上的Pod都已驱除（替换<kubelet_version>为旧节点版本，1.13）：

kubectl get nodes | grep v<kubelet_version> | awk '{print $1 " --force --ignore-daemonsets --delete-local-data"}' | xargs kubectl drain

对于需要精确控制的迁移，也可针对特定Pod和Node做精确驱逐操作。

以下通过对deployment做重启控制的方式，将Pod迁移至新节点上。

修改需要迁移的deployment（替换<deployment_name>为应用名称，替换<namespace>为应用空间名称）：

kubectl rollout restart deployment <deployment_name> -n <namespace>

以下通过扩展deployment数量方式，将新Pod扩展部署在新节点上。

扩展现有的deployment（替换<deployment_name>为应用名称，替换<namespace>为应用空间名称，替换<replica_number>为扩展数量）：

kubectl scale deployments/<deployment_name>; --replicas=<replica_number> -n <namespace>

在Pod迁移过程中，也建议配合使用Pod Disruption Budgets来保证应用迁移过程中的可用性。

针对StatefulSet Pod的迁移，请确认新节点组与旧节点组使用相同配置，确认新节点与老节点置放在相同可用区，使用相同PV。

5.5 删除旧版本节点组

确认旧节点上的non-DaemonSet pods都已迁移或扩展到新节点上。

kubectl get po -n <namespace> -o wide

确认流量入口的ELB目标组中新节点的健康检查通过，开始接受流量。

由于旧版本节点组为自管理节点组，在EKS管理控制台上不可见，需要找到节点组对应的Auto Scaling组，设置所需容量为 0，等待节点自动回收。当所有节点回收完成，删除该Auto Scaling组。

5.6 更新后检查

如果集群使用了Cluster Autoscaler组件，请将部署向上扩展到 1 个副本以启用组件功能。

kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system

1.14 版本升级至1.15版本

升级至1.15版本前，请先了解Kubernetes社区公告1.15版本的更新日志，以及AWS更新说明Amazon EKS 现已支持 Kubernetes 1.15 版。

1. 确认当前版本

控制平面的版本信息，在管理控制台上可直接查看，也可使用以下命令查看：

kubectl version --short

托管节点组的版本信息，在管理控制台上可直接查看，也可通过以下命令获取：

kubectl get nodes

2. 更新控制平面

当前使用老版本的控制平面，在管理控制台上会提示更新，点击更新将控制平面版本更新至 1.15。

在更新过程中，新版本 API 服务器会替换老版本 API 服务器，请尽量避免API操作，直至更新操作完成。

3. 更新集群组件

当集群控制平面更新时，Amazon EKS 不修改您的任何 Kubernetes 组件。因此在更新控制平面后，建议您将所有使用到的组件更新为适配新Kubernetes 版本的兼容版本。针对Kubernetes 1.15版本，其默认组件以及适配的兼容版本如下：

将集群中使用的未在上表中列出的其他附加组件也一并列出，并安排好更新顺序。

按顺序更新KubeProxy, DNS, CNI以及其它组件，具体操作请参考“1.13 版本升级至 1.14版本”章节中的4.1至4.4步骤，注意使用上表中组件的对应版本更新地址。

4. 更新数据平面

当前集群中已全部使用托管节点组，托管节点组支持就地升级。

本文中的Amazon EKS单个集群里包含了多个节点组。在此次升级过程中，将对部署管理应用的节点组执行替换升级，对部署无状态应用的节点组执行就地升级。

替换升级的方式，将通过创建新版本1.15的托管节点组，把应用从旧版本托管节点组迁移至新版本托管节点组，然后删除旧版本托管节点组。具体操作请参考“1.13 版本升级至 1.14版本”章节中的5.1至5.6步骤，注意使用1.15版本。

就地升级的方式，将使用托管节点组的自动更新功能，详细步骤请参考更新托管节点组，并了解托管节点组更新行为。更新过程中可查看节点组的更新历史记录，以及观察node和pod的更新行为。

kubectl get nodes --watch
kubectl get pods --watch

1.15版本升级至1.16版本

升级至1.16版本前，请先了解Kubernetes社区公告1.16版本的更新日志，以及AWS更新说明Amazon EKS 现已支持 Kubernetes 1.16 版。

1. 确认当前版本

控制平面的版本信息，在管理控制台上可直接查看，也可使用以下命令查看：

kubectl version --short

托管节点组的版本信息，在管理控制台上可直接查看，也可通过以下命令获取：

kubectl get nodes

2. 弃用API更改

如 Kubernetes 1.15 更改日志中所述，请先了解在 1.16 中弃用的APIs文档。在将集群升级到 1.16 之前，需要对部署的资源进行 API 更改，请参考Kubernetes 1.16 升级先决条件。

涉及更新的API如下：

要检查集群中已弃用的 API 使用情况，请确保已启用 audit 控制层面日志，并指定 v1beta 作为事件的筛选器。

也可以使用以下命令获取使用了特定API版本的资源：

kubectl get deployment.extensions --all-namespaces

kubectl get deployment.apps --all-namespaces

按照以上资源API弃用更新列表对资源yaml文件中的apiVersion做逐一更新（替换<new_api>为对应资源的更新API）：

apiVersion: <new_api>

对于Deployment和DaemonSet资源的API更新，可以使用以下命令（替换<deployment.yaml>为对应资源的yaml文件）：

kubectl convert -f ./<deployment.yaml> --output-version apps/v1

如果集群使用了Helm进行资源部署，可使用Helm mapkubeapis Plugin来进行弃用API的替换更新。

资源API更新完成后，通过kubectl edit查看的deployment的apiVersion仍然显示为弃用API，直到控制平面升级完成后，才会显示更新API。

3. 更新控制平面

当前使用老版本的控制平面，在管理控制台上会提示更新，点击更新将控制平面版本更新至 1.16。

在更新过程中，新版本 API 服务器会替换老版本 API 服务器，请尽量避免API操作，直至更新操作完成。

4. 更新集群组件

当集群控制平面更新时，Amazon EKS 不修改您的任何 Kubernetes 组件。因此在更新控制平面后，建议您将所有使用到的组件更新为适配新Kubernetes 版本的兼容版本。针对Kubernetes 1.16版本，其默认组件以及适配的兼容版本如下：

将集群中使用的未在上表中列出的其他附加组件也一并列出，并安排好更新顺序。

按顺序更新KubeProxy, DNS, CNI以及其它组件，具体操作请参考“1.13 版本升级至 1.14版本”章节中的4.1至4.4步骤，注意使用上表中组件的对应版本更新地址。

5. 更新数据平面

当前集群中已全部使用托管节点组，托管节点组支持就地升级。

本文中的Amazon EKS单个集群里包含了多个节点组。在此次升级过程中，将对部署管理应用的节点组执行替换升级，对部署无状态应用的节点组执行就地升级。

替换升级的方式，将通过创建新版本1.16的托管节点组，把应用从旧版本托管节点组迁移至新版本托管节点组，然后删除旧版本托管节点组。具体操作请参考“1.13 版本升级至 1.14版本”章节中的5.1至5.6步骤，注意使用1.16版本。

就地升级的方式，将使用托管节点组的自动更新功能，详细步骤请参考更新托管节点组，并了解托管节点组更新行为。更新过程中可查看节点组的更新历史记录，以及观察node和pod的更新行为。

kubectl get nodes --watch
kubectl get pods --watch

1.16版本升级至1.17版本

升级至1.17版本前，请先了解Kubernetes社区公告1.17版本的更新日志，以及AWS更新说明Amazon EKS 现已支持 Kubernetes 1.17 版。

1. 确认当前版本

控制平面的版本信息，在管理控制台上可直接查看，也可使用以下命令查看：

kubectl version –short

托管节点组的版本信息，在管理控制台上可直接查看，也可通过以下命令获取：

kubectl get nodes

2. 更新控制平面

当前使用老版本的控制平面，在管理控制台上会提示更新，点击更新将控制平面版本更新至 1.17。

在更新过程中，新版本 API 服务器会替换老版本 API 服务器，请尽量避免API操作，直至更新操作完成。

3. 更新集群组件

当集群控制平面更新时，Amazon EKS 不修改您的任何 Kubernetes 组件。因此在更新控制平面后，建议您将所有使用到的组件更新为适配新Kubernetes 版本的兼容版本。针对Kubernetes 1.17版本，其默认组件以及适配的兼容版本如下：

将集群中使用的未在上表中列出的其他附加组件也一并列出，并安排好更新顺序。

按顺序更新KubeProxy, DNS, CNI以及其它组件，具体操作请参考“1.13 版本升级至 1.14版本”章节中的4.1至4.4步骤，注意使用上表中组件的对应版本更新地址。

4. 更新数据平面

当前集群中已全部使用托管节点组，托管节点组支持就地升级。

本文中的Amazon EKS单个集群里包含了多个节点组。在此次升级过程中，将对部署管理应用的节点组执行替换升级，对部署无状态应用的节点组执行就地升级。

替换升级的方式，将通过创建新版本1.17的托管节点组，把应用从旧版本托管节点组迁移至新版本托管节点组，然后删除旧版本托管节点组。具体操作请参考“1.13 版本升级至 1.14版本”章节中的5.1至5.6步骤，注意使用1.17版本。

就地升级的方式，将使用托管节点组的自动更新功能，详细步骤请参考更新托管节点组，并了解托管节点组更新行为。更新过程中可查看节点组的更新历史记录，以及观察node和pod的更新行为。

1.17版本升级至1.18版本

升级至1.18版本前，请先了解Kubernetes社区公告1.18版本的更新日志，以及AWS更新说明Amazon EKS 现已支持 Kubernetes 1.18 版。

1. 确认当前版本

控制平面的版本信息，在管理控制台上可直接查看，也可使用以下命令查看：

kubectl version --short

托管节点组的版本信息，在管理控制台上可直接查看，也可通过以下命令获取：

kubectl get nodes

2. 更新控制平面

当前使用老版本的控制平面，在管理控制台上会提示更新，点击更新将控制平面版本更新至 1.18。

在更新过程中，新版本 API 服务器会替换老版本 API 服务器，请尽量避免API操作，直至更新操作完成。

3. 更新集群组件

当集群控制平面更新时，Amazon EKS 不修改您的任何 Kubernetes 组件。因此在更新控制平面后，建议您将所有使用到的组件更新为适配新Kubernetes 版本的兼容版本。针对Kubernetes 1.18版本，其默认组件以及适配的兼容版本如下：

将集群中使用的未在上表中列出的其他附加组件也一并列出，并安排好更新顺序。

按顺序更新KubeProxy, DNS, CNI以及其它组件，具体操作请参考“1.13 版本升级至 1.14版本”章节中的4.1至4.4步骤，注意使用上表中组件的对应版本更新地址。

4. 更新数据平面

当前集群已全部使用托管节点组，托管节点组支持就地升级。

本文中的Amazon EKS单个集群里包含了多个节点组。在此次升级过程中，将对部署管理应用的节点组执行替换升级，对部署无状态应用的节点组执行就地升级。

替换升级的方式，将通过创建新版本1.18的托管节点组，把应用从旧版本托管节点组迁移至新版本托管节点组，然后删除旧版本托管节点组。具体操作请参考“1.13 版本升级至 1.14版本”章节中的5.1至5.6步骤，注意使用1.18版本。

就地升级的方式，将使用托管节点组的自动更新功能，详细步骤请参考更新托管节点组，并了解托管节点组更新行为。更新过程中可查看节点组的更新历史记录，以及观察node和pod的更新行为。

常见问题

• 托管节点组就地升级失败

现象：对托管节点组执行升级操作，页面没有变化或变回未升级前的页面。

原因：升级过程失败，可查看节点组的更新历史记录。失败的原因可能为: Reached max retries while trying to evict pods from nodes in node group。在驱逐pod 的过程中，达到了最大的尝试次数，升级任务被判定为失败，记录失败历史，页面跳回升级前的页面。

解决方法：确认pod驱逐失败的原因，在页面上再次尝试执行升级操作，或使用替换升级的方式。

总结

Amazon EKS提供了完全托管的Kubernetes服务，在集群版本升级操作上提供了一键式的升级控制平面及数据平面的功能。

每个 Kubernetes 新版本都会引入重大更改，因此，我们建议您先针对新的 Kubernetes 版本测试您的应用程序的行为，演练更新操作，然后再在生产集群上执行更新。

本篇作者