Devops技术栈讲解：Kubernetes和Docker的之间存在什么关系？

作为一名容器时代的程序员相信你已经或多或少接触过Docker，但同时你也会发现Docker虽然流行了多年，但之前却很少有公司直接将线上应用通过Docker容器进行大规模地部署。但最近三年，你会发现几乎绝大多数有条件的公司都已经在使用Kubernetes部署和发布自己的线上业务了。对一名普通开发人员来说，这一切可能发生得太快，以至于你还没有搞清楚它是怎么发生的，也会疑惑Docker和Kubernetes之间到底是个什么关系。

在今天的内容中，我们从Kubernetes的系统架构及容器编排核心概念两个方面来简单聊一聊这个问题，希望能帮助到你更好地理解Docker和Kubernetes之间因果关系。

Kubernetes介绍

在具体介绍Kubernetes之前不得不再提一下Docker，如果你用过Docker部署过程序，那么你一定会非常享受它带给你的丝滑体验，而联想到在此之前发布一个程序需要写各种脚本、进行各种环境匹配的糟糕体验，那么相信你的这种感觉会更加强烈。

而Docker之所以能做到这一点，就在于它以“Docker镜像”的方式一举解决了应用打包和发布这一困扰业界多年的技术难题，并且大大降低了普通开发人员运维部署应用的门槛。正是因为解决了应用打包这个根本性的问题，才使得Docker很快就被广大开发/运维人员所接受，迅速成为炙手可热的技术，并在一定时间内引领了容器化技术发展的浪潮。

那么Docker这么好用为什么还会出现Kubernetes呢？事实是Docker作为单一的容器技术工具并不能很好地定义容器的“组织方式”和“管理规范”，难以独立地支撑起生产级大规模容器化部署的要求。因此容器技术的发展就迅速走向了以Kubernetes为代表的“容器编排”的技术路线，而这也是为什么Docker容器没有直接在生产环境中大规模部署的关键原因。

上面我们提到了“容器编排”的概念，了解到相对于Docker单一容器技术而言，Kubernetes容器编排技术可以很好地实现大规模容器的组织和管理，从而使容器技术实现了从“容器”到“容器云”的飞跃！那么Kubernetes技术是从何而来？而又真正解决了什么问题呢？

从背景上说，Kubernetes是由Google与RedHat公司共同主导的开源“容器编排”项目，它起源于Google公司的Borg系统。所以它在超大规模集群管理方面的经验要明显优于其他容器编排技术，加上Kubernetes在社区管理方面的民主化，使得它很快打败了Docker公司推出的容器编排解决方案(Compose+Swarm)，从而成为了容器编排领域事实上的标准。

而在功能上Kubernetes是一种综合的基于容器构建分布式系统的基础架构环境，它不仅能够实现基本的拉取用户镜像、运行容器，还可以提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力，而更重要的是Kubernetes可以按照用户的意愿和整个系统的规则，高度自动化的处理好容器之间的各种关系实现“编排”能力。

此外Kubernetes的出现也重新定义了微服务架构的技术方向，目前通常所说的“云原生”及“Service Mesh(服务网格)”等概念，很大程度上也是依赖于Kubernetes所提供的基础能力。由于篇幅和作者知识水平有限，这里就不展开去聊了，感兴趣的读者可以参考其他专业书籍或技术资料。

Kubernetes整体系统架构

前面我们简单介绍了Kubernetes的起源和背景，接下来看看Kubernetes的整体系统架构，如下图所示：

Devops技术栈讲解：Kubernetes和Docker的之间存在什么关系？

如上图所示，Kubernetes在架构上主要由Master和Node两种类型的节点组成，这两种节点分别对应着控制节点和计算节点。其中Master即控制节点，是整个Kubernetes集群的大脑，主要负责编排、管理和调度用户提交的作业，并能根据集群系统资源的整体使用情况将作业任务自动分发到可用Node计算节点。具体看Master节点主要由三个紧密协作的独立组件组合而成，它们分别是：

kube-apiserver：是Kubernetes集群API服务的入口，主要提供资源访问操作、认证、授权、访问控制及API注册和发现等功能机制。
kube-scheduler：负责Kubernetes的资源调度，能按照预定的调度策略将Pod调度到相应的机器上。
kube-controller-manager：负责容器编排及Kubernetes集群状态的维护，例如故障检测、自动扩展、滚动更新等。

需要说明的是，上述组件在工作状态下还会产生许多需要进行持久化的数据，这些数据会通过kube-apiserver处理后统一保存到Etcd存储服务中。所以从这个角度看kube-apiserver不仅是外部访问Kubernetes集群的入口，也是维护整个Kubernetes集群状态的信息中枢。

