🌟 前言

Docker 本身非常适合用于管理单个容器，但真正的生产环境还会涉及多个容器的封装和服务之间的协同处理。

这些容器必须跨多个服务器主机进行部署与连接，单一的管理方式满足不了业务需求。

Kubernetes 是一个可以实现跨主机管理容器化应用程序的系统，是容器化应用程序和服务生命周期管理平台，它的出现不仅解决了多容器之间数据传输与沟通的瓶颈，而且还促进了容器技术的发展。

本篇文章将详细介绍 Kubernetes 的发展与基本的体系结构。

1. 容器编排初识

🍑 企业架构的演变

企业中的系统架构是实现系统正常运行和服务高可用、高并发的基础。

随着时代与科技的发展，系统架构经过三个阶段的演变，实现了从早期单一服务器部署到现在的容器部署方式的改变。

🍇 传统时代

早期，企业在物理服务器上运行应用程序，无法为服务器中的应用程序定义资源边界，导致系统资源分配不均匀。

例如，一台物理服务器上运行着多个应用程序，可能存在一个应用程序占用大部分资源的情况，其它应用程序的可用资源因此减少，造成程序运行表现不佳。

当然也可以在多台物理服务器上运行不同的应用程序，但这样资源并未得到充分利用，也增加了企业维护物理服务器的成本。

🍇 虚拟化时代

虚拟化技术可以在物理服务器上虚拟出硬件资源，以便在服务器的 CPU 上运行多个虚拟机（Virtual Machine，VM）。

每个 VM 不仅可以在虚拟化硬件之上运行包括操作系统在内的所有组件，而且相互之间可以保持系统和资源的隔离，从而在一定程度上提高了系统的安全性。

虚拟化有利于更好地利用物理服务器中的资源，实现更好的可扩展性，从而降低硬件成本。

🍇 容器化时代

容器化技术类似于虚拟化技术，不同的是容器化技术是操作系统级的虚拟，而不是硬件级的虚拟。

每个容器都具有自己的文件系统、CPU、内存、进程空间等，并且它们使用的计算资源是可以被限制的。

应用服务运行在容器中，各容器可以共享操作系统（Operating System，OS）。

因此，容器化技术具有轻质、宽松隔离的特点。因为容器与底层基础架构和主机文件系统隔离，所以跨云和操作系统的快速分发得以实现。

企业中系统架构的演变 如图所示👇

🍑 常见的容器编排工具

容器的出现和普及为开发者提供了良好的平台和媒介，使开发和运维工作变得更加简单与高效。

随着企业业务和需求的增长，在大规模使用容器技术后，如何对这些运行的容器进行管理成为首要问题。

在这种情况下，容器编排工具应运而生，最具代表性的有以下三种。

🍇 Apache 公司 Mesos

Mesos 是 Apache 旗下的开源分布式资源管理框架，由美国加州大学伯克利分校的 AMPLab（Algorithms Machine and People Lab，算法、计算机和人实验室 ）开发。

Mesos 早期通过了万台节点验证，2014 年之后又被广泛使用在 eBay 、Twitter 等大型互联网公司的生产环境中。

🍇 Docker 公司三剑客

容器诞生后，Docker 公司就意识到单一容器体系的弊端，为了能够有效地解决用户的需求和集群中的瓶颈，Docker 公司相继推出 Machine、Compose、Swarm 项目。

Macheine 项目由 Go 语言编写，可以实现 Docker 运行环境的安装与管理。实现批量在指定节点或平台上安装并启动 Docker 服务。

Compose 项目由 python 语言编写，可以实现基于 Docker 容器多应用服务的快速编排，其前身是开源项目 Fig。

Compose 项目使用户可以通过单独的 YAML 文件批量创建自定义的容器，并通过 API（Application Programming Interface，应用程序接口）对集群中 Docker 服务进行管理。

Swarm 项目基于 Go 语言编写，支持原生态的 Docker API 和 Docker 网络插件，很容易实现跨主机集群部署。

🍇 Google 公司 Kubernetes

Kubernetes（来自希腊语，意为“舵手”，因为单词 k 与 s 之间有 8 个字母，所以业内人士喜欢称其为 K8S）基于 Go 语言开发，是 Google 公司发起并维护的开源容器集群管理系统，底层基于 Docker、rkt 等容器技术，其前身是 Google 公司开发的 Borg 系统。

Borg 系统在 Google 内部已经应用了十几年，曾管理超过 20 亿个容器。

经过多年的经验积累，Google 公司将 Borg 系统完善后贡献给了开源社区，并将其重新命名为 Kubernetes。

Kubernetes 系统支持用户通过模板定义服务配置，用户提交配置信息后，系统会自动完成对应用容器的创建、部署、发布、伸缩、更新等操作。

