🌟 前言

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

2. Kubernetes体系结构

🍑 集群体系结构

Kubernetes 集群主要由控制节点 Master（部署高可用需要两个以上）和多个工作节点 Node 组成，两种节点上分别运行着不同的组件来维持集群高效稳定的运转，另外还需要集群状态存储系统（etcd）来提供数据存储服务。

Kubernetes 集群中各节点和 Pod 的对应关系如图所示👇

Kubernetes 的系统架构中，Master 节点上主要运行着 API Server、Controller Manager 和 Scheduler 组件，而每个 Node 节点上主要运行着 Kubelet、Kubernetes Proxy 和 容器引擎。

除此之外，完整的集群服务还依赖一些附加的组件，如 kubeDNS、Heapster、Ingress Controller 等。

🍑 Master 节点与相关组件

控制节点 Master 是整个集群的网络中枢，主要负责组件或者服务进程的管理和控制，例如，追踪其它服务器健康状态、保持各组件之间的通信、为用户或者服务提供 API 接口。

Master 中的组件可以在集群中的任何计算机上运行。

但是，为简单起见，设置时通常会在一台计算机上部署和启动所有主组件，并且不在此计算机上运行用户容器。

在控制节点 Master 中所部署的组件包括以下三种。

🍇 API Server

API Server 是整个集群的网关，作为 Kubernetes 系统的入口，其内部封装了核心对象的 “增、删、改、查” 操作，以 REST API 方式供外部客户和内部组件调用，就像是机场的 “联络室”。

🍇 Scheduler 调度器

该组件监视新创建且未分配工作节点的 Pod，并根据不同的需求将其分配到工作节点中。

同时负责集群的资源调度、组件抽离。

🍇 Controller Manager 控制器管理器

Controller Manager 是所有资源对象的自动化控制中心，大多数对集群的操作都是由几个被称为控制器的进程执行的，这些进程被集成于 kube-controller-manager 守护进程中。实现的主要功能如下：

（1）生命周期功能：Namespace 创建，Event、Pod、Node 和 级联垃圾 的回收。

（2）API 业务逻辑功能：ReplicaSet 执行的 Pod 扩展等。

Kubernetes 主要控制器功能如表所示。

另外 Kubernetes1.16 版本还加入了云控制器管理组件，用来与云提供商交互。

🍑 Node节点与相关组件

Node 节点是集群中的工作节点（在早期的版本中也被称为 Minion），主要负责接收 Master 的工作指令并执行相应的任务。

当某个 Node 节点宕机时，Master 节点会将负载切换到其它的工作节点上，Node 节点与 Master 节点的关系如图所示👇

Node 节点上所部署的组件包括以下三种。

🍇 Kubelet

Kubelet 组件主要负责管控容器，它会从 API Server 接收 Pod 的创建请求，然后进行相关的启动和停止容器操作。同时，Kubelet 监控容器的运行状态并 “汇报” 给 API Server。

🍇 Kubernetes Proxy

Kubernetes Proxy 组件负责为 Pod 创建代理服务，从 API Server 获取所有的 Service 信息，并创建相关的代理服务，实现 Service 到 Pod 的请求路由和转发。

Kubernetes Proxy 在 Kubernetes 层级的虚拟转发网络中扮演着重要的角色。

🍇 Docker Engine

Docker Engine 主要负责本机的容器创建和管理工作。

🍑 集群状态存储组件

Kubernetes 集群中所有的状态信息都存储于 etcd 数据库中。

etcd 以高度一致的分布式键值存储，在集群中是独立的服务组件，可以实现集群发现、共享配置以及一致性保障（如数据库主节点选择、分布式锁）等功能。

在生产环境中，建议以集群的方式运行 etcd 并保证其可用性。etcd 不仅可提供键值存储，还可以提供监听（Watch）机制。

键值发生改变时 etcd 会通知 AIP Server，并由其通过 Watch API 向客户端输出用户可以访问 Kubernetes 官方网站查看更多的 etcd 说明。

🍑 其他组件

Kubernetes 集群还支持 DNS、Web UI 等插件，用于提供更完善的集群功能，这些插件的命名空间资源属于命名空间 kube-system，下面列出了常用的插件及其主要功能。

🍇 DNS

DNS（Domain Name System，域名系统）插件用于集群中的主机名、IP 地址的解析。

🍇 Web UI

Web UI（用户界面）是提供可视界面的插件，允许用户通过界面来管理集群中运行的应用程序。

🍇 Container Resource Monitoring

Container Resource Monitoring（容器资源监视器）用于容器中的资源监视，并在数据库中记录这些资源分配。

🍇 Cluster-level Logging

Cluster level Logging（集群级日志）是用于集群中日志记录的插件，负责保存容器日志与搜索存储的中央日志信息。

🍇 Ingress Controller

Ingress Controller 可以定义路由规则并在应用层实现 HTTP（S）负载均衡机制。

3. 深入理解 Kubernetes

Kubernetes 在容器层面而非硬件层面运行，因此它不仅提供了 PaaS 产品的部署、扩展、负载平衡、日志记录和监控功能，还提供了构建开发人员平台的构建块，在重要的地方保留了用户选择灵活性。

Kubernetes 的其它特征如下所示。

（1）Kubernetes 支持各种各样的工作负载，包括无状态、有状态和数据处理的工作负载。如果应用程序可以在容器中运行，那么它也可以在 Kubernetes 上运行。

（2）不支持部署源代码和构建的应用程序，其持续集成、交付和部署工作流程由企业自行部署。

（3）Kubernetes 只是一个平台，它不提供应用程序级服务，包括中间件（如消息总线）、数据处理框架（如 Spark）、数据库（如 MySQL）、高速缓存、集群存储系统（如 Ceph）等。

（4）Kubernetes 不提供或授权配置语言（如jsonnet），只提供了一个声明性的 API，用户可以通过任意形式的声明性规范来实现所需要的功能。

4. 总结

本篇文章介绍了容器编排工具 Kubernetes 的发展历史、使用优势，同时对部署 Kubernetes 集群的一些核心概念和网络进行了讲解。

大家应该深入理解集群中 Master 节点、Node 节点上运行的核心组件，以及这些组件实现的功能和相互关系，了解 Pod 中各个容器的通信方式和工作原理。

下一篇文章节将介绍 Kubernetes 的安装和基本配置。