而在Kubernetes计算节点中，除了上述3个系统组件外，其他基本与Master节点相同，而其中最核心的部分就是kubelet组件。它的核心功能具如下：

通过CRI(Container Runtime Interface)远程接口同容器运行时（如Docker）进行交互，对容器生命周期进行维护。其中CRI接口会定义了容器运行时的各项核心操作，例如启动容器所需的命令及参数等。
通过GRPC协议同Device Plugin插件交互，实现Kubernetes对宿主机物理设备的管理。
此外kubelet另一个重要的功能则是通过CNI（Container Networking Interface）来调用网络插件为容器配置网络，以及通过CSI（Container Storage Interface）和存储插件交互为容器配置持久化存储。

在Kubernetes中kubelet会通过CRI接口同容器运行时进行交互，而容器运行时则通过叫做OCI容器运行时规范与底层Linux操作系统进行交互(涉及对Namespace、Cgroups等资源的操作，具体可以了解下Docker的技术原理)。需要强调的是，这里所说的容器运行时并不仅仅指Docker，而是所有实现了CRI接口规范的容器项目都可以作为Kubernetes的容器运行时存在。这是因为Kubernetes从设计之初就没有把Docker作为整个架构的核心，而只是将其作为最底层的一个容器运行时来实现。

但这并不是说Kubernetes就完全抛弃Docker了，要知道Docker最大的成功并不是它的容器运行时技术，而是它定义的“容器镜像”开创性地解决了困扰业界多年的应用打包难题，所以虽然Kubernetes并不完全依赖于Docker的容器运行时技术，但容器镜像的定义标准却是所有容器技术都绕不开的存在。

况且从Kubernetes架构设计上看，Kubernetes并没有打算重复造轮子而对已有的容器技术进行替代，它更关注的是对运行在大规模集群中的各种任务根据其关系进行作业编排及管理，所以任何实现了CRI、CNI、CSI等协议标准的容器技术都可以无缝地与Kubernetes集成。从这个角度看，Docker与Kubernetes的关系并不是替代的关系，而是平台与组件的关系，Kubernetes可以利用现有的Docker容器运行时技术，但却并不完全依赖Docker。而这也正是Kubernetes为什么被称作容器编排技术而不仅仅只是容器技术的原因。

Kubernetes容器编排概述

我们说处理任务之间的各种关系，实现容器编排是Kubernetes的核心技术能力，也是其大规模流行的关键原因。那么容器编排到底是个什么概念？在Kubernetes中是如何实现容器编排的呢？

其实所谓容器编排，通俗点举例就是如果两个应用调用关系比较紧密，那么我们希望运行时将它们部署在同一台机器上，从而提升服务之间的通信效率。而能够支持自动将具有此类关系的应用，以容器的方式部署在同一台机器上的技术就是容器编排。

当然，这里所说的紧密关系只是一种形象的说法，实际的技术场景中这种紧密关系可以被划分为很多类型，例如Web应用与数据库之间的访问关系、负载均衡和它后端服务之间的代理关系、门户应用与授权组件之间的调用关系等。

而对于Kubernetes来说，这样的关系描述显然还是过于具体，因为Kubernetes的设计目标不仅仅是能够处理前面提到的所有类型的关系，还要能够支持未来可能出现的更多种类的关系。这就要求Kubernetes要从更宏观地角度来定义任务之间的各种关系，并且能为将来支持更多种类的关系留有余地。

具体来说，Kubernetes是对容器间的访问进行了分类，如果这些应用之间需要非常频繁的交互和访问，或者它们之间存在直接通过本地文件进行信息交换的情况，那么在Kubernetes中可以将这些容器划分为一个“Pod”,而Pod中的容器将共享同一个Network Namespace、同一组数据卷，从而实现高效率通信。

Pod是Kubernetes中最基础的编排对象，是Kubernetes最小的调度单元，也是Kubernetes实现容器编排的载体，其本质上是一组共享了某些系统资源的容器集合。在Kubernetes中围绕Pod可以延伸出其他核心概念，具体如下图所示：

Devops技术栈讲解：Kubernetes和Docker的之间存在什么关系？

如上图所示，在Kubernetes中Pod解决了容器间紧密协作（即编排）的问题，而Pod要实现一次启动多个Pod副本就需要Deployment这个Pod多实例管理器；而有了这样一组Pod后，我们又需要通过一个固定网络地址以负载均衡的方式访问它，于是又有了Service。

而根据不同的编排场景Pod又衍生出描述一次性运行任务的Job编排对象、描述每个宿主机上必须且只能运行一个副本的守护进程服务DaemonSet、描述定义任务的CronJob编排对象、以及针对有状态应用的StatefulSet等多种编排对象。而这些编排对象正是Kubernetes定义容器间关系和形态的主要方法。