一文了解docker与k8s

随着 k8s 作为容器编排解决方案变得越来越流行，有些人开始拿 Docker 和 k8s 进行对比，不禁问道：Docker 不香吗？

k8s 是 kubernetes 的缩写，'8' 代表中间的八个字符。

其实 Docker 和 k8s 并非直接的竞争对手两者相互依存。 Docker 是一个容器化平台，而 k8s 是 Docker 等容器平台的协调器。

1、容器化时代

（1）虚拟化技术已经走过是三个时代，没有容器化技术的研究就不会有Docker技术的诞生。

1）物理机时代： 多个应用程序排在一台机器上。

2）虚拟机时代：一台物理机器安装多个虚拟机(VM),一个虚拟机跑多个程序。

3）容器化时代：一台物理机器安装多个容器实例(Container),一个容器跑多个程序。

（2）容器化解决了什么问题？

用一段话描述：

测试人员：你这个功能有问题。

开发人员：我本地是好的呀！

开发人员编写代码，在自己本地环境测试完成后，将代码部署到测试或生产环境中经常会遇到各种各样的问题。明明本地完美运行的代码为什么部署后出现很多 bug，原因有很多：不同的操作系统、不同的依赖库等。总结一句话：因为本地环境和远程环境不一致。

容器化技术正好解决了这一关键问题，它将软件程序和运行的基础环境分开。开发人员编码完成后将程序打包到一个容器镜像中，镜像中详细列出了所依赖的环境，在不同的容器中运行标准化的镜像，从根本上解决了环境不一致的问题。

注：容器的概念已经出现不短的时间。但直到 2013 年开源项目 Docker 的出现才极大推广了容器这项技术，并推动了软件开发中容器化和微服务的趋势，这种趋势后来被称为云原生开发。

2、容器化技术解决的核心问题

可移植性：不依赖具体的操作系统或云平台，比如在阿里云或腾讯云直接随意迁移。
占地小：容器只需要其应用程序以及它需要运行的所有容器和库的依赖清单，不需要将所有的依赖库都打包在一起。
共享 bin 和 lib：不同的容器可以共享 bin 和 lib，进一步节省了空间。
 

3、docker的出现

2010 年一位年轻小伙子在美国旧金山成立了一家名叫【dotCloud】的公司， 开发了 Docker 的核心技术，从此开启了容器技术的时代。后面 dotCloud 公司将自己的容器技术进行了简化和标准化，取名为 Docker，就是大家熟悉的鲸鱼 logo。

2013 年 dotCloud 公司宣布将 Docker 开源，随着越来越多的工程师发现了它的优点， Docker 的人气迅速攀升，成为当时最火爆的开源技术之一。

当前有 30％ 以上的企业在其 AWS 环境中使用 Docker，并且这个数字还在继续增长。

此时的 Docker，已经成为行业里人气最火爆的开源技术，没有之一。甚至像 Google、微软、Amazon、VMware 这样的巨头，都对它青睐有加，表示将全力支持。

Docker 火了之后，dotCloud 公司干脆把公司名字也改成了 Docker Inc. 。

Docker 和容器技术为什么会这么火爆？说白了，就是因为它 “轻”。在容器技术之前，业界的网红是虚拟机。虚拟机技术的代表，是 VMWare 和 OpenStack 。

相信很多人都用过虚拟机。虚拟机，就是在你的操作系统里面，装一个软件，然后通过这个软件，再模拟一台甚至多台“子电脑”出来。

在 “子电脑” 里，你可以和正常电脑一样运行程序，例如登录 QQ。如果你愿意，你可以变出好几个 “子电脑”，里面都登录上 QQ。“子电脑” 和 “子电脑” 之间，是相互隔离的，互不影响。

虚拟机属于虚拟化技术。而 Docker 这样的容器技术，也是虚拟化技术，属于轻量级的虚拟化。

虚拟机虽然可以隔离出很多 “子电脑”，但占用空间更大，启动更慢，虚拟机软件可能还要花钱（例如：VMWare）。

而容器技术恰好没有这些缺点。它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境（类似 “沙箱”）。Docker 可以轻松创建容器和基于容器的应用程序，最初是为 Linux 构建的，现在也可以在 Windows 和 MacOS 上运行。

它启动时间很快，几秒钟就能完成。而且，它对资源的利用率很高（一台主机可以同时运行几千个 Docker 容器）。此外，它占的空间很小，虚拟机一般要几 GB 到几十 GB 的空间，而容器只需要 MB 级甚至 KB 级。

正因为如此，容器技术受到了热烈的欢迎和追捧，发展迅速。大家需要注意，Docker 本身并不是容器，它是创建容器的工具，是应用容器引擎。想要搞懂 Docker，其实看它的两句口号就行。

第一句，是 “Build, Ship and Run”。

