01-Kubernetes 诞生背景

背景

在云原生技术发展的浪潮之中，Kubernetes 伴随着容器技术的发展，成为了目前云时代的操作系统。Kubernetes 作为容器编排领域的事实标准和云原生领域的关键项目，已经是云原生时代工程师最需要理解与实践的核心技术。

但技术的发展从来都不是一蹴而就，Kubernetes 的诞生与完善也有其对应的技术历史背景，了解其诞生与发展的过程，对于更加系统的理解其核心思想、架构设计、实现原理等内容会大有帮助。

如果要了解 Kubernetes 的诞生，就绕不开整个云计算的发展历程。了解了云计算的发展的过程，就会明白，Kubernetes是云计算发展到一定程度的必然产物。

云计算发展历程

云计算发展历程的时间轴如下图所示，从物理机过渡到传统的 IaaS 阶段，进而发展为早期的 PaaS，直至发展到如今的基于 Kubernetes 架构的新兴 PaaS 平台。

用户使用资源的形态也由早期的物理机过渡到虚拟机，再进化到目前更轻量的 Docker 容器。本质上云计算实现的关键突破就在于资源使用方式的改变，其最初解决的核心的问题就是应用的托管即应用的部署与管理问题。

早期物理机时代

云计算之前，开发者如需部署管理服务，需要根据需求，进行配置、管理与运维物理机。整体上维护困难，成本高昂，重复劳动，风险随机。

在那个时代，应用的部署与管理面临着以下诸多问题：

• 硬件、机房等维护成本高。各个团队独立搭建机群、运维机器。

• 应用部署、迁移、修复困难。缺少统一的部署发布平台；面对突发情况，缺少自动化工具，排查解决问题依赖人工，低效且成本巨大。

• 资源利用率低。物理机的平均资源率不到10%，有的甚至在5%左右，造成了资源的巨大浪费。

• 应用隔离性差。多业务混部在一台机器时，会产生干扰。例如：当某一应用资源使用率突然提升，会抢占其他应用的可用资源。

IaaS 平台

Infrastructure as a service (IaaS) 基础设施即服务，用户可以按需去申请基础设施资源（包括：计算、存储、网络）。

IaaS 商业化道路上的一个标志性事件：2006 年 AWS 推出了 EC2（亚马逊弹性云端运算），其基于 Xen 虚拟化技术，用户可以在 web 界面上配置、获取虚拟机资源，部署应用。通过规模化来降低边际成本。

虚拟化技术

IaaS 的底层核心技术是虚拟化技术。虚拟化技术是一种资源关联技术，是将计算机的各种实体资源，如服务器、网络、存储等，进行抽象、整合、管理与再分配的一种技术。最常用的一种方案是基于虚拟机（Hypervisor-based）的虚拟化实现。其通过一个软件层的封装，提供和物理硬件相同的输入输出表现，实现了操作系统和计算机硬件的解耦，将 OS 和计算机从一对一转变为多对多（实际上是一对多）的关系。该软件层称为虚拟机管理器（VMM/Hypervisor），它分为两大类：裸金属架构、宿主机架构。

• 裸金属架构：VMM 直接安装和运行在物理机上；VMM 自带虚拟内核的管理和使用底层的硬件资源。业界的 Xen、VMWare ESX 都是裸金属架构。

• 宿主机架构：物理机上首先会装一个操作系统，VMM 安装和运行在操作系统上；在 VMM 再去装其他虚拟机操作系统，依赖与操作系统对硬件设备的支持与资源的管理。
  这种架构的好处是，VMM 会变的非常简单，因为可以基于操作系统去管理系统资源，VMM 只需要做额外的虚拟化工作。Oracle VirtualBox，VMWare Workstation、KVM都是这种架构，宿主机架构是目前虚拟化技术的主流架构。

下图对比了物理机架构与宿主机虚拟化架构的区别。

虚拟化架构有如下的优势：

