一文读懂Kubernetes 与 Docker

作者 | 乔冰诚 翻译

来源 | 新钛云服（ID：newtyun）

转载请联系授权（微信ID：zlm935177782）

两个最具影响力的云计算开源项目之间的异同。
Kubernetes vs. Docker 是一个在云计算行业被多次提及的话题。无论你来自非技术背景，需要快速介绍，还是需要做商业决策，我都希望以下几点能一劳永逸地澄清这件事。
我们需要超越围绕 Kubernetes 和 Docker 的炒作。这些词的意思很重要，在它们之上运行您的业务之前要掌握。
Kubernetes 和 Docker 之间的共生关系
问题“Kubernetes vs. Docker？” 本身是相当荒谬的，就像将苹果比作橘子一样。一个不是另一个的替代品。恰恰相反，Kubernetes 可以在没有 Docker 的情况下运行，而 Docker 可以在没有 Kubernetes 的情况下运行。但是 Kubernetes 可以（并且确实）从 Docker 中受益匪浅，反之亦然。
Docker 是一个独立的应用程序，可以安装在任何计算机上以运行容器化应用程序。容器化是一种在操作系统上运行应用程序的方法，以便应用程序与系统的其余部分隔离。尽管可能有其他容器在同一系统上运行，但您为应用程序创建了一种错觉，认为它正在获得自己的操作系统实例。Docker 使我们能够在单个操作系统上运行、创建和管理容器。
Kubernetes 将其增加到 11。如果您在一堆主机（不同的操作系统）上安装了 Docker，则可以利用 Kubernetes。这些节点或 Docker 主机可以是裸机服务器或虚拟机。然后，Kubernetes 可以让您从单个命令行或仪表板跨所有这些节点自动执行容器配置、网络、负载平衡、安全性和扩展。由单个 Kubernetes 实例管理的节点集合称为 Kubernetes 集群。
现在，为什么首先需要有多个节点？其背后的两个主要动机是：

1.      使基础设施更加健壮——即使某些节点离线，您的应用程序也将在线，即高可用性。

2.      使您的应用程序更具可扩展性——如果工作负载增加，只需生成更多容器和/或向 Kubernetes 集群添加更多节点。

Kubernetes 和 Docker 之间的差异
原则上，Kubernetes可以使用任何容器化技术。Kubernetes 可以集成的两个最流行的选项是 rkt 和 Docker。然而，Docker赢得了最大的细分市场，这导致在完善 Docker 和Kubernetes 之间的集成方面付出了很多努力，比任何其他容器化技术都多。
同样，Docker背后的公司 Docker Inc. 也提供了自己的容器编排引擎，名为 Docker Swarm。但即使是他们也意识到 Kubernetes 已经上升到甚至 Docker for Desktop（MacOS 和 Windows）都带有自己的 Kubernetes 发行版。
如果有人对在基于 Docker 的产品中采用 Kubernetes 感到紧张，那么最后一点将消除所有疑虑。这两个项目都全心全意地相互拥抱，并从这种共生关系中受益匪浅。
Kubernetes 和 Docker 之间的相似之处
这些项目不仅仅是技术，它们是一个人的社区，尽管存在差异，但由业内一些最聪明的人组成。当志同道合的人合作时，他们会交换聪明的想法并相互学习最佳实践。
这些是Kubernetes 和 Docker 共享的一些想法：

1.      他们对基于微服务的架构的热爱（稍后会详细介绍）。
2.      他们对开源社区的热爱。两者都是主要的开源项目。
3.      它们主要是用 Go 编写的，因此可以将它们作为小型轻量级二进制文件发送。
4.      他们使用人类可读的 YAML 文件来指定应用程序堆栈及其部署。

从理论上讲，您可以在不了解另一个的情况下了解其中一个。但请记住，在实践中，如果您从 Docker 在单机上运行的简单案例开始，然后逐渐了解 Kubernetes 如何发挥作用，您将受益更多。
什么是 Docker？
有两种看待 Docker 的方式。第一种方法涉及将 Docker 容器视为真正的轻量级虚拟机。第二种方法是将 Docker 视为软件打包和交付平台。后一种方法被证明对人类开发人员更有帮助，并导致该技术得到广泛采用
Docker 容器概述：
传统上，云服务提供商使用虚拟机将正在运行的应用程序相互隔离。管理程序或主机操作系统为许多客户操作系统提供虚拟 CPU、内存和其他资源。每个来宾操作系统都像在实际物理硬件上运行一样工作，理想情况下，它不知道在同一物理服务器上运行的其他来宾操作系统。VMware 是最早普及这一概念的公司之一。

