AWS EKS 详细升级流程

Posted 2022-02-16 hsbxxl

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了AWS EKS 详细升级流程相关的知识，希望对你有一定的参考价值。

升级概述

AWS EKS作为K8S的云平台托管服务，也需要跟随K8S的版本迭代，进行定期升级更新。如何升级，以及升级的详细步骤，在本文有详细的记录和描述。

EKS更新时间线如下：

AWS

版本更新差异，请参考文档：

https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/kubernetes-versions.html

1.20版本的一个重要提示

· Docker 容器运行时间已逐步停止。Kubernetes 社群已经就这一点撰写了一篇详细的博客文章并提供了专门的常见问题页面。Docker 生成的镜像可以继续使用，并且会一如既往地发挥功能。您可以安全地忽略 kubelet 启动日志中打印的 dockershim 弃用警告消息。EKS 最终将迁移到 Containerd，后者将作为 EKS 优化版 Amazon Linux 2 AMI 的运行时间。您可以参阅容器路线图问题，了解更多详细信息。

Kubernetes 计划在即将发布的 1.24 版本里弃用 dockershim

http://dockone.io/article/2434814

升级方式：

1. 原地升级，直接点击AWS 控制台进行升级，控制层面升级，数据平面升级，插件组件升级

2. 通过切换node group的方式升级，控制层面升级，数据层面升级（增加新的node group，升级并切换），插件升级

3. 通过ALB， nginx的流量控制，进行升级

测试环境准备

1. 先安装AWS Cli 和 kubectl，参考链接如下

https://docs.aws.amazon.com/zh_cn/zh_cn/eks/latest/userguide/install-kubectl.html

本文测试内容为：从版本1.18升级到1.19

执行环境，需要先安装kubectl 1.18

2.安装EKS

2.1 配置kubectl，

aws eks --region us-east-2 update-kubeconfig --name eks1118

2.2 创建命令

AWS_REGION=us-east-2
AWS_DEFAULT_REGION=us-east-2
CLUSTER_NAME=eks11811
eksctl create cluster --name=$CLUSTER_NAME --version 1.18 --nodes=10
--node-type c5.large --managed --alb-ingress-access --region=$AWS_REGION

注释：

创建了 1.18 版或更高版本的集群后，您可以将随集群一起部署的 Amazon VPC CNI、CoreDNS 和 kube-proxy 附加组件迁移到 Amazon EKS 附加组件。有关更多信息，请参阅 Amazon EKS 附加组件。

3. 创建完成的EKS 1.18版本

AWS

升级测试

本文将升级方法分为三类：原地顺序升级，通过更新节点组的方式升级，ALB/Nginx流量分配方式升级

方法一：原地顺序升级

1．升级过程的官方文档说明：

Amazon EKS 对这些新节点上的网络流量执行标准基础设施和就绪运行状况检查，以确认它们是否按预期工作。如果任意一项检查失败，Amazon EKS 都将恢复基础设施部署，且您的集群保留为先前的 Kubernetes 版本。正在运行的应用程序不会受影响，并且您的集群绝不会处于不确定性或不可恢复的状态。Amazon EKS 会定期备份所有托管的集群，并且具有在必要时恢复集群的机制。我们会不断评估和改进我们的 Kubernetes 基础设施管理流程。

2．升级是不能回退的

AWS

3．只能逐个版本升级

AWS

4. 需要先升级控制层面，升级时间在30分钟左右，升级过程平稳。

AWS

5. 升级节点组方式

5.1. 注释：

https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/update-workers.html

有两种基本方法可以更新集群中自行管理的节点组以使用新 AMI：

• 迁移到新的节点组 – 创建一个新的节点组并将您的 Pod 迁移到该组。迁移到新的节点组要比简单地更新现有 AWS CloudFormation 堆栈中的 AMI ID 更为自然，因为迁移过程会以 NoSchedule 形式对旧节点组执行 Taint 操作，并在新堆栈准备好接受现有 Pod 工作负载后耗尽这些节点。 

• 更新现有自行管理的节点组 – 更新现有节点组的 AWS CloudFormation

堆栈以使用新 AMI。使用 eksctl 创建的节点组不支持此方法。 

6. 节点组升级过程—更新现有自行管理节点组

AWS

6.1. 节点组升级，有两个升级选项，Rolling和Force，建议Rolling方式升级

AWS AWS

6.2 升级过程中，会新增Node，用来转移pod

AWS

6.3. 在启动的过程中，node节点开始逐步替换

AWS

6.4. 托管节点更新行为

https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/managed-node-update-behavior.html

6.5 新的托管节点组升级完成，可以删除老的托管节点组

https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/delete-managed-node-group.html

整个升级过程在17分钟完成。升级时间会随着node数量的增多，而增加。

方法二：通过更新节点组的方式升级

1.添加新的节点组方式进行升级

https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/update-workers.html

有两种基本方法可以更新集群中自行管理的节点组以使用新 AMI：

迁移到新的节点组 – 创建一个新的节点组并将您的 Pod 迁移到该组。迁移到新的节点组要比简单地更新现有 AWS CloudFormation 堆栈中的 AMI ID 更为自然，因为迁移过程会以 NoSchedule 形式对旧节点组执行 Taint 操作，并在新堆栈准备好接受现有 Pod 工作负载后耗尽这些节点。

2. 新增节点组

AWS

可以选择不同机型的节点组

AWS

4. 查看节点组

5.

注意事项

这种方法，也是需要先更新控制层面，然后更新节点组。

可以通过命令行进行尝试，在更新控制层面之前更新节点组，会报错。需要先升级控制层面，并保证节点组的版本不高于控制层面。您可以将节点组升级到与控制层面的 Kubernetes 版本相同的版本。例如，如果您的集群运行 Kubernetes 1.19，则您可以使用以下命令将当前运行 Kubernetes 1.18 的节点升级到版本 1.19。

样例：

eksctl upgrade nodegroup \\
    --name=ng119 \\
    --cluster=eks11811 \\
    --kubernetes-version=1.19

Error: InvalidParameterException: Nodegroup Kubernetes version should be
equal to Cluster kubernetes version 1.18 or NodeGroup kubernetes version 1.18
  RespMetadata: 
    StatusCode: 400,
    RequestID:
"c9133322-2fe0-4fa2-94aa-792caa95f29d"  ,
  ClusterName: "eks11811",
  Message_: "Nodegroup
Kubernetes version should be equal to Cluster kubernetes version 1.18 or
NodeGroup kubernetes version 1.18",  NodegroupName: "ng119"

6. 更新节点组，两个节点组，是可以各自单独执行升级。

6.1. 可以在控制台升级，也可以通过命令行升级

AWS