新的挑战
比武大会的名次出来了，小刀荣登探花。作为一个新人，取得了第三的好成绩，小刀和他的朋友们都非常高兴，相约一起去喝酒庆祝。
小刀没有忘记，是大师兄给了自己参赛的信心。看到结果这天，小刀就去找了大师兄。
大师兄看到小刀过来，也很是欣喜，他似乎对小刀的名次并不感到意外，对小刀说：“名次我看到了，恭喜你！”
“多谢大师兄提点，这都要感谢...”小刀作揖道。
“诶～这都是你自己的努力。”大师兄赶紧握住小刀的手说道，“既是第三，那你就要随我前去参加容器武道大会了。”
“非常荣幸能和师兄们一起去。”小刀依旧非常恭敬。
“不过～你可不要太开心。”大师兄嘿嘿一笑，说道，“既然代表门派去参加容器武道大会，那也不是白去的。可是有任务的。”
“啊！？”小刀问道，“大师兄请讲。”
“你已修炼容器功法多时，也应该知道，”大师兄边说边走向书柜，“容器功法只是基本，一个人再厉害，能操控几个容器？十个？还是二十个？而对于一个门派来说，我们要能够操控成千上万个容器的实力。”
大师兄看了小刀一眼，继续说道：“比武会上，白长老也问你了，docker-compose 只能操控单机的容器，如果成千上万个，必然是集群，那集群容器的编排就不可避免了。”
“大师兄可是指容器集群？”小刀问道。
“正是！”大师兄说道，“掌门已经下令，三个月时间，将我们门派的功法和容器集成，在门派内部全面推行容器集群。”
“三个月时间可是有些紧张？”小刀问道。
“确实有点，所以掌门也在全门派提拔人才。”大师兄看着小刀说道，“所以我力荐了你，你也确实证明了你自己。接下来，就准备接受挑战吧！”
说完，大师兄扬长而去。
集群编排
小刀被拉入了门派临时组建的「容器化改造委员会」，由掌门亲自挂帅，除了大师兄，还有之前看到的白胡子的长老，人称「白狐」的白长老，一袭灰袍，人称「灰狼」的伍三，还有另外几个师兄。小刀算是其中资历最浅的小白。
Docker Swarm
这天，「容器化改造委员会」召开了一次内部会议。会上，大师兄介绍了他这些天的研究——Docker Swarm。
Docker Swarm 是一款轻量的容器集群编排工具，由于是 Docker 自家的东西，现在已完全集成在 Docker 引擎中，且提供一致的 API 接口。
大师兄展开了 Docker Swarm 的架构图。
使用 Docker Client 可以与 Swarm Manager 交互，而 Swarm Manager 是整个集群的 Leader，由 Raft 算法选举而来，包含了基本的调度、节点发现等基本功能。Swarm Manager 通过 API 与所有节点交互，通过节点上的 Docker Daemon 控制容器的运行。
而 Docker Stack 提供期望状态、滚动升级、扩缩容、健康检查等特性简化了应用的管理，把这些功能都封装在一个简单的声明式模型当中。我们可以通过 Docker Client，以配置文件的方式快速部署应用到集群。例如部署文件 deploy.yml
version: '3.7'
services:
app:
image: web:1.0
ports:
- "8000:8080"
部署到集群
docker stack deploy -c deploy.yaml demo
然后就可以通过 service 看到
docker service ls
最后，可以移除应用。
docker stack rm demo
应用的操作就是这么简单。
Docker Swarm 提供了容器集群基本的容器管理功能，轻量快速，架构简单，但是功能相对简单，完全依赖于 Docker。对于复杂的业务场景，无法提供更精细的容器编排策略，而且容器的可靠性上也无法保证。
“不错不错！”白长老问道，“那有其他的对比方案吗？”
Kubernetes
大师兄刚想开口，白长老伸手阻止，转头面向小刀，问道：“还记得我问你的那个问题吗？”
“当然记得！”小刀说道，“除了 Docker Swarm 之外，更流行和成熟的方案就是——Kubernetes，俗称 K8S。”
Kubernetes 是 Google 门派多年容器功法的精华，是容器编排领域的集大成者。其设计理念也是开放，并不完全基于 Docker，使用者可以通过 CRI 接口接入其他容器运行时。它整体的设计上，处处体现了开放的思维。CNI 接口，用于对接不同的网络实现方案，CSI 接口用于对接不同的存储实现方案，等等。
下面这个图很好的展示了 Kubernetes 的架构。
图片来源：https://www.sohu.com/a/239563819_797717
Kubernetes 的优势
- 通过各种接口（CRI，CNI，CSI）提供了更灵活的实现方式
- 更强大的容器调度能力和容错能力
- 丰富的扩展插件
- 通过 CRD 提供了强大的扩展能力
- 活跃的社区和丰富的周边生态
上面可以看到，Kubernetes 集群由 Master 节点和 Worker 节点组成，Master 节点上主要有三大组件：API Server，Scheduler 和 Controller Manager。而 Worker 节点上，有 Kubelet 作为代理，与 Master 节点进行通信，Proxy 作为容器交互的网络代理。
API Server 暴露 Kubernetes 集群的管理 API，是集群管理的入口。
Scheduler 用于容器的调度，为 Pod 选择合适的运行节点。
Controller Manager 是一系列控制器的统称，例如，Node Controller 管理失联的节点，Replication Controller 用于管理运行的 Pod 数量，Endpoints Controller 用于连接 Service 和 Pod，Service Account & Token Controllers 管理认证和权限。
Cloud Controller Manager 用于集群和各种公有云的服务进行交互。
而 ectd 是一个分布式的存储服务，所有集群的数据都存储于 etcd 集群中，提供了高可用的集群数据存储服务。
而 Kubernetes 集群有几个核心概念。
Pod
Pod 是 Kubernetes 集群部署的最小单元，一个 Pod 可以包含一个或者多个容器。
那为什么不直接管理容器，而要用 Pod 来包装容器呢？
Pod 可以包含多个容器，作为最小的部署单元，将多个容器绑定，做到同时管理、扩缩容的目的。
Pod 内的容器共享网络和存储，可达到非侵入的注入能力，例如自动为每个 Pod 绑定一个日志收集容器，代理容器等等。
另外，仔细看节点上的容器会发现，每个 Pod 都会配备一个 Pause 容器，那这个 Pause 容器的用处是什么呢？
我们知道，Docker 可以为每个容器创建一个独立的命名空间，如果没有 Pause 容器，启动业务容器并创建一个命名空间，那如果这个容器挂了，这个命名空间也就没有了。如果有多个容器，那拿哪一个容器作为第一个容器都是不合理的。
因此 Pause 容器也被称作基础架构容器，其作为 Pod 整个命名空间的第一个容器，撑起了整个命名空间，使得命令空间的生命周期与 Pause 容器的生命周期一致。同时，Pause 容器也非常轻量，不做任何操作，对资源的占用基本可以忽略不计。
Service
Service 可以看作一个具体的服务，Service 后面对接的是一系列的 Pod。可以认为，一类相同的 Pod 共同以 Service 的身份对集群暴露一致的服务地址。
Pod 的扩缩容、重建等都会导致 Pod IP 的改变，但是 Service 动态地维护了对应的 Pod IP，而 Service 的 IP 和域名是不变的，就对集群或者其他服务提供了一个稳定的访问地址，同时又起到了负载均衡的作用。
Namespace
Namespace 是 Kubernetes 集群的逻辑概念，类似于 Linux 的 Namespace，集群将一系列的 Pod、Service 等资源组织在一个命名空间下面。在不同的命名空间下，可以有完全一样命名的资源，起到了逻辑隔离的作用。
Node
Node 即为集群中的节点，包括 Master 节点和 Worker 节点，节点用于承载具体的 Pod，每个节点由 Kubelet 服务与 Master 的 API server 交互。当节点离线或者宕机后，集群会迁移其上的 Pod 到其他节点上。节点是集群层级的资源，所以不属于任何一个 Namespace。
当然，Kubernetes 的内容非常丰富，这里仅能抛砖引玉，让大家有个初步的了解。
后记
小刀的介绍引得大家的拍手称赞，白长老开心地说：“年轻人大有可为，看来我们都该退休了。哈哈～”
小刀连连感谢，环顾四周，不经意间与大师兄眼神对视。只见大师兄正欣慰地看着自己，一阵难以言表的感觉，赶紧避开。
这是什么情况？
请关注「容器霸业」，知乎专栏同步更新。
上一章：容器霸业：5 比武大会