但是，这种虚拟化存在几个问题。首先，资源的供应需要时间。每个虚拟磁盘映像都很大很笨重，准备使用 VM 可能需要长达一分钟的时间！ 其次，也是一个更重要的问题，是系统资源的低效利用。操作系统内核是控制狂，想要管理他们认为可用的一切。

因此，当客户操作系统认为它有 2GB 内存可用时，它会控制该内存，即使在该操作系统上运行的应用程序只使用其中的一半。 另一方面，当我们运行容器化应用程序时，我们虚拟化操作系统（您的标准库、包等）本身，而不是硬件。

现在，您不再为 VM 提供虚拟硬件，而是为应用程序提供虚拟操作系统。如果需要，您可以运行多个应用程序并对其资源利用率施加限制，并且每个应用程序都将在运行时忽略与其一起运行的数百个其他容器。

Docker——作为开发者的工具：
开发人员面临的问题之一是运行应用程序的生产服务器与开发应用程序的他们自己的开发机器（通常是笔记本电脑和工作站）之间的差异。假设您在桌面上运行 Windows 10，但您想为 Ubuntu 18.04 编写应用程序。也许您正在使用 Python v3.6 来编写您的应用程序，而 Ubuntu 服务器仍在运行 3.4。
 有太多的变量需要考虑，所以我们使用 Docker 来抽象出这种复杂性。Docker 可以安装在任何操作系统上，甚至 Windows 和 Mac OS X 都得到很好的支持。因此，您可以将代码打包到 Docker 映像中，使用 Docker 在本地运行和测试它，以确保从该 Docker 映像创建的容器在生产中的行为方式相同。
注意：所有依赖项，如编程语言版本、标准库等，都包含在该映像中。
 这种将Docker 镜像视为软件包的方式导致了以下流行语录：

包管理器Apt 仍然在底层使用 tar，但用户永远不必担心它。同样，在使用 Docker 时，我们永远不必担心包管理器，尽管它仍然存在。即使在 Node.js 技术之上进行开发时，开发人员也更喜欢在 Node 的官方 Docker 镜像之上构建他们的 Docker 镜像。
所以，这是对 Docker 是什么以及为什么即使他们没有参与 DevOps 也可能想了解它的一个简要概述。现在让我们继续 Kubernetes。
什么是 Kubernetes？
Kubernetes 采用了如上所述的容器化技术，并将其变成了 11 个。它允许我们跨多个计算节点（这些可以是虚拟机或裸机服务器）运行容器。一旦 Kubernetes 控制了一组节点，容器就可以在任何给定时间根据我们的需要启动或拆除。
如果您访问他们的官方网站，Kubernetes 会非常清楚地说明其目的：

到目前为止，我们仅将Kubernetes的简要概述表示为自动化一堆容器创建。应用程序需要有存储空间，并且需要管理一些 DNS 记录。您需要确保参与的计算节点彼此安全连接等等。拥有一组不同的节点而不是单个主机会带来一系列完全不同的问题。
Kubernetes 架构的简要概述将帮助我们阐明它如何设法实现所有这些以及更多。
Kubernetes 架构 — 简要概述：
关于 Kubernetes 集群，您需要了解两个基本概念。第一个是节点。这是 Kubernetes 管理的 VM 和/或裸机服务器的通用术语。第二个术语是 pod，它是 Kubernetes 中的基本部署单元。Pod 是需要共存的相关 Docker 容器的集合。例如，您的 Web 服务器可能需要与 Redis 缓存服务器一起部署，以便您可以将它们两者封装到一个 Pod 中。Kubernetes 并排部署它们。如果这对您来说更简单，您可以完全想象一个由单个容器组成的 pod，那就没问题了。
 回到节点，有两种类型的节点。一个是主节点，其中安装了 Kubernetes 的核心，它控制着应用程序实际运行的各个工作节点之间的 pod 调度。主节点的工作是确保维持集群的期望状态。