• 封装应用技术栈。虚拟化镜像中可以预装一些通用的软件与库，来减少应用对通用软件与库的依赖。
• 提高底层资源的隔离性。硬件层面做了隔离，虚拟机之间互不干扰。
• 动态调整机器、资源配置。虚拟化的配置可以动态升降配，用户可以按自己的需求调整。
• 提高资源利用率。资源使用率从平均不到10%提高到了15%左右。

OpenStack

当物理机转变为虚拟机之后，如何对多台虚拟机的资源进行管理与调度，成为了一个新的问题。

OpenStack 给出了解决方案，它是一个开源的分布式的平台，能够统一管理多个服务器，按用户需求进行分配与调度虚拟机。其本质上是一组分配、管理虚拟机的自动化工具脚本。

目前，OpenStack 已经发展成了 IaaS 的主流解决方案，即：OpenStack as IaaS。目前主流 IaaS 云服务厂商底层基本都是利用 OpenStack 技术。

IaaS 平台一定程度上提升了物理机的资源利用率，由物理机时代的低于10%，提升到了15%。但虚拟机对资源利用率的提升仍存在一定的局限性，其相对笨重，启动慢，自身消耗大（其完整运行了一套操作系统），自身加载就要消耗几百兆的内存资源。此外，虚拟机可以预装一些软件，一定程度简化了应用程序的依赖安装。但应用程序的部署与打包，仍然需要开发人员各自解决，仍未高效的完成应用部署与分发。

PaaS 平台

Platform-as-a-Service (PaaS)平台即服务。PaaS 提供了包括服务器、存储空间和网络等基础结构，但它并未包括中间件、开发工具、数据库管理系统等。PaaS 旨在支持应用程序的完整生命周期：生成、部署、管理和更新，提供应用的托管能力。

在 IaaS 阶段，服务厂商只提供虚拟机，虚拟机之上的软件栈都由用户管理，包括操作系统、持久化层、中间层、用户程序。在 IaaS 层面用户只是减少了关心底层硬件，而 PaaS 层面希望能够进一步解放用户，让用户真正只需关注应用本身。

PaaS 主要功能

目前一个成熟的 PaaS 平台应具备的主要功能 ，如下图所示：

早期 PaaS 平台，更多关注运行时环境与依赖服务，而目前的 PaaS 平台新增大量的支持服务，包括：认证授权、系统日志、应用监控等，以上都是应用开发的常见需求。原则上：共用内容就应该抽象出统一通用的组件，由框架和平台来实现。让用户只关心逻辑或应用本身，避免重复造轮子。

PaaS 早期代表 Cloud Foundry

PaaS 在成熟之前也经历了几个阶段，而 PaaS 早期的代表就不得不提 Cloud Foundry。Cloud Foundry 由 VMWare 开发，是第一款开源 PaaS 平台（2011年）。支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够快速进行应用的部署，无需担心任何基础架构的问题。

它主要功能包括以下：

1. 应用打包、分发部署
2. 以容器的方式运行应用
3. 均衡负载
4. 服务监控、异常重启

Cloud Foundry 的出现，其描绘了 PaaS 平台的初步形态，推动了 PaaS 的发展，具有划时代的意义。

但其最终并未成为 PaaS 主流，是因为其存在一个核心不足：它只对应用和配置进行了打包，而没有打包整体依赖（所谓的整体依赖包括：中间环境、操作系统文件）。所以它的包在跨平台运行时，会出现运行失败的现象。这个问题非常致命。

而且，早期 Cloud Foundry 主要是针对单一 Web 应用的管理，对分布式应用所需的各项能力均未涉及，例如：服务发现、弹性扩缩等。

Docker

Docker 公司的前身是 dotCloud，它是2010年成立，提供 Paas 服务的平台。但当时 Cloud Foundry 做的相对完善和开放，2012 年底 dotClound 濒临倒闭，创始人决定把内部的打包平台开源出去。因此，2013年3月 dotCloud 公司在 github 平台上开源了其内部的容器项目 Docker。Github 开源之后，受到了业界的热烈追捧，从而 Docker 大火。公司后来也改名为 Docker。

Docker 的成功，主要是通过镜像完美解决了开发、测试、生产环境不一致的问题。它的口号是：Build、Shipand Run any App、Anywhere，即一处构建，到处运行。

