Amazon EKS 版本管理策略与升级流程

Kubernetes 社区非常活跃，每3个月就会有一个新的版本发布。在版本迭代过程中，新功能特性也在不断地更新，状态从 alpha 到 beta 到 stable 。同时某些功能也会被逐渐弃用。对于 Kubernetes 这样一个具有非常多组件的分布式系统而言，版本管理是非常重要的话题。在这个博客里的，我们会尝试对 Kubernetes 的版本管理策略进行分析，并整理如何在 AWS EKS 上制定对应的版本升级策略和流程。

1. Kubernetes 与 EKS 版本支持介绍

Kubernetes 是有非常多公司和个人开发者参与的开源项目，从 CNCF 的统计网站我们可以从一些具体数字上直观了解 Kubernetes 社区的活跃程度。比如从下面这个图我们可以看到过去一年参与贡献的开发者平均约3000名，参与的公司也超过600家：

从 Kubernetes 的文档我们可以看到社区如何来进行整个软件发布周期的管理。每个Release从功能定义、测试到最后正式发布，大概需要3个月的时间，也就是每年大致进行4次版本发布：

对于如此频繁的新版本发布，如何进行支持也是一个非常重要的问题。因为每个版本都会有一个生命周期，因此社区并不会对所有发布过的版本都进行支持。目前的支持策略是对最新的3个版本提供支持。同时，从1.19版本开始，社区的支持时间从原来的9个月延长至了一年。

EKS 与Kubernetes社区的版本支持策略保持一致，同时EKS会对至少4个生产可用的Kubernetes版本提供技术支持。在社区发布新版本后，EKS 会进行测试然后再发布对应的EKS版本出来。EKS每个版本的技术支持时间会延长至14个月，即使上游社区对该版本已经不支持，在EKS的技术支持时间内，EKS 仍然会将相应的安全补丁 back port回EKS所支持的Kubernetes版本。具体的版本Release和End of Support(EoS)的时间会由EKS在官方文档上公布：

在EKS版本End of Support 后，EKS 会对控制平面进行自动升级，而这个升级的时间可能会发生在End of Support后的任何时间，因此建议用户在End of Support前安排时间进行主动的版本升级。

EKS 版本到期后自动进行升级的主要考虑是安全。Kubernetes社区会在版本停止支持后一段时间开始发布CVE补丁，同时也不鼓励对过期版本进行CVE的提交，因此针对旧版本Kubernetes的安全漏洞甚至不会被报告出来, 运行该版本的集群会暴露在这些未知的漏洞并且没有修复方案。云安全是AWS的首要考虑因素，而运行过期版本的EKS会面临较大的安全风险，因此EKS不允许托管的控制平面处在End of Support状态，从而进行自动升级。

一般在EKS版本发布的12个月后，EKS就会通过 Personal Health Dashboard 告知客户该版本的End of Support时间（大致是60天之后）并建议客户进行升级。建议客户在版本End of Support之前就计划升级，在End of Support之后，EKS会将版本强制升级至最老的可支持的版本，具体升级的时间点是无法预知的。

2.制定 EKS 版本升级策略

通常来说，建议客户使用最新的EKS支持的版本，除非客户应用对特定的K8S版本有依赖。如果EKS有新的版本发布，也建议客户安排时间主动进行升级。

客户可以结合自身的情况采用如下的升级策略

升级策略一：每季度升级
比如说客户在2020年10月份创建了EKS集群，使用了当时最新的版本1.18，那在2021年2月份EKS发布了1.19时，客户安排时间进行了升级。在2021年5月份EKS发布1.20时，也同样进行了升级。因此客户每3个月就进行一次版本升级，保持在了最新的EKS版本。每次升级跨越1个版本。

升级策略二：每年升级
比如说客户在2020年7月份创建了EKS集群，使用了当时最新的版本1.17，然后客户一直保持未做升级，那在2021年7月份左右，客户会开始收到通知建议进行升级，因为1.17 End of Support的时间会在2021年10月份。客户可以选择在2021年7月份升级至最新的版本 1.21，然后继续保持一年的时间不升级。每次升级跨越4个版本。由于kubernetes版本升级需要一个版本一个版本往上升，可以考虑直接创建一个新的集群，使用目标的新版本，直接重新部署应用，测试成功后直接将新集群切换为生产。

3.EKS 版本升级流程

升级前检查：
详细的升级流程参考如下文档：
https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html
该文档整理了整个升级流程并针对某些特定Kubernetes版本升级过程需要注意的地方进行提示，建议在每次版本升级前进行通读。同时考虑使用EKS创建一个新版本的集群并部署应用进行测试

如下列出几个重点的检查点供参考：

a, 检查 Kubernetes manifest
Kubernetes 版本升级可能会带来 API deprecation ，即某些API会被弃用。特别是从1.15 至 1.16 , 被弃用的API数量较多。因此需要先检查现有的 manifest 文件所使用的API在新的版本下面是否还继续支持。
可以考虑使用 kube-no-trouble 工具进行API deprecation的检查