下面是对 Kubernetes 图表的简要总结，如上所示。

在 Kubernetes Master 上，我们有：
1.      kube-controller-manager：负责考虑集群的当前状态（例如，X 个正在运行的 Pod）并做出决定以实现所需的状态（例如，有 Y 个活动的 Pod）。它在 kube-apiserver 上侦听有关集群状态的信息
2.      kube-apiserver：这个 API 服务器公开了Kubernetes 的齿轮和杠杆。它由 WebUI 仪表板和命令行实用程序（如 kubeclt）使用。这些实用程序反过来被人类操作员用来与 Kubernetes 集群交互。
3.      kube-scheduler：这决定了如何根据资源的可用性、运营商设置的策略等在集群中调度事件和作业。它也侦听kube-apiserver 以获取有关集群状态的信息。
4.      etcd：这是 Kubernetes 主节点的“存储堆栈”。它使用键值对，用于保存策略、定义、秘密、系统状态等

我们可以有多个主节点，这样即使一个主节点发生故障，Kubernetes 也能存活下来。在工作节点上，我们有：

1.      kubelet：这将有关节点健康状况的信息中继回主节点，并执行主节点给它的指令
2.      kube-proxy：此网络代理允许您的应用程序的各种微服务在集群内相互通信，并且如果您愿意，还可以将您的应用程序公开给世界其他地方。原则上，每个 Pod 都可以通过此代理与其他每个 Pod 通信。
3.      Docker：这是拼图的最后一块。每个节点都有一个 Docker 引擎来管理容器。

当然，还有更多 Kubernetes，我鼓励您探索所有这些。
Docker 和 Kubernetes 的全行业采用
到目前为止，我们讨论的许多概念在纸面上听起来不错，但它们是否经济？它们真的会帮助您的业务增长、减少停机时间并节省人力和计算能力方面的资源吗？
生产环境中的 Docker：
在采用 Docker 时，答案很简单。特别是如果你为你的软件采用基于微服务的架构，你绝对应该为每个微服务使用 Docker 容器。

这项技术相当成熟，几乎没有人可以反对它。请记住，仅仅容器化您的代码不会让您的代码变得更好。如果您真的想使用容器化平台，请尝试避免单体设计并使用微服务。
生产中的 Kubernetes：
不能因为在生产中对 Kubernetes 的咆哮而受到指责，在我个人看来，其背后的原因有两个方面。
 首先，大多数组织在对分布式系统的基本概念没有任何了解的情况下盲目跳槽。他们尝试建立自己的Kubernetes 集群并使用它来托管简单的网站或小型可扩展应用程序。
 其次，Kubernetes 正在快速发展，其他组织正在为其添加自己的特殊调味料，例如服务网格、网络插件等。其中大部分是开源的，因此对运营商很有吸引力。但是，在生产中运行它们并不是我推荐的。跟上它们需要不断维护集群并花费更多的人力时间。
但是，组织可以使用云托管的 Kubernetes 平台来运行其应用程序。AWS、Azure、Joyent 或 GCE 等公司提供的数据中心的全球可用性实际上可以帮助您充分利用 Kubernetes的分布式特性。而且，当然，您不必担心维护集群。
 这是中小型组织经常忽略的东西。如果您想在节点故障中幸存下来并获得高可扩展性，您不应该在单个 1-U 机架甚至单个数据中心上运行 Kubernetes。

那么，Kubernetes 在生产中吗？是的，但对于大多数人来说，我会推荐云托管解决方案。
容器和云计算的新时代
Docker 并不是作为操作系统级别的虚拟化软件进行宣传的，而是作为一种软件打包和交付机制进行营销的。Docker容器引起其竞争对手关注的唯一原因是这种软件交付方法。
 多亏了 Dockerfiles，自动化构建变得容易多了。由于 docker-compose，复杂的多容器部署现在已经标准化。通过提供完整的CI/CD 解决方案，包括构建和测试 Docker 镜像以及管理公共或私有 Docker 注册表，软件工程师将容器发挥到了逻辑极限。