Docker 的核心技术有三个：NameSpaces做视图隔离、Cgroups做资源限制，UnionFS联合文件系统，统一mount。

通俗理解：NameSpaces、Cgroups通给进程设置属性，实现进程的隔离与限制，UnionFS 给进程构造文件系统。这三项技术均有 linux 内核提供，Docker 本身并没有创造新的技术。

但是Docker创造性的通过镜像整体打包了应用的依赖环境，包括：操作系统文件、中间依赖层、APP。

1. 整体打包之后，镜像变大，又该如何优化？
   Docker 通过镜像分层复用的方式进行了优化。共用只读层，节省存储空间，提高镜像推送、拉取效率，镜像的操作是增量式。

2. 当分层之后，在宿主机上如何合并多个层？
   利用UnionFS实现合并，多个只读层加一个可写层 mount 成一个目录。并且上面的层会覆盖下面的层，当对底层的只读层修改时会采用写时复制策略（copy-on-write）。
   写时复制的含义：当另一个层第一次需要写入该文件时（在构建镜像或运行容器时），该文件会被复制到该读写层并被修改。该机制大大减少了容器的启动时间（启动时新建的可写层只有很少的文件写入），但容器运行后每次第一次修改的文件都需要先将整个文件复制到container layer 中。

如下图所示，Docker 相比于虚拟机操作系统级的资源隔离，实现了进程级资源隔离，极大提升了资源利用率。具备以下特点：

1. 进程级隔离，更轻量
2. 更低消耗系统资源
3. 更快速启动
4. 更快交付与部署

容器编排

当 Docker 解决了应用打包的问题后，PaaS 上应用大规模部署与管理的问题愈发突出。此时，业内明白：容器本身没有“价值”，有价值的是容器编排。

**容器编排(Orchestration)**：对 Docker 及容器进行更高级更灵活的管理，按照用户的意愿和整个系统的规则，完全自动化的处理好容器之间的各种关系（对象之间的关系远重要于对象本身）。

容器技术做为底层基础技术，只能用来创建和启动容器的小工具，最终只能充当平台项目的“幕后英雄”。用户最终部署的还是他们的网站、服务、数据库，甚至是云计算业务。这就需要一个真正的 PaaS 平台，让用户把自己的容器应用部署在此之上。

在以上的历史背景之下，2014年左右，Docker、Mesos、Google 相继发布自己的 PaaS 平台，容器编排之争正式开始。

• Docker 发布了 Swarm 平台，Swarm 擅长跟 Docker 生态无缝集成，Docker 用户可以低成本过渡。其最大亮点是使用 Docker 项目原有的容器管理API来完成集群管理。例如：

  • 单机 Docker 项目: docker run “我的容器”。
  • 集群 Docker 项目：docker run -H “我的Swarm集群API地址” “我的容器”。

• Mesos 平台，擅长大规模集群的调度与管理。它是 Apache 基金会下的一个开源集群管理器，最初是由 Berkeley 分校开发的。它为应用程序提供了跨集群的资源管理和调度API。之后转向支持 PaaS 业务，推出了 Marathon 项目。它是一个高度成熟的 PaaS 项目，旨在让用户便捷管理一个数万级别的物理机集群，可使用 Docker 容器在这个集群里自由部署应用。

• Google 推出的是 Kubernetes 平台，整个系统的前身是 Borg 系统，Kubernetes 平台是 google 在容器化基础设施领域十多年来实践经验的沉淀与升华。

经过近3年的角逐，容器编排之争的胜利者是 Kubernetes。

2017年 9月，Mesos 宣布支持 Kubernetes。
2017年10月，Docker 官方支持 Kubernetes。
2018年 3月，Kubernetes 正式从CNCF毕业，开始一统江湖。（所谓毕业是指这个产品可以直接使用在生产环境）。

对于如今已经成为容器编排领域的事实标准的 Kubernetes，读者一定会有一个疑问：为什么最后是 Kubernetes？ 这个问题就留给大家了。

Reference

https://zhuanlan.zhihu.com/p/572206500