第二句口号则是：“Build once，Run anywhere(搭建一次，到处能用)”。

• Build（构建镜像）： 镜像就像是集装箱，包含文件以及运行环境等等资源；
• Ship（运输镜像）：在宿主机和仓库间进行运输，这里仓库就像是超级码头；
• Run（运行镜像）：运行的镜像就是一个容器，容器就是运行程序的地方。

说白了，这个 Docker 镜像，是一个特殊的文件系统。它除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（例如：环境变量）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

综上所述，Docker 的运行过程，也就是去仓库把镜像拉到本地，然后用执行命令把镜像运行起来变成容器，这也就是为什么人们常常将 Docker 称为码头工人或码头装卸工。

负责对 Docker 镜像进行管理的，是 Docker Registry 服务（类似仓库管理员）。当然，不是任何人建的任何镜像都是合法的。万一有人构建的镜像存在问题呢？所以，Docker Registry 服务对镜像的管理是非常严格的。最常使用的 Registry 公开服务，是官方的 Docker Hub，这也是默认的 Registry，并拥有大量的高质量的官方镜像。

4、Docker如何使用

其实大多数人谈论 Docker 时说的是 Docker Engine，这只是一个构建和运行的容器。

在运行容器前需要编写 Docker File，通过 dockerFile 生成镜像，然后才能运行 Docker 容器。

Docker File 定义了运行镜像（image）所需的所有内容，包括操作系统和软件安装位置。一般情况下都不需要从头开始编写 Docker File，在 Docker Hub 中有来自世界各地的工程师编写好的镜像，你可以基于此修改。

📚此外，Docker 容器提供了一种构建企业应用程序和业务流程应用程序的方法，这些应用程序比传统应用程序更容易安装、维护和移动。

⭐Docker 容器支持隔离：Docker 容器使应用程序不仅彼此隔离，而且与底层系统隔离。这不仅使软件栈更干净，而且更容易使容器化应用程序使用系统资源，例如 CPU、GPU、内存、I/O、网络等，它还可以确保数据和代码保持独立。

⭐Docker 容器支持可移植性：Docker 容器在支持容器运行环境的任何机器上运行。应用程序不必绑定到主机操作系统，因此可以保持应用程序环境和底层操作环境的整洁和最小化。
例如，采用容器的 MySQL 将在大多数支持容器的 Linux 系统上运行，应用程序的所有依赖项通常都在同一个容器中提供。基于容器的应用程序可以轻易从 on-prem 系统迁移到云环境中，或从开发人员的笔记本电脑移到服务器上，只要目标系统支持 Docker 以及可能与之一起使用的任何第三方工具，比如 Kubernetes。

⭐通常，Docker 容器镜像必须为特定的平台构建。例如 Windows 容器不能在 Linux 上运行，反之亦然；以前，绕过此限制的一种方法是启动运行所需操作系统实例的虚拟机，并在虚拟机中运行容器。
然而 Docker 团队后来设计了一个更优雅的解决方案，称为 manifest，它允许多个操作系统的镜像并行打包。尽管 manifest 还处于试验阶段，但这暗示了容器可能成为跨平台应用程序解决方案和跨环境应用程序解决方案。

⭐Docker 容器支持可组合性：大多数业务应用程序由几个独立的组件组成，web 服务器、数据库和 cache 缓存。Docker 容器可以将这些部件组合成一个容易更换的功能单元。每个部分由不同的容器提供，可以独立于其他容器进行维护、更新、交换和修改。

🔥 这本质上是应用程序设计的微服务模型。通过将应用程序功能划分为独立的、自包含的服务，微服务模型为过程缓慢的传统开发和单一僵化的应用程序提供了一种解决方案，轻量级和便携式容器使构建和维护基于微服务的应用程序变得更加容易。

5、编排系统的需求催生了k8s

尽管 Docker 为容器化的应用程序提供了开放标准，但随着容器越来越多出现了一系列新问题：

• 如何协调、调度和管理这些容器？
• 如何在升级应用程序时不中断服务？
• 如何监视应用程序的运行状况？
• 如何批量重新启动容器里的程序？

解决这些问题需要容器编排技术，可以将众多机器抽象，对外呈现出一台超大机器。现在业界比较流行的有：k8s、Mesos、Docker Swarm。

在业务发展初期只有几个微服务，这时用 Docker 就足够了，但随着业务规模逐渐扩大，容器越来越多，运维人员的工作越来越复杂，这个时候就需要编排系统解救 opers。

一个成熟的容器编排系统需要具备以下能力：

• 处理大量的容器和用户
• 负载均衡
• 鉴权和安全性
• 管理服务通信
• 多平台部署

其中，K8S，就是基于容器的集群管理平台，它的全称，是 kubernetes。

和 Docker 不同，K8S 的创造者，是众人皆知的行业巨头——Google。

