K8S和Docker到底啥关系？为什么K8S想要放弃Docker底层？

Posted 2021-08-16 思科CCIE训练营

K8S和Docker到底啥关系？别着急，咱们先来谈谈K8S。

什么是K8S？

K8S,全称kuternetes，因为K和S之间有8个字母，所以也叫做K8S。

K8S有什么用？

K8S是个有脑子的搬运高手，擅长搬运各种“箱子”，盘各种各样的容器玩。

 

K8S的大致架构，就像上面。Master节点，用来放“脑子”，“腿脚”搭在工作节点上“搬砖”，工作节点就是实际业务容器的存放地。

单个容器或多个关系密切的容器，被编成一组，称为pod。K8S就是以pod为单位进行编排操作。

本期训练营课题-K8S+Docker

长摁图片 扫码报名 获取双技能

↓↓↓↓↓↓

什么是容器呢？

容器一词的英文是container，其实container还有集装箱的意思，集装箱绝对是商业史上了不起的一项发明，大大降低了海洋贸易运输成本。让我们来看看集装箱的好处：

1. 集装箱之间相互隔离

2. 长期反复使用

3. 快速装载和卸载

4. 规格标准，在港口和船上都可以摆放

容器和集装箱在概念上是很相似的，容器的本质就是一种技术，一种把东西用箱子打包装起来的一种技术，里面的东西能够通过箱子实现彼此隔离，互不影响。

随着容器技术的火爆，利用容器架构来搭建业务系统的人越来越多。

可是，大家在实操中发现，像Docker之类的容器引擎，折腾少量容器还行。但如今的云原生应用、机器学习任务或者大数据分析业务，动辄就要使用成百上千的容器。要管理这么多容器，Docker们就力不从心了。

于是乎，市场上就出现了一大批容器编排工具，最为突出的工具就是K8S。

读到这儿，咱们总算是搞清楚了K8S和Docker的关系，也就是说，这两人就是一对小情侣，但是小情侣，谈个恋爱，也总有吵架的时候，不过这一次吵架不同以往，情况变得有些严重，“他/她“俩现在要分手了，K8S说，我也并不是非你不可，咱们分手吧，咱们不合适，典型的渣男经典语句。

具体什么情况呢，作为技术人，不得不吃瓜八卦一下，K8S官方发布公告，宣布自v1.20起放弃对Docker的支持，届时用户将收到Docker弃用警告，并需要改用其他容器运行时。

但Docker作为容器镜像构建工具的作用将不受影响，用其构建的容器镜像将一如既往地在集群中与所有容器运行时正常运转。Kubernetes将弃用 Docker。

 

目前，Kubelet中的Docker支持功能现已弃用，并将在之后的版本中被删除。

Kubelet之前使用的是一个名为dockershim的模块，用以实现对Docker的CRI 支持。但Kubernetes社区发现了与之相关的维护问题，因此建议大家考虑使用包含CRI完整实现 （兼容 v1alpha1 或 v1） 的可用容器运行时。

简而言之，Docker并不支持CRI（容器运行时接口）这一Kubernetes运行时API，而Kubernetes用户一直以来所使用的其实是名为“dockershim”的桥接服务。

Dockershim能够转换Docker API与CRI，但在后续版本当中，Kubernetes将不再提供这项桥接服务。

当然，Docker本身也是一款非常强大的工具，可用于创建开发环境。但为了了解造成当前状况的原因，我们需要全面分析Docker在现有Kubernetes架构中的作用。

本期训练营课题-K8S+Docker

资深讲师叶sir带你学习

技术和瓜 一个不落

↓↓↓↓↓↓

那么Docker为什么会被弃用？

综上所述，Kubernetes只能与CRI通信，因此要与Docker通信，就必须使用桥接服务。这就是第一点原因。

 

CRI运行时的实现方案主要有两种：

1. containerd

如果大家只是想从 Docker 迁移出来，那么 containerd 就是最好的选择。因为它实际上就是在 Docker 之内起效，可以完成所有“运行时”工作，如上图所示。更重要的是，它提供的 CRI 其实 100% 就是由 Docker 所提供。

 

2. CRI-O

CRI-O是主要由Red Hat员工开发的CRI运行时。它的最大区别在于并不依赖于Docker，而且目前已经在Red Hat OpenShift中得到使用。 有趣的是，RHEL 7同样不官方支持Docker。

不同于作为Docker组成部分的containerd，CRI-O在本质上属于纯CRI运行时、因此不包含除CRI之外的任何其他内容。

运行时分为两种：CRI 运行时和OCI 运行时。

1. CRI 运行时

正如之前所提到，CRI 是 Kubernetes 提供的 API，用于同容器运行时进行通信以创建/删除容器化应用程序。各容器化应用程序作为 kubelet 通过 IPC 在 gRPC 内通信，而且运行时也运行在同一主机之上；CRI 运行时负责从 kubelet 获取请求并执行 OCI 容器运行时以运行容器。

因此，CRI 运行时将执行以下操作：

①从 kubelet 获取 gRPC 请求。

②根据规范创建 OCI json 配置。

 

2. OCI运行时

OCI运行时负责使用Linux内核系统调用（例如 cgroups 与命名空间）生成容器。你可能听说过runC或者gVisor，这就是了。

CRI会通过Linux系统调用以执行二进制文件，而后runC生成容器。这表明runC依赖于Linux计算机上运行的内核。

这也意味着，如果你发现runC中的漏洞会使你获得主机 root 权限，那么容器化应用程序同样会造成root权限外泄。

很明显，恶意黑客会抓住机会入侵主机，引发灾难性的后果。正因为如此，大家才需要不断更新 Docker（或者其他容器运行时），而不仅仅是更新容器化应用程序本身。

 

总而言之

Docker确被弃用，大家应该开始考虑使用CRI运行时，例如containerd与CRI-O。containerd与Docker相兼容，二者共享相同的核心组件。如果你主要使用Kubernetes的最低功能选项，CRI-O可能更为适合。

废弃Docker，但别着急，为什么别着急，作为吃瓜群众的我们，我相信有很多“童鞋”读到这儿对K8S和Docker并不了解，简直就是“爱的魔力转圈圈”，一个字，“晕”。

没关系！不就是读不懂这篇文章么，简单，给您准备好了，绝对让你这瓜吃起来“倍儿香”。

想成为一名合格的技术类吃瓜群众，本期训练营特别适合你，请看下方大屏幕：

 

本期linux训练营

第一天：掌握Docker基础入门必会技能

 - 深入理解容器应用部署优势

 - 掌握Docker容器/镜像管理命令

 - 掌握通过Docker容器部署应用程序

 

第二天：深入理解k8s容器编排企业应用场景，快速掌握大厂技能

- 企业软件架构的演进过程精讲

- 掌握k8s核心组成部分，理解原理

- 掌握k8s+docker部署企业应用集群

仅需两天时间，K8S和Docker一锅烩，啥都会，这瓜吃起来自然就有香味了，掌握真正的大厂技术，走哪儿，你都有发言权，还等什么，赶快行动，做一名专业的技术“吃瓜群众”。