1. 引言

此前的文章中，我们介绍了 Docker 的使用以及工作原理：

一文带你全面了解 docker 的概念与使用

docker 赖以实现资源隔离与限制的原理

我们看到 Docker 的本质其实就是被 linux 系统机制隔离的进程，有了这样的隔离性，我们能够借以实现我们的微服务架构。

但是，在微服务架构中，往往会有许许多多的服务，光是将他们一个个以 docker 的形式启动起来并不能解决我们的核心问题 — 集群管理。

那么，如何去管理 Docker 形成的集群呢？目前市面上有着许许多多的容器管理方案，下图就是 2018 年的容器管理技术市场占有率的调查结果：

本文我们就来介绍一下 Docker Swarm 与 Kubernetes 的核心思想。

2. Docker Compose

此前的文章中，我们介绍了 Docker Compose 的用法，它让我们可以将多个 Docker 容器链接成一个组合的功能，这个组合中的所有容器可以被一次性全部部署、启动或停止。

这对于我们单机部署多个相互有依赖关系的 Docker 镜像时，有着很大的帮助。

但对于多个物理机或虚拟主机组成的集群来说，Docker Compose 就力不从心了。我们往往需要一个更高等级的中心化平台去管理和调度整个由 Docker 镜像构成的集群。

3. Docker Swarm

Docker1.12 版本开始，Docker 引擎中原生内建了 Docker Swarm Mode 只要通过 Docker Engine CLI/API 就可以建立并且管理 Docker Swarm 集群，无需额外的安装和设定。

Docker Swarm 将集群中不同的设备划分为两种不同的角色：Manager 和 Worker，它们组成了 Docker Overlay Network 网络机制：

Worker 负责业务容器的运行，Manager 则负责集群的管理。

基于这样的集群管理模式，我们可以实现：

1. 自动化跨主机 host 的集群搭建；

2. 集群规模的按需缩放，但目前尚不成熟；

3. worker 容器宕机后，在冗余的 Worker 主机上自动启动 Worker 来容灾；

4. 镜像版本的升级和回滚；

5. 支持 Routing Mesh 复杂均衡。

4. Kubernetes

4.1 什么是 Kubernetes

基于 Docker Compose 我们可以实现单机的多 Docker 镜像的依赖管理，基于 Docker Swarm，我们可以实现集群组建与调度。那么，针对线上微服务场景，Docker 原生的所有工具是否已经完全可以满足我们的一切需要了呢？

Google 公司告诉我们说不行，因为：

在大规模集群中的各种任务之间运行，实际上存在着各种各样的关系，处理这些关系才是作业编排和管理系统最困难的地方。

Kubernetes 的设计思想是以统一的方式抽象底层基础设施（计算、存储、网络等）的能力，定义任务编排的各种关系（亲密关系、访问关系、代理关系等），将这些抽象以声明式 API 的方式对外暴露，从而允许平台构建者基于这些抽象进一步构建自己的 PaaS 集群乃至更上层的平台。于是，Kubernetes 便成为了构建平台的基础平台。

相比于 Docker Swarm，Kubernetes 更进一步将平台构建进行了抽象，这深一层的抽象，让 Kubernetes 项目不只是简单地提供编排能力，而是变成了一系列具有普遍意义的、以声明式 API 驱动的容器化作业编排思想。如果将 Docker Swarm 看成是承载了战斗机集群的一架航母，那么 Kubernetes 可以被看作是一个航母设计平台。

由于 Kubernetes 在 K 和最后的 s 之间有 8 个字母，于是人们通常将这个长长的名字简化为 K8s，而在中文发音中，K8s 又恰好与 Kubernetes 十分相似，K8s 也就成为了人们十分喜欢的简称。

4.2 K8s 的抽象

上图展示了 K8s 核心功能的全景图。

4.2.1 Pod

位于上面这个全景图最核心地位的就是 Pod。

若干需要协同调度的容器被封装为一个 Pod，它们在同一个主机上，通过 localhost 进行通信，通过本地磁盘交换文件，因此，K8s 让这些容器共享同一个 Network Namespace、同一组 Volume，从而实现高效的信息交换。

4.2.2 Deployment、Job 与 Cronjob

当我们需要针对同一个 Pod 启动它的多个应用实例时，这些应用实例就被封装在一个 Deployment 中，Deployment 就是这个 Pod 的多实例管理器。

而 Job 封装了只运行一次的 Pod；Cronjob 则封装了需要周期运行的 Pod。

4.2.3 Service

Pod 中的容器要想向外提供服务，就需要绑定到一个 Service，由 Service 代理 Pod 的 IP 地址和端口，从而通过 K8s 平台的功能，让调用者无需绑定到随时可能变化的 Pod 的固定 IP 地址和端口，而是通过调用 Service 动态找到其代理的后端 Pod。

当一个 Service 代理 Deployment 时，针对 Deployment 中的多个 Pod 实例，Service 会以负载均衡的功能进行调用。

4.2.4 ConfigMap 与 Secret

在一个集群中，我们经常会需要维护许许多多诸如密钥、密码键值对等信息，这时，我们就需要定义 Secret 节点，当使用该 Secret 的 Pod 启动时，K8s 会自动把 Secret 里的数据以 Volume 的方式挂载到容器中。同理，还有维护 Pod 所需配置信息的 ConfigMap。