一、容器编排之战

Kubernetes是谷歌严格保密十几年的秘密武器——Borg的一个开源版本，是Docker分布式系统解决方案。2014年由Google公司启动。

Borg
Borg是谷歌内部使用的大规模集群管理系统，基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化

• 容器编排引擎三足鼎立：
  1. Mesos
  2. Docker Swarm+compose
  3. Kubernetes

早在 2015 年 5 月，Kubernetes 在 Google 上的搜索热度就已经超过了 Mesos 和 Docker Swarm，从那儿之后更是一路飙升，将对手甩开了十几条街,容器编排引擎领域的三足鼎立时代结束。

image.png

目前，AWS、Azure、Google、阿里云、腾讯云等主流公有云提供的是基于 Kubernetes 的容器服务；Rancher、CoreOS、IBM、Mirantis、Oracle、Red Hat、VMWare 等无数厂商也在大力研发和推广基于 Kubernetes 的容器 CaaS 或 PaaS 产品。可以说，Kubernetes 是当前容器行业最炙手可热的明星。

Google 的数据中心里运行着超过 20 亿个容器，而且 Google 十年前就开始使用容器技术。
最初，Google 开发了一个叫 Borg 的系统（现在命名为 Omega）来调度如此庞大数量的容器和工作负载。在积累了这么多年的经验后，Google 决定重写这个容器管理系统，并将其贡献到开源社区，让全世界都能受益。这个项目就是 Kubernetes。简单的讲，Kubernetes 是 Google Omega 的开源版本。

跟很多基础设施领域先有工程实践、后有方法论的发展路线不同，Kubernetes 项目的理论基础则要比工程实践走得靠前得多，这当然要归功于 Google 公司在 2015 年 4 月发布的 Borg 论文了。

Borg 系统，一直以来都被誉为 Google 公司内部最强大的"秘密武器"。虽然略显夸张，但这个说法倒不算是吹牛。

因为，相比于 Spanner、BigTable 等相对上层的项目，Borg 要承担的责任，是承载 Google 公司整个基础设施的核心依赖。在 Google 公司已经公开发表的基础设施体系论文中，Borg 项目当仁不让地位居整个基础设施技术栈的最底层。

由于这样的定位，Borg 可以说是 Google 最不可能开源的一个项目。而幸运地是，得益于 Docker 项目和容器技术的风靡，它却终于得以以另一种方式与开源社区见面，这个方式就是 Kubernetes 项目。

所以，相比于"小打小闹"的 Docker 公司、"旧瓶装新酒"的 Mesos 社区，Kubernetes 项目从一开始就比较幸运地站上了一个他人难以企及的高度：在它的成长阶段，这个项目每一个核心特性的提出，几乎都脱胎于 Borg/Omega 系统的设计与经验。更重要的是，这些特性在开源社区落地的过程中，又在整个社区的合力之下得到了极大的改进，修复了很多当年遗留在 Borg 体系中的缺陷和问题。

所以，尽管在发布之初被批评是"曲高和寡"，但是在逐渐觉察到 Docker 技术栈的"稚嫩"和 Mesos 社区的"老迈"之后，这个社区很快就明白了：k8s 项目在 Borg 体系的指导下，体现出了一种独有的"先进性"与"完备性"，而这些特质才是一个基础设施领域开源项目赖以生存的核心价值。

二、为什么是编排

• 一个正在运行的 Linux 容器，可以分成两部分看待：
  1. 容器的静态视图
     一组联合挂载在 /var/lib/docker/aufs/mnt 上的 rootfs，这一部分称为"容器镜像"（Container Image）
  2. 容器的动态视图
     一个由 Namespace+Cgroups 构成的隔离环境，这一部分称为"容器运行时"（Container Runtime）

作为一名开发者，其实并不关心容器运行时的差异。在整个"开发 - 测试 - 发布"的流程中，真正承载着容器信息进行传递的，是容器镜像，而不是容器运行时。
这正是容器技术圈在 Docker 项目成功后不久，就迅速走向了"容器编排"这个"上层建筑"的主要原因：作为一家云服务商或者基础设施提供商，我只要能够将用户提交的 Docker 镜像以容器的方式运行起来，就能成为这个非常热闹的容器生态图上的一个承载点，从而将整个容器技术栈上的价值，沉淀在我的这个节点上。

更重要的是，只要从这个承载点向 Docker 镜像制作者和使用者方向回溯，整条路径上的各个服务节点，比如 CI/CD、监控、安全、网络、存储等等，都有可以发挥和盈利的余地。这个逻辑，正是所有云计算提供商如此热衷于容器技术的重要原因：通过容器镜像，它们可以和潜在用户（即，开发者）直接关联起来。

