Kubernetes和Docker分道扬镳对你来说意味着什么
这一刻已经来了很久。Kubernetes在1.20版本之后弃用Docker作为容器运行时,转而使用使用为Kubernetes创建的Container Runtime Interface(CRI)的运行时。但是,这并不意味着Docker的死亡,也不意味着您也应该放弃自己喜欢的容器化工具。
事实上,作为Kubernetes的最终用户,对您来说并没有很多改变。您仍然可以使用Docker来构建容器,并且通过运行docker build生成的映像仍将在您的Kubernetes集群中运行。
那么,为什么要这么大惊小怪呢?发生了什么变化,为什么Docker突然看起来像是黑羊呢?我们应该继续编写Dockerfiles吗?
不要惊慌
这里引起混乱的原因是我们在谈论两种不同的事情。在Kubernetes集群节点内部,容器运行时守护程序管理着完整的容器生命周期:映像拉取和存储,容器执行和监督,网络附件等等。
Docker无疑是最受欢迎的选择。但是,Docker并非旨在嵌入Kubernetes中。这是所有问题的根源。Docker不仅仅是容器运行时;它是整个技术堆栈,具有许多UX增强功能,使我们可以轻松地与其进行交互。实际上,Docker本身包含一个高级容器运行时:contined。并且containerd将是您前进的容器运行时选项。
而且,这些UX增强功能对于Kubernetes来说不是必需的。如果有的话,它们是Kubernetes必须变通以获取其真正需求的障碍。这意味着Kubernetes集群必须使用另一个名为Dockershim的工具,该工具是容器化的。这增加了一定程度的复杂性以及团队应维护的另一种工具。另一个可能产生错误和问题的来源。
因此,这里真正发生的是Kubernetes将删除1.23版中的Dockershim,这将中断Docker支持。
你应该在乎吗?
那么,作为开发人员,您正在改变什么?没有那么多。如果在开发过程中使用Docker,则将继续这样做,并且不会发现任何差异。当您使用Docker构建映像时,结果并不是特定于Docker的。这是一个OCI(开放容器倡议)图片。Kubernetes及其兼容的容器运行时(例如容器化或CRI-O)知道如何提取和使用这些映像。这就是为什么我们首先要制定容器外观标准的原因。
另一方面,如果您使用的是托管的Kubernetes服务(例如GKE或EKS),则需要确保节点在运行受支持的容器运行时之前重新应用Docker支持或更新自定义配置(如果使用)任何。如果您是在本地运行Kubernetes,则还应该进行更改以避免不必要的问题和意外情况。
结论
在1.20版中,您将收到Docker的弃用警告。这种变化即将到来,并且像其他任何变化一样,它一开始可能会引起一些问题。但这不是灾难性的,从长远来看,它将使事情变得更容易。
我希望本文能使事情变得更清楚,并减轻一些焦虑。归根结底,这些更改对于您作为开发人员而言可能毫无意义。
相关文章
- 【技术种草】cdn+轻量服务器+hugo=让博客“云原生”一下
- CLB运维&运营最佳实践 ---访问日志大洞察
- vnc方式登陆服务器
- 轻松学排序算法:眼睛直观感受几种常用排序算法
- 十二个经典的大数据项目
- 为什么使用 CDN 内容分发网络?
- 大数据——大数据默认端口号列表
- Weld 1.1.5.Final,JSR-299 的框架
- JavaFX 2012:彻底开源
- 提升as3程序性能的十大要点
- 通过凸面几何学进行独立于边际的在线多类学习
- 利用行动影响的规律性和部分已知的模型进行离线强化学习
- ModelLight:基于模型的交通信号控制的元强化学习
- 浅谈Visual Source Safe项目分支
- 基于先验知识的递归卡尔曼滤波的代理人联合状态和输入估计
- 结合网络结构和非线性恢复来提高声誉评估的性能
- 最佳实践丨云开发CloudBase多环境管理实践
- TimeVAE:用于生成多变量时间序列的变异自动编码器
- 具有线性阈值激活的神经网络:结构和算法
- 内网渗透之横向移动 -- 从域外向域内进行密码喷洒攻击