b, 详细检查待升级的kubernetes版本的change log:
https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html
change log会显示每个EKS版本带来的更新，包括新支持的feature，或是一些配置上的变化，以便评估新版本的变化对应用的影响

c, 检查数据平面 Node 的版本
升级控制平面前需要检查 Node 当前所属版本，对于托管节点组和Faragte Node，版本需要与控制平面保持一致。对于非托管节点组，也建议先将其版本升级至与控制平面一致。

升级流程：

从上图可以看到，整体的升级包括三个部分：控制平面升级、数据平面升级以及Add-on的升级。接下来分别介绍这三部分的升级过程：

升级控制平面版本

可以通过 Console 或者 eksctl 命令行工具进行控制平面的升级，升级时长大概是25分钟。EKS 控制平面中 api-server 是进行 HA 配置的，在某个 api-server 所在实例进行版本更新过程中，连接到上面的请求可能会失败，这时候只需要重试即可。因为只涉及控制平面相关组件的升级，部署在Node上面的应用是不会受影响。

那如果控制平面升级出错，如何进行回退？升级过程中，EKS会自动创建新版本的api server节点，进行一系列健康检查，确保新版本的Api server可以正常工作后才会将旧版本的api server删除。如果新版本的api server的健康检查失败后，EKS会自动将集群回退到旧版本，其上运行的应用程序也不会受到影响。同时，EKS也会定期自动备份集群相关信息，以确保在需要的时候可以对集群配置进行恢复。因此，简单来说，这个控制平面的升级过程是完全自动化的，客户不需要干预，如果有问题也会自动回退到旧版本，确保集群处于可用状态

升级Nodes版本

如果使用的是EC2 托管节点组：
可以通过 Console 或 eksctl 命令行工具进行版本升级。托管节点组会自动对节点进行滚动升级。节点升级前会自动驱逐Pod并对节点进行隔离等，以确保对应用影响最小。托管节点组的具体升级过程可以参考这个文档。对于使用托管节点组升级的具体步骤，可以参考这个博客，包含了使用托管节点组与自定义AMI来进行版本升级的具体操作步骤

如果使用的是EC2 非托管节点组：
可以考虑建新的节点组，将应用/Pod地迁移至新的节点组后，再将旧节点组删除。如果使用的是eksctl工具创建的节点组，在删除时eksctl会自动先将Pod驱逐，并将节点隔离后再删除节点。如果是通过Console或CLI创建节点组，则需要按照文档进行更多的检查和操作，详细的步骤参见这个文档。考虑到托管节点组在升级时较为便利，建议客户从非托管节点组转到托管节点组。

如果使用的是Fargate:
控制平面升级后，新部署到Fargate的Pod对应的Node就是新版本了。因此如果需要升级Fargate Node，则将旧的Pod删除新重新部署即可。如果Fargate Node当前版本低于1.16，则控制平面在升级到1.17时会失败。因此需要先将Fargate Node升级至1.16，再进行控制平面升级

升级Add-ons版本：

默认情况下 EKS 为会每个集群部署三个 Add-ons，包括 VPC-CNI, CoreDNS 和 kube-proxy，并由客户自行进行管理，包括配置维护和版本升级等。从EKS 1.18版本开始，用户可以选择由EKS来托管将上述 Add-ons ，后续相关的Add-on的版本升级等就可以通过EKS Console/API 来进行操作，简化相关的运维工作。

VPC-CNI:
EKS 默认使用的 CNI 是 VPC-CNI ，这个网络插件可以让EKS中的Pod获取到VPC的私有地址。对于EKS默认安装的由用户自行管理的VPC CNI, 其版本为 1.7.5-eksbuild.1 ，如果通过 EKS 进行 Add-ons 的托管，其版本为 1.7.5-eksbuild.2 。如果需要升级至最新的 1.9 版本，则需要升级至 1.8 版本，再升级至 1.9 版本。可以参考这个文档，以进一步了解具体如何去对自行管理和EKS托管的 VPC-CNI 进行版本升级。

CoreDNS:
EKS 默认安装 CoreDNS 做为 Kubernetes Cluster DNS 。通过下表可以查看到不同的EKS版本对应部署的CoreDNS的版本：

在EKS 控制平面与Node升级后，可以参考这个文档，以进一步了解具体如何去对自行管理和EKS托管的 CoreDNS 进行版本升级。

kube-proxy:
kube-proxy 会维护EC2 Node上的网络规则，每个EKS版本都有对应的 kube-proxy 版本：

上表的 minimal version 主要是 EKS Distro 使用，在 AWS 上部署的 EKS 建议使用对应版本的 default version 即可。注意到 Fargate nodes 上并不部署 kube-proxy，因此如果 EKS 中只有 Fargate Node 的话，则无须进行 kube-proxy 的升级。
在EKS 控制平面与 Node 升级后，可以参考这个文档，以进一步了解具体如何去对自行管理和EKS托管的 kube-proxy 进行版本升级。