然而，K8S 并不是一件全新的发明。它的前身，是 Google 自己捣鼓了十多年的 Borg 系统。K8S 是 Google 研发的容器协调器，已捐赠给 CNCF，现已开源。

Google 利用在容器管理多年的经验和专业知识推出了 k8s，主要用于自动化部署应用程序容器，可以支持众多容器化工具包括现在非常流行的 Docker。

目前 k8s 是容器编排市场的领导者，开源并公布了一系列标准化方法，主流的公有云平台都宣布支持。

一流的厂商都在抢占标准的制高点，一堆小厂商跟着一起玩，这就叫生态了。

6、k8s架构和组件

k8s 由众多组件组成，组件间通过 API 互相通信，归纳起来主要分为三个部分：

• controller manager
• nodes
• pods

• Controller Manager，即控制器管理器，用于调度程序以及节点状态检测(是k8s的大脑)。
• Nodes，构成了 Kubernetes 集群的集体计算能力，实际部署容器运行的地方。
• Pods，Kubernetes 集群中资源的最小单位。

下图是 Kubernetes 集成 Jenkins 实现 CICD（一图胜千言，需要对其有一个大致的认识）：

而下图则是 GitLab + Jenkins Pipeline + Doker + k8s + Helm 自动化部署：

7、k8s与Docker Swarm江湖恩怨

Docker Swarm 与 k8s 同为容器编排技术。

如果非要拿Docker和k8s进行比较，其实更应该拿Docker Swarm和k8s比较。

Docker Swarm是Docker自驾针对集群化部署管理的解决方案。优点很明显，可以更紧密集成到Docker生态系统中。虽说Swarm和Docker血缘更近，但是由于商业、生态等原因依旧没有k8s流行。

8、Docker与k8s难舍难分

Docker和k8s在业界非常流行，已经是事实上的标准了。

Docker是用于构建、分发、运行()容器的平台和工具。

而k8s实际上是一个使用Docker容器进行编排的系统，主要围绕pods进行工作。Pods是k8s生态中最小的调度单位，可以包含一个或多个容器。

Docker和k8s分别做不通的事情，两者是协同关系。

9、开发实践

（1）不用k8s可以使用docker吗？

可以。对于一些小型公司、业务不太复杂的情况下都是可以直接使用docker的。尽管k8s有很多好处，但是众所周知它非常复杂，简单业务完全可以放弃使用k8s。但是当业务达到一定规模后可能还是要借助k8s才行。

（2）没有Docker可以使用k8s吗？

k8s展示一个容器编排器，没有容器拿什么编排？？

k8s经常与Docker进行搭配使用，但是也可以使用其他容器，如RunC、Containerted等。

（3）Docker Swarm和k8s怎么选？

选k8s。2019 年底 Docker Enterprise 已经出售给 Mirantis，Mirantis 声明要逐步淘汰 Docker Swarm，后续会将 k8s 作为默认编排工具。

转载自  一文带你认识「Docker」与「k8s」 - 掘金

10、k8s弃用docker？

k8s 1.20版本的changelog原文如下：

Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community

原文说的是kubelet是通过一个叫做dockershim的模块实现对docker的支持，然后以后版本会移除这个dockershim模块。

典型的k8s runtime架构(dockershim)

关于dockershim是什么还要从k8s发布之初和docker的关系说起。k8s在发布之初，docker在容器实现方面占据垄断地位。为了迎合主流，kubernetes官网也率先使用docker作为底层容器的实现。

注： shim 顾名思义就是 “垫片”的意思。

2016年12月k8s发布CRI(Container Runtime Interface)，很重要的一个考量就是为了避免后续兼容其他运行时带来的维护工作，所以发布了统一的CRI接口。这样凡是支持CRI的运行时，皆可以直接作为k8s的底层运行时。

所以之前的架构是：

Kubelet 通过CRI接口调用dockershim请求创建容器；

dockershim把创建容器的请求转换成docker daemon的请求往docker创建一个容器；

这时候把容器创建请求请求到使用CRI实现的containerd；

containerd通过OCI调用containerd-shim然后进而使用操作系统底层实现容器的创建 ；

看到这儿，相信大家就知道官网为什么要移除dockershim了！！！

因为这个调用合着需要经过两个划水的dockershim和docker daemon。kubelet直接调用containerd就完事了。于是就有了如下新架构：

        总结来说，k8s启用的其实是dockershim，选择直接对接CRI接口；并且默认支持的是containerd(就是docker自带的组件)，所以完全可以和docker本身做到100%兼容。k8s去除dockershim是自身发展考虑，为的是支持更通用的CRI标准，更高抽象化意味着更好的兼容性。

        顺便说下，即便启用docker也不代表docker就要凉了。docker带给我们的是更新的工作流和开发方式，一种容器化的思维。在我们的日常开发中，docker在临时搭建一些环境时还是可以发挥巨大作用的。