从一个开发者和单一的容器镜像，到无数开发者和庞大的容器集群，容器技术实现了从"容器"到"容器云"的飞跃，标志着它真正得到了市场和生态的认可。

这样，容器就从一个开发者手里的小工具，一跃成为了云计算领域的绝对主角；而能够定义容器组织和管理规范的"容器编排"技术，则当仁不让地坐上了容器技术领域的"头把交椅"。

• 最具代表性的容器编排工具：
  1. Docker 公司的 Compose+Swarm 组合
  2. Google 与 RedHat 公司共同主导的 Kubernetes 项目

三、理解容器编排

Docker平台以及周边生态系统包含很多工具来管理容器的生命周期。例如，Docker Command Line Interface(CLI)满足在单个主机上管理容器的需求，但是面对部署在多个主机上的容器时就无所适从了。为了超越单个容器管理，我们必须转向编排工具。容器编排工具将生命周期管理能力扩展到部署在大量机器集群上部署的复杂的、多容器工作负载。

容器编排工具为开发人员和基础设施团队提供了一个抽象层来处理大规模的容器化部署。容器编排工具提供的特征在众多提供者之间有所不同，然而常见的公共特征包含准备、发现、资源管理、监视和部署。

由于微服务将应用程序分解为不同的微应用程序，许多开发人员会请求更多的服务器节点进行部署。为了正确地管理微服务，开发者倾向于在每个VM中部署一个微服务，这进一步降低了资源利用率。在许多情况下，这会导致CPU和内存的过度分配。

在许多部署中，微服务的高可用性需求迫使工程师添加越来越多的服务实例来进行冗余。实际上，尽管它提供了所需的高可用性，但这将导致出现一些未充分利用的服务器实例。一般而言，与单一应用程序部署相比，微服务部署需要更多的基础设施。由于基础设施成本的增加，许多组织未能看到微服务的价值。

• 为了解决上面提到的问题，我们需要一个工具能做到以下几点：

  1. 活动自动化。例如有效地向基础设施分配容器，这一行为对开发人员和管理员都是透明的。
  2. 为开发人员提供一个抽象层，以便他们可以在不知道使用哪个机器托管他们的应用程序的情况下，将应用程序部署到数据中心。
  3. 对部署设置规则或约束。
  4. 提供更高的敏捷性，为开发人员和管理员提供最小的管理开销和最少的人为交互。
  5. 通过最大限度地利用可用资源，有效地构建、部署和管理应用程序。
  6. 典型的容器编排工具有助于虚拟化一组机器并将它们作为单个集群管理。容器编排工具也有助于将机器上的工作负载或容器移动到消费者透明的位置。很多工具目前既支持基于DOCKER的容器，也支持非容器化二进制文件部署，例如独立的Spring Boot应用程序。这些容器编排工具的基本功能是从应用程序中抽象出实际的服务器实例。

• 容器编排工具的一些关键能力概括如下：

  1. 集群管理：将虚拟机和物理机器的集群管理为一台大型机器。这些机器在资源能力方面可能有些差异，但大体上都是以Linux作为操作系统的机器。这些虚拟集群可以建立在云上、本地或两者的混合。
  2. 部署：能处理有大量机器的应用程序和容器的自动部署。支持多个版本的应用程序容器，并且还支持跨越大量集群机器的滚动升级。这些工具还能够处理故障回滚。
     可伸缩性：支持应用实例的自动和手动伸缩，以性能优化为主要目标。
  3. 健康：它管理集群、节点和应用程序的健康。可以从集群中移除异常的机器和应用程序实例。
     基础结构抽象化：开发人员不必担心机器、容量等问题。完全是容器编排工具来决定如何调度和运行应用程序。这些工具也抽象化机器的细节、能力、使用和位置。对于应用程序所有者来说，它们相当于一个容量几乎无限的大型机器。
  4. 资源优化：这些工具以有效的方式在一组可用机器上分配容器工作负载，从而降低成本，通过从简单的到复杂的算法可有效地提高利用率。
  5. 资源分配：基于应用程序开发人员设置的资源可用性和约束来分配服务器。资源分配将基于约束、规则、端口要求、应用依赖性、健康等等。
     服务可用性：确保服务在集群中正常运行。在机器故障的情况下，容器编排会自动通过在集群中的其他机器上重新启动这些服务来处理故障。
  6. 敏捷性：敏捷性工具能够快速分配工作负载到可用资源，或者在资源需求发生变化时跨机器移动工作量。此外，可以根据业务临界性、业务优先级等来设置约束重新调整资源。
  7. 隔离：一些工具提供了资源隔离。因此，即使应用程序不是容器化的，也可以实现资源隔离。