Kubernetes1.24新特性解读

科技 2022-05-14 22:03:41
导读 5月4日,Kubernetes版本正式发布。像以前的版本一样,Kubernetes带来了大大小小几十个变化。几十项涉及基础设施、运维、应用开发的方方面面

5月4日,Kubernetes版本正式发布。像以前的版本一样,Kubernetes带来了大大小小几十个变化。几十项涉及基础设施、运维、应用开发的方方面面,有些人可能很难全部理解。本文不打算一一列举。我结合自己的经验,谈谈应用开发者可能比较关注的几点。

Kubernetes版本1.24标志:观星者

首先是官方取消了dockershim支持。一年多前,Kubernetes版本宣布对Docker的支持处于“已弃用”状态,不再进化,“将在未来版本中移除”。此次发布的1.24版本,就是所谓的“正式移除Docker支持”。然而,Docker公司声称,它可以在Kubernetes环境中继续使用Docker,其Docker桌面产品的用户仍然可以无缝地使用Kubernetes的最新版本。这是怎么回事?

事实上,如果你仔细阅读Kubernetes的官方1.24版本更改日志,你会发现它对Docker支持的表述与一年前的1.20版本有着微妙的不同。

变更日志版本1.20的屏幕截图

变更日志版本1.24的屏幕截图

Kubernetes移除Docker主要是因为Docker长期不支持Kubernetes推广的CRI容器运行时接口标准,所以Kubernetes社区维护了一个dockershim组件专门对接Docker。

这在当年Docker处于垄断地位的时候是非常必要的。随着containerd、kata等容器运行时的发展和成熟,特别是当containerd在生产环境中被广泛使用时,Kubernetes社区决定不再维护dockershim。

然而,最近两年,米兰蒂斯(2019年11月收购了Docker Enterprise)和Docker公司不断投资支持Kubernetes。目前社区中已经有一个独立于Kubernetes并支持CRI的“Shim”:CRI-Docker,继续实现Kubernetes和Docker的连接。

Docker桌面以其出色的用户体验赢得了众多开发者的青睐。自从Kubernetes版本发布以来,作者一直在寻找Docker桌面的替代品,也尝试了很多,但目前还没有找到一款可以与之媲美的产品。Cri-dockerd使Kubernetes 1.24能够继续对接Docker容器运行时,这意味着用户可以像以前一样在Docker桌面中一键安装并无缝使用最新版本的Kubernetes,这对开发者来说无疑是个好消息。

同时,由于Docker映像已经成为各类容器在运行时使用的标准镜像格式,因此开发和使用Docker,在生产或分发到客户的环境中使用其他容器,可能会成为一种长期的普遍现象。

第二个我想说的是Kubernetes的工作。Kubernetes提供作业资源来支持批处理类的应用程序负载。但是当我们要运行作业进行并行处理或者分布式计算的时候,就会遇到一个问题:Kubernetes中的Pod是动态创建和回收的,也是基于Kubernetes的作业来发货的。

行批处理负载的优势之一,因为资源能够在需要时才被占用,用完可以立即回收,然而这却会导致任务在往各个Pod分配时缺少依据(基于机器的并行计算系统中往往需要将主机名称等相对固定的标识作为任务调度的输入)。

  在早些版本中,Kubernetes官方建议引入消息队列或者内存数据库来给Job的各个Pod分配编号以解决该问题[1],这无疑提升了应用的复杂度且引入了第三方组件的运维问题。在Kubernetes 1.24版本中,有一项从Beta阶段提升为正式特性的功能叫做“Indexed Job”,该特性会给同一个Job的各个Pod在环境变量中注入一个编号索引,应用可以根据这个编号为各个Pod分配具体的task。

  去年该特性还在beta阶段时,笔者尝试将一个基于Kubernetes Job的云原生分布式图计算应用从依赖外部消息队列分配task改为Indexed Job,应用的可维护性、稳定性和资源消耗都得到了明显的改善。

  第三个推荐开发者关注的特性是gPRC健康状态探针已经是beta状态了,这是一个很值得期待的功能。gRPC协议在云原生应用中得到日益广泛的使用,然而Kubernetes过去一直缺少gRPC原生的健康状态探针支持,使得对gRPC服务的启动、存活和就绪状态检查都需要依赖其他手段,官网有一篇文章对这些技术手段进行了介绍[2],从文章中不难看出,这些方法对于应用迁移上Kubernetes的成本和云原生应用的可维护性、可用性都会有一定的影响。在Kubernetes原生支持gRPC探针后,这些问题得到了有效的解决,采用gRPC协议构建云原生应用的同仁们可以期待一下这个特性未来从beta状态变为正式可用。

  最后想到一个非常有意思的更新,1.24版本以后,kubeadm安装Kubernetes集群时,不再给运行控制面组件的节点标记为“master”,因为这个词被认为是“具有攻击性的、无礼的(offensive)”。近几年,一些用master-slave来表示主-从节点的计算机系统纷纷改掉术语,slave前两年就已经销声匿迹了,现在看来master也不能用。

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时候联系我们修改或删除,多谢

最新文章