微服务部署 Docker 和 Kubernetes 译

Docker

几年前，Docker 以优雅的解决方案来实现不变交付（immutable delivery）。Docker 允许我们将应用程序与它需要的所有依赖包(os、jvm、其他应用程序依赖项等)打包，以轻量级、分层、镜像格式进行打包。使用这些镜像运行实例，这些实例运行在 linux 容器内的应用程序，这些容器具有独立 cpu、内存、网络和磁盘使用。从某种意义上讲，这些容器是应用程序虚拟化或过程虚拟化的形式。他们允许一个进程执行，认为它是运行的唯一方法(例如，ps，您只看到您的应用程序在那里)，并且它完全访问cpu、内存、磁盘、网络和其他资源，但现实中它没有，它只能使用它分配的资源。例如，我可以启动一个Docker容器分配cpu，内存段，限制网络io的使用程度。从 linux 容器外部，在主机上，应用程序看起来就像另一个过程。没有虚拟化设备驱动程序、操作系统或网络栈以及特殊的虚拟机监控程序。这只是个过程。这也意味着我们可以获得更多的应用程序，运行在一个单一的硬件上，以提高密度，而无需额外操作系统和其他部分 vm 的开销，这将需要实现类似的隔离质量。

发生的事情也不是革命性的，已构建到linux内核中(并且有一段时间)的名为cgroups、名称空间和chroot 的特性用于创建应用程序虚拟化的外观。linux容器已经运行了10年多了，而且在solaris和freebsd中，流程虚拟化甚至在此之前也存在。传统上，使用这些底层 linux 原语，甚至像 LXC 这样的高级抽象，充其量也是复杂的。Docker来了，并简化了 api 和用户体验围绕 linux 容器。Docker带来了一个单一客户端cli，它可以轻松地根据基于在的镜像格式来创建这些 linux 容器，现在已经向开放容器倡议(Oci)中的更大社区打开了这个格式。这种易用性和镜像格式正在改变我们打包和交付软件的方式。

一旦你有了一个镜像，那么就会把许多 linux容器的大量圈圈变得微不足道。这些层是建立在基础镜像(例如rhel、debian或其他linux操作系统)和应用程序文件之间的增量。分发新应用程序只会将新层分发到现有基础层之上。这使得非图像比绕着膨胀的云机器图像更容易。此外，如果在基镜像中找到了漏洞(例如shell冲击、Heartbleed等)，则可以重建基镜像，而不必尝试修补每个vm。这样可以轻松地运行容器：然后它们可以从开发人员的桌面移动到dev、qa或生产，而不必手动希望所有正确的依赖项都位于正确的位置(此应用程序使用jvm 1.6、1.7、1.8？)。如果需要使用更改(新应用程序)重新部署或修复基镜像，那么就只需更改需要更改的图像中的层。

Kubernetes

谷歌以规模运行linux容器而闻名。事实上，在google运行的“一切”都运行在linux容器中，并且由他们的 Borg 集群管理平台管理。谷歌前工程师 Joe·Beda 表示，该公司每周启动二十亿次以上的容易行为。谷歌甚至可以利用它创建底层 linux 技术，从而使容器成为可能。2006，他们开始着手研究“process containers”，最终变成了cgroups，并被合并到 linux 内核代码库中，并在2008发布。随着其规模和规模的运行容器规模，这并不奇怪，谷歌已经对围绕容器构建的平台产生了这样的影响。例如，一些流行的集装箱管理项目在 Kubernetes 之前受到了谷歌的影响。

最初的 CloudFoundry 创建者(德里克·科里森和瓦迪姆·斯皮瓦克)曾在谷歌工作，并花了几年时间使用谷歌的 Borg 集群管理解决方案。
ApacheMesos是为一篇博士论文而创建的，它的创建者(本·辛德曼)曾在谷歌实习，并与谷歌工程师就容器集群、调度和管理问题进行了多次交谈。
Kubernetes是一个开源的容器集群管理平台和社区，最初是由在Google构建Borg的工程师创建的。

早在2013年，当 Docker 撼动了科技行业时，谷歌就决定，是时候开放下一代继任者博格(Borg)的开源软件了，他们将其命名为 Kubernetes 。如今，Kubernetes是一个庞大的、开放的、快速发展的社区，Google、RedHat、CoreOS和许多其他人(包括许多独立的个人)都做出了贡献。Kubernetes为在Linux容器内大规模运行微服务集群带来了很多功能。Google已经将十多年的经验打包成Kubernetes，因此能够利用这些知识和功能来部署我们自己的微服务是改变游戏规则的。网络规模的公司已经这样做多年了，他们中的许多公司(Netflix、亚马逊等)不得不手工制作许多库伯尼特现在已经好的原型机。 Kubernetes有几个简单的原语，在我们深入研究示例之前，您应该理解它们。在本章中，我们将向您介绍这些概念；在接下来的一章中，我们将使用它们来管理一个微服务集群。