系统发布以来吸引了 Red Hat、CentOS 等知名互联网公司与容器爱好者的关注，是目前容器集群管理系统中优秀的开源项目之一。

🍑 Kubernetes 的设计理念

Kubernetes 的设计理念大多数用户，希望 Kubernetes 项目带来的体验是确定的：有应用的容器镜像，请在一个给定的集群上把这个应用运行起来，此外，用户还希望 Kubernetes 具有提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维的能力。

这些其实就是经典 PaaS 项目的能力，用户使用 Docker 公司的 Compose+Swarm 项目，完全可以很方便地自己开发出这些功能。

而如果 Kubernetes 项目只停留在拉取用户镜像、运行容器和提供常见的运维功能，就很难和 "原生态" 的 Docker Swarm 项目竞争，与经典的 PaaS 项目相比也难有优势可言。

🍇 Kubernetes 项目着重解决的问题

运行在大规模集群中的各种任务之间存在着千丝万缕的关系。如何处理这些关系，是作业编排和管理系统的难点。

这种关系在各种技术场景中随处可见，比如，Web 应用与数据库之间的访问关系，负载均衡器和后端服务之间的代理关系，门户应用与授权组件之间的调用关系。

同属于一个服务单位的不同功能之间，也存在这样的关系，比如，Web 应用与日志搜集组件之间的文件交换关系。

在容器普及前，传统虚拟化环境对这种关系的处理方法都是 "粗粒度" 的。很多并不相关的应用被部署在同一台虚拟机中，也许是因为这些应用之间偶尔会互相发起几个 HTTP 请求。

更常见的是，把应用部署在虚拟机里之后，还需要手动维护协作处理日志搜集、灾难恢复、数据备份等辅助工作的守护进程。

容器技术在功能单位的划分上有着独一无二的 "细粒度" 优势。使用容器技术可以将那些原先挤在同一个虚拟机里的应用、组件、守护进程分别做成镜像，然后运行在专属的容器中。

进程互不干涉，各自拥有资源配额，可以被调度到整个集群里的任何一台机器上。

这正是 PaaS 系统最理想的工作状态，也是所谓 "微服务" 思想得以落地的先决条件。

围绕容器，Kubernetes 项目核心功能的 "全景图" 如图所示👇

为了解决容器间需要 "紧密协作" 的难题，Kubernetes 系统中使用了 Pod 这种抽象的概念来管理各种资源；

当需要一次性启动多个应用实例时，可以通过系统中的多实例管理器 Deployment 实现；

当需要通过一个固定的 IP 地址和端口以负载均衡的方式访问 Pod 时，可以通过 Service 实现。

🍇 Kubernetes 项目对容器间的访问进行了分类

在服务器上运行的应用服务频繁进行交互访问和信息交换。

在常规环境下，这些应用往往会被直接部署在同一台机器上，通过本地主机（Local Host）通信并在本地磁盘目录中交换文件。

在 Kubernetes 项目中，这些运行的容器被划分到同一个 Pod 内，并共享 Namespace 和同一组数据卷，从而达到高效率交换信息的目的。

还有另外一些常见的需求，比如 Web 应用对数据库的访问。

在生产环境中它们不会被部署在同一台机器上，这样即使 Web 应用所在的服务器宕机，数据库也不会受影响。

容器的 IP 地址等信息不是固定的，为了使 Web 应用可以快速找到数据库容器的 Pod，Kubernetes 项目提供了一种名为 Service 的服务。

Service 服务的主要作用是作为 Pod 的代理入口（Portal），代替 Pod 对外暴露一个固定的网络地址。

这样，运行 Web 应用的 Pod，就只需要关心数据库 Pod 提供的 Service 信息。

🍑 Kubernetes 的优势

Kubernetes 系统不仅可以实现跨集群调度、水平扩展、监控、备份、灾难恢复，还可以解决大型互联网集群中多任务处理的瓶颈。

Kubernetes 遵循微服务架构理论，将整个系统划分为多个功能各异的组件。

各组件结构清晰、部署简单，可以非常方便地运行于系统环境之中。

利用容器的扩容机制，系统将容器归类，形成 "容器集"（Pod），用于帮助用户调度工作负载（Word Load），并为这些容器提供联网和存储服务。

2017 年 Google 的搜索热度报告中显示，Kubernetes 搜索热度已经超过了 Mesos 和 Docker Swarm，这也标志着 Kubernetes 在容器编排市场逐渐占有主导地位，如图所示👇

近几年容器技术得到广泛应用，使用 Kubernetes 系统管理容器的企业也在不断增加，Kubernetes 系统的主要功能如表所示。

Kubernetes 提供的这些功能去除了不必要的限制和规范，使应用程序开发者能够从繁杂的运维中解放出来，获得了更大的发挥空间。