亚马逊AWS官方博客
Amazon EKS 1.20 已发布
Amazon Elastic Kubernetes Service(Amazon EKS)团队很高兴地宣布支持 Kubernetes 1.20。我有幸在 2020 年 9 月至 12 月期间加入上游发行团队为此次发行服务,并且很高兴 Amazon EKS 客户能够体验到“最完美发行版”的所有荣光。
Kubernetes 1.20 官方发行版徽标。© The Kubernetes Authors CC BY 4.0
更快推出新版本一直是 EKS 团队的首要任务,而在此版本发布之时,我们已在马不停蹄地研究下一个版本。上游 Kubernetes 项目最近已将其发布节奏从每年四次改为三次。这一变化加上项目的不断成熟,未来的发行版将会包含远远更加丰富的功能。我们将继续努力,确保 EKS 轻松支持所有新的优秀功能。
此次发行也标志着对 EKS 1.15 的支持停止。由于移除了许多已弃用的 API,升级到 Kubernetes 1.16 的挑战非常大。请务必查看我们的 1.16 升级准备的博客文章和 Amazon EKS 发行日历,以了解未来的相关日期。
Kubernetes 1.20 亮点
有关此发行版的具体详细信息,请参阅上游博客文章和发行说明。 在本文中,我将介绍此发行版的一些亮点。
Kubernetes 中的功能受到发行阶段的限制。Alpha功能最前沿,仅推荐用于短暂测试。这些功能通常会默认禁用,可能会随时更改或被移除。Beta功能通常会默认启用,并且认为是可以安全使用的。资源结构可能会改变,但这时是提供反馈并帮助定型功能的最佳时候。稳定功能是正式发行版的功能,可以安全地使用。这些功能与当前主要版本相比不应有任何颠覆性的更改。自推出以来,EKS 一直支持稳定的功能以及默认启用的Beta功能。
TTL 控制器
Kubernetes 中的作业是运行短暂任务(在完成之前持续运行)的工作负载,而不是针对长期运行的服务或应用程序的部署。作业通常用于生成报告或对数据执行提取、转换和加载(ETL)操作等任务。默认情况下,作业创建的 Pod 将在完成后停留在集群中。这是为了便于您观察作业的日志和结果,但运维人员需要清理或者构建执行清理所需的工具。
Kubernetes 1.12 首次推出了 TTL 控制器,以帮助解决这一痛点。它提供了一种生存时间(TTL)机制来清理已完成的作业。当作业被标记为 Completed或 Failed时,系统将在 .spec.ttlSecondsAfterFinished.规定的时间之后删除该作业(以及任何创建的 Pod).
尽管 TTL 控制器在 1.21 版中已转为Beta版,但在过去的几个发行版中,它没有发现重大改变。作为我们最受欢迎的功能之一,经过全面的测试后,我们决定在 EKS 1.20 中启用此内部测试版功能。对于 AWS Fargate 上的 Amazon EKS 来说,由于在清理完成之前,已完成的任务将会继续产生成本,因此这一功能将尤其有用。
PID 限制功能转为正式发行版
进程 ID(PID)代表正在服务器上运行的进程。不同的 Linux 安装具有不同的 PID 限制,并且直接取决于可用的计算资源量。PID 限制功能提供了每节点限制和每 Pod 限制,这些限制可以设置为 kubelet 的标志(需要与上述相同的节点限制)。借助这些限制,您可以为操作系统预留一定数量的 PID,从而防止 Kubernetes 工作负载耗尽系统操作。
卷快照功能转为正式发行版
容器存储接口(CSI)用于在集群中预置持久性的存储。当您使用 Amazon Elastic Block Store(Amazon EBS)CSI 驱动程序并创建持久卷时,控制器将能够代表您预置 EBS 卷。EBS CSI 驱动程序最近也转为正式发行版。
EBS 快照是 EBS 卷上数据的时间点备份。您可以从快照创建新的 EBS 卷,从而创建克隆或回滚磁盘。Kubernetes 卷快照使用原生的 Kubernetes 资源在集群中实现此功能。有关创建和使用 EBS 快照的更多信息查,请参阅此博客文章。
API 优先级和公平性功能转为公开测试版
API 优先级和公平性(APF)让您能够对来自繁忙的控制器以及向可观察性工具等 Kubernetes API 服务器发出请求的其他应用程序的流量进行排序并设置权重。以前的解决方案要求在 Kubernetes API 服务器上设置标志,而EKS 不支持客户定义的标志。这是一项更高级的功能,可用于解决各种问题,例如可能会淹没 API 服务器并导致请求失败的突增流量。
如果您看到有请求被丢弃或发生延迟,集群运维人员可以调整 APF 的精细控制。此外还有一种为某些终端节点或服务(如运行状况和就绪检查)禁用 API 速率限制的机制。更多信息请参阅文档。
RootCAConfigMap 转为公开测试版
从 1.20 版开始,您可能会注意到所有命名空间中都有一个新的默认 ConfigMap。
此 ConfigMap 包含 Kubernetes API 服务器的证书颁发机构捆绑包,从而便于控制器和服务在发出 API 请求时验证其连接。这是我们提高服务账户令牌安全性的持续工作的一部分。
Docckershim 被弃用
您也许还记得几个月前 Kubernetes 用户的讨论首次出现在发行说明中。Don’t Panic: Kubernetes and Docker(不要惊慌:Kubernetes 与 Docker)由我们自己的 AWS 开发者布道师 Justin Garrison 在 Kubernetes 博客上联合撰写。简而言之,不用担心。集群中使用的容器运行时将来可能会发生变化,但是 Docker 容器仍然可以正常工作,您应该不会注意到这些变化。您可以放心地忽略 kubelet 启动日志中打印的 dockershim 弃用警告消息。对于 EKS 优化的 Amazon Linux 2 AMI,EKS 最终将转向以 containerd 作为运行时。您可以关注容器路线图问题以了解更多详细信息。
Amazon EKS 1.20 的具体变化
每个 Kubernetes 发行版都可能会包含一些 EKS 特定的更改。这些通常会侧重于与其他 AWS 服务的互操作性。从 EKS 1.20 开始,我们创建了一些新的默认服务账户和角色,以向不同的 Kubernetes 组件提供 RBAC 权限。
在 EKS 1.20 中,Bottlerocket(由 AWS 为运行容器而构建的基于 Linux 的开源操作系统)已更新至内核版本 5.10。您可以使用 EKS 优化的 Bottlerocket AMI 为您的集群启动自行管理的节点,此外我们也在努力工作,以为 EKS 托管节点组提供对 Bottlerocket 的原生支持。
有关更多信息,请参阅 1.19 版以来的更改日志和 EKS 1.20 文档。
后续步骤
从 1.19 升级
从 1.19 升级到 1.20 应会十分轻松,因为基本没有突破性的变化。与往常一样,请首先检查升级说明。保持集群的更新是使用 Kubernetes 的一个重要方面。EKS 已集成自动化升级,但团队仍应提前计划。要开始升级集群,请参阅此博客文章和 Amazon EKS 文档。
计划升级
如果您还在使用 Kubernetes 1.15,那么是时候升级了。支持周期已于 2021 年 5 月 3 日停止,您的控制平面最终将自动升级。我们建议您不要依赖 Amazon EKS 的自动更新进程,而应主动采取行动并更新控制平面。有关更多信息,请参阅版本弃用常见问题。对 Kubernetes 1.16 的支持将于 2021 年 7 月 25 日停止。因此建议提前计划并立即升级。有关更多信息,请参阅 EKS 发行日历。