Pods

pod 是由一个或多个 Docker 容器组成的一组(就像一群鲸鱼？)。然而，一个典型的 pod 部署通常是一对一的带有一个 Docker 容器.。如果您有SideCar、ADVINE或适配器部署，这些部署必须始终与应用程序位于同一位置，那么将它们分组的方法是使用 Pod。此抽象也是保证容器关联的一种方法(即，Docker容器A将始终部署在同一主机上的Docker容器B旁边)。

Kubernetes 负责组织、安排和管理 Pod。当我们提到运行在 Kubernetes 内部的应用程序时，它是在一个 Pod 内的Docker容器内运行的。一个 Pod 有它自己的 IP 地址，并且 Pod 内的所有容器都共享这个IP(这不同于普通的 Docker ，每个容器都有一个IP地址)。当 volumes 被安装到 Pod 时，它们也在运行在Pod 中的单个容器之间共享。

关于 Pod 还有最后一件事要知道：它们是可替换的。这意味着它们可以在任何时候消失(要么是因为服务崩溃，要么是集群杀死了它)。他们不像一个虚拟机，你关心和培育。Pod 在任何时候都可以被摧毁。这符合我们在微服务世界中的预期，即事情会失败(并且会发生)，因此强烈鼓励我们在编写微服务时考虑到这一前提。这是一个重要的区别，因为我们将在下面几节中讨论其他一些概念。

Labels

标签是简单的键/值对，我们可以将其分配给释放=稳定或层=后端之类的 Pod。Pod(和其他资源，但我们将重点放在 Pod )可以有多个标签，分组和分类在松散耦合的方式，这变得相当明显，尤其当你使用Kubernetes。这并不奇怪，谷歌已经确定了这样简单的结构，我们可以建立强大的集群规模。在我们标记了 Pod 之后，我们可以使用标签选择器来找出哪些 Pod 属于哪一组。例如，如果我们有一些豆荚标签层=后端和其他标签层=前端，使用标签选择器表达式的层！=前端。我们可以选择所有没有标记为“前端”的Pod。标签选择器用于下面两个概念：复制控制器和服务。

Replication Controllers

当谈到在规模上运行微服务时，我们可能会讨论任何给定微服务的多个实例。Kubernetes有一个名为ReplyingController的概念，即给定的一组微服务的副本数进行控制。例如，假设我们想要管理标记为tier=后端和Release=稳定的 Pod 的数量。我们可以使用适当的标签选择器创建一个复制控制器，然后能够用ReplicationController上的副本值控制集群中的那些 Pod 的数量。如果我们将副本计数设置为10，那么 Kubernetes 将协调它的当前状态，以反映为给定的 ReplyingController 运行的10个 Pod。如果现在只有五个人在跑，Kubernetes 就会再运行五个。如果有20个运行，Kubernetes将杀死10(其中10杀死是不确定的，就你的应用程序而言)。Kubernetes将做它所需要的任何事情来收敛到所需的10个副本的状态。您可以想象使用ReplicationController非常容易地控制集群的大小。我们将在下一章中看到Rep许可控制器的例子。

Services

我们应该理解的最后一个 Kubernetes 的概念是Kubernetes 服务。ReplicationController可以控制我们所拥有的服务的代表的数量。我们也看到 Pod 可以被杀死(或者他们自己坠毁，或被杀，可能是作为一个恢复控制器的规模缩小事件的一部分)。因此，当我们试图与一组 Pod 通信时，我们不应该依赖它们的直接IP地址(每个 Pod 都有自己的IP地址)，因为 Pod 可以来来去去。我们需要的是一种方法来分组 Pod，以发现他们在哪里，如何与他们沟通，并可能对他们负载平衡。这正是 Kubernetes 服务机构的职责所在。它允许我们使用标签选择器对我们的 Pod 进行分组，并用单个虚拟(集群)IP对它们进行抽象，然后我们可以用它来发现它们并与它们交互。我们将在下一章中展示具体的例子。

有了这些简单的概念、pods、标签、ReplicationControllers和服务，我们就可以像 Google 已经学会的(或者不学会的)管理和扩展我们的微服务。为复杂的问题找出简单的解决方案需要很多年和许多失败，因此我们强烈鼓励您学习这些概念，并体验使用Kubernetes管理容器为您的微服务带来的力量。

下章我们看看怎么使用！

原文：