Kubernetes 1.24删除Dockershim，为有状态工作负载腾出空间

Kubernetes容器编排引擎的最新版本，绰号为“Stargazer”，旨在更好地支持数据库、微服务和其他新兴用例，同时摆脱此前阻碍K8s核心开发人员生产力的失误。

据管理该开源项目的CNCF称，总的来说，这个版本有46个“增强”。15项增强功能已升级到稳定状态，这意味着它们已准备好投入生产使用，15项增强功能正在升级到beta，13项增强功能已进入alpha状态。

首先，从老版本走出去。

那些仍在使用Docker运行时引擎的人必须找到替代品或商业解决方案，才能将其用于Kubernetes的新版本：从1.24开始，Dockershim将不再受支持。

2020年决定放弃对Docker运行时的支持。尽管Docker在容器的使用方面首次取得了广泛的成功，但Kubernetes还是转向了2016年推出的标准化容器运行时接口，以允许Kubernetes-Kubelet节点引擎与任何兼容的运行时引擎接口，其目标是不完全依赖Docker本身。

当然，最初的Docker引擎本身并不兼容，因此制作了一个垫片来操作K8s上的运行时。在这次发布之前，该垫片一直被支持。

此更改将与仍在使用Docker引擎本身的正在运行的部署相关，在更新之前，需要将其更新到兼容的运行时（CRI-O或containerd）或商用Mirantis容器运行时（MCR）。

在Docker开发工具上构建的容器现在构建为在CRI规范上运行，并且不受此更改的影响。“对于大多数应用程序开发人员来说，这将是一个透明的变化。”v1.24发布项目负责人James Laverack解释道。

虽然Laverack没有估计有多少部署仍然依赖Docker引擎，但他指出，仍然这样做的唯一原因是如果Kubernetes功能是在其API之外访问的。在这些情况下，这样做的应用程序需要进行一些升级工作。

Laverack解释说，通过API以外的方式访问Kubernetes是有问题的，原因有几个。首先，它可以将用户锁定为只使用一个引擎（在本例中为Docker）来访问Kubernetes功能。

Docker垫片也存在问题，因为它为K8s维护人员带来了大量维护工作。有很多专门用来处理Docker的代码（与CRI本身并行），而且都有缺陷。Lavelack说，消除支持有助于K8s工程师简化代码库。

“社区认为，删除它将使代码库的这一部分得到简化，减少bug，提高稳定性，并提高更多发布的速度。”Laverack说，“因此，这确实是一个基础性的改变，将有助于Kubernetes在未来以更好的质量推出更多功能。”

还有什么？

Stargazer还展示了为Kubernetes提供存储感知控制所做的工作。对于那些计划在Kubernetes上运行有状态工作负载（如数据库）的人来说，这将是个好消息。Kubernetes-aware应用程序将能够使用这些功能以更精细的粒度管理存储，提供调整卷大小的能力，或允许应用程序根据任何给定时刻可用的剩余存储做出决策。

作为API服务器的alpha版本引入的上下文日志功能将帮助平台工程师和Kubernetes核心开发团队自己调试Kubernetes。该版本现在在测试版中支持Kubernetes OpenAPI的第3版，该版本允许第三方开发人员编写operator和自定义资源定义来扩展Kubernetes。

对于微服务开发者来说，好消息是：Kubernetes 1.24支持谷歌的gRPC通信协议。

一个新的探测功能消除了设置单独的HTTP服务器来检查容器准备就绪和可用性的需要。Lavelack说，微服务经常使用gRPC进行通信，这将允许开发者在gRPC上标准化他们的堆栈。

安全性已经向前迈出了一大步，现在可以使用Sigstore签署发布工件。K8s用户现在可以签署他们的软件组件，确保它们没有被篡改。

Chainguard开源负责人Tracy Miranda在Sigstore的一篇博客文章中表示：“这是保护Kubernetes生态系统完整性的一大步，并证明了由于供应链攻击的增加，大规模的代码签名是可能的，而且坦率地说是必要的。”

原文链接：

https://thenewstack.io/kubernetes-1-24-drops-dockershim-makes-space-for-stateful-workloads/