Kubernetes 将容器从被困在一台计算机上解放出来，使云成为这项技术的一个更具吸引力的地方。慢慢地，但可以肯定的是，容器化将成为每个依赖于云的服务的规范，因此，尽早而不是以后采用这项技术非常重要。这样做可以最大限度地减少迁移成本和相关风险。
分布式操作系统案例
既然我已经对公司在没有完全理解的情况下采用 Kubernetes 大发雷霆，请允许我说明为什么你应该采用 Kubernetes。云计算已经发展成为这个竞争激烈的市场，谷歌、微软、亚马逊和许多其他玩家相互竞争。
这大大降低了在云中部署软件的成本。Kubernetes 的最大优点是它在很大程度上是开源的，因此您可以了解正在发生的事情，而不会被细节所困扰。
 这是 Azure 宣传其Kubernetes 服务： 

仅仅知道它在表面上是如何工作的，就可以让您对在分布式系统中运行的软件进行推理。但是您不必担心实际管理底层集群！
 亚马逊、谷歌和 DigitalOcean 正在提供类似的解决方案。即使是小型企业和个人开发人员现在也可以在整个地球上扩展他们的应用程序。稍微了解它是如何实现的并没有什么坏处，所以你至少应该对 Kubernetes 和 Docker 有一定的了解。
 每次你想，“Kubernetes vs. Docker？” 反对者会回应说 Docker 很酷，但 Kubernetes 有点极端。但是整个计算机科学都是关于极端自动化的，Kubernetes将容器化模型带到了它的逻辑极端！
更细微的差异——网络
许多 Kubernetes 与Docker 的争论都源于基础知识，例如存储堆栈和网络的实现。Docker 和 Kubernetes 都喜欢以不同的方式做事。
 容器需要的不仅仅是 CPU 和一些内存才能发挥作用。在 Kubernetes 和 Docker 主机等平台上运行应用程序之间存在许多细微差别。这些差异太多了，无法在此简明扼要地提及，但总是引起我注意的是事物的网络方面。
 Kubernetes 指定每个 pod 应该能够在给定的命名空间中与集群中的每个其他 pod 自由通信。而 Docker 有一个创建虚拟网络拓扑的概念，您必须指定您希望容器连接到哪些网络。像这样的区别确实会让尝试试水的人望而却步，但是当您考虑 Kubernetes 与 Docker 的根本区别时，它们至关重要： 

对于这种困境，确实别无选择，您只需要在学习曲线上保持耐心即可。渐渐地，更大的画面对你的眼睛来说会变得更清晰。

Docker 与 Kubernetes 的采用心态
使用 Docker，好处是相当明显的。如果您在 Docker 容器上发布您的应用程序，那么它也可以在任何 Linux 发行版上运行。即使基于 Illumos 的操作系统（根本不是 Linux）也支持 Docker，并且可以运行 Docker 容器。
 您的应用程序实际上可以分解为多个微服务，这样每个微服务都可以打包为一个 Docker 容器。通过定义明确的 API，可以轻松地向现有功能添加新功能。例如，如果您需要分析，只需启动一个可以与数据库通信的 Hadoop 容器。

同样，当谈到 Kubernetes 时，用户和云服务提供商实际上都可以通过采用它而大大受益。由于它基于容器化，与传统虚拟机不同，云服务提供商可以有效地利用其资源获得高密度的容器。这使他们能够显著降低价格。
 另一方面，用户可以在全球部署他们的应用程序，减少延迟并改善用户体验。
 这种转变的唯一例外是桌面应用程序开发人员。由于大多数桌面应用程序可能会使用云进行更新和/或备份，但它们主要设计为在单台机器上运行。
结论
容器是惊人的！它们使我们能够以全新的数字化方式思考服务和系统。Docker 和 Kubernetes 都将继续存在。他们不断地改变以在未来将自己转变为更好的东西。让您的公司参与到技术时代并实施您的基础设施最需要的容器。

为以容器为中心的平台设计更新的软件不仅会使您的应用程序更具可扩展性，而且更能适应未来的发展。坚持使用旧的 VM 可能暂时有效，但几年后，您最终将不得不承担将所有内容迁移到容器中的沉重成本，或者完全放弃您的项目。希望现在如果有人提出“Kubernetes vs Docker”的话题，你不会被行话冲昏头脑。