哈喽大家好，我是咸鱼
咸鱼在《一文带你了解容器技术的前世今生》有介绍过容器技术的由来以及Docker项目的发展
我们知道，Docker 及其他容器技术能够极大地简化应用程序的部署，做到了”开箱即用“
俗话说：”凡是具有两面性“。容器技术给我们带来便利的同时，一些问题也随之出现了
随着企业规模或者说业务规模的不断扩大，应用程序越来越多、而每个应用程序往往又由多个容器组成
例如想要实现一个简单的数据库 web 界面也可能需要为数据库服务器和应用程序运行单独的容器
于是容器的管理便成为了一个棘手的难题。工程师们为了解决这个问题，开发了一系列的容器编排器（container orchestrator），其中最有名的当属 kubernetes
容器编排器可以将一组容器作为一个基本单元去进行管理（例如 K8s 里的 pod），而且容器编排器可以在集群之间自动分配容器工作负载
那么今天，咸鱼将以自我介绍的形式来带大家了解三个容器编排器——Docker Compose、Swarm、Kubernetes
Docker Compose
大家好，我叫 Docker Compose 。我的爸爸是一个名叫 Docker 的公司
我的前身是一个叫 Fig 的项目，Fig 项目可是大有来头——因为它第一次提出了容器编排的概念
你只需要执行一条命令 fig up 就能够依次创建一系列容器，并且容器之间的关系及依赖性，都会自动帮你解决
当时它在 Github 上的热度可是比肩 Docker 的，后来我的爸爸秉承”打不过就加入“的理念，把 Fig 项目收购了
收购之后将名字改成了 Compose，于是我诞生了
我是根据一个 yaml 格式的配置文件来工作的，通常命名为 Docker-compose.yml ：
- 首先我会去读取这个文件，然后通过 Docker API 创建这个文件声明的资源
- 我还会为这些资源打上标签，方便我创建之后将它们分组管理
实际上我并不能够称得上是一个容器编排器，因为我实际上是通过 Docker 命令行接口（Docker command-line interface ）去操作一组组容器的
举个例子，比如说在配置文件里有这三种类型的资源：
- service：包含了要启动的容器的声明。里面的每一个条目都相当于一个
Docker run命令 - networks：包含了可以访问到容器的网络。里面的每个条目都相当于一个
Docker network create命令 - volumes：包含了可以访问到容器内部的容器卷（容器卷即能够挂载到容器内部的持久存储）。里面的每一个条目都相当于一个
Docker vloume create命令
尽管如此，我依旧能够较好地管理容器之间的依赖关系，我还能够为容器创建一个共享网络和卷，使它们可以相互通信和共享数据
但是我不能够实现容器的高可用性，如果容器出现故障，需要手动进行恢复
Swarm
哈喽大家好，我叫 Swarm
Docker Compose 虽然为大家提供了一种方便的方式去管理容器，但他在一开始的时候只能在单台主机上工作
也就是说他创建的所有容器都在同一台机器上面运行，抛开性能不谈，如果所有应用都在一台服务器上，要是这台服务器宕了，后果可是不堪设想的
为了解决这个问题，早在 2014 年我的哥哥 Classic Swarm （https://github.com/Docker-archive/classicswarm ）
就已经开始提供跨主机运行容器的解决方案了，但不久之后我的爸爸就不管他了，在社区上不再维护
时间来到 2016 年，我诞生了
与我的哥哥 Classic Swarm 相比，我是直接被内置到了 Docker 当中
不但如此，我能够提供更强大的功能和更好的性能，支持服务发现、负载均衡、滚动更新等特性
创建集群的时候，我只需要在初始节点上执行 Docker swarm init 命令，然后在每个要添加进集群的其他节点上面执行 Docker swarm join 命令就可以了
怎么样，是不是非常方便
小伙伴们可能对我怎么管理集群比较关心，首先我会将集群中的节点分成两类：
- 管理节点（Manager nodes）
管理节点提供了一个 API ，可以通过这个 API 来启动容器
而且管理节点之间使用基于 Raft 共识算法的协议相互通信，便于同步集群的状态，实现了高可用性和数据一致性
- 工作节点（Worker nodes）
工作节点，顾名思义就是就负责干活的节点啦。它们负责执行实际的容器工作
而且我的爸爸跟我说管理节点最多只能设置七个，但工作节点数量不限制
别看我这么能干，其实我也有一些缺点，毕竟器无完器嘛
缺点一：集群里面不能够实现跨节点共享存储
虽然我支持集群里面跨节点网络通信（使用桥接方法），但是我不能够支持跨节点的共享存储。我必须依赖第三方的卷插件才能实现
缺点二：stack file 和 compose file 难以区分
自从我被集成到 Docker Engine 后，我发现我能够通过 compose 文件来部署服务了（部署 services、volumes等资源）
而你们也知道的，compose 文件一开始是给 Docker Compose 用的
我们来看下对比，可以看到用法是很相似的
Docker-compose -f Docker-compose up
Docker stack deploy -c Docker-compose.yml somestackname
但实际上我是通过 stack file 来进行集群部署的，stack file 也是 YML 格式的文件，它跟 compose file 极其相似
这样就会导致一些初学者在学习的时候不知道该用 stack file 还是 compose file ，可以看下下面这个 issue
PS：一般来讲，Stack file 和Compose file 的语法和功能非常相似，都可以用来定义和部署多个服务或容器
但是，Stack file 更加适合用来管理生产环境中的服务，而Compose file 更加适合用来管理开发和测试环境中的容器
此外，Stack file 还支持一些 Compose file 不支持的功能，如服务发现、负载均衡、滚动更新等
我的器生并非一帆风顺，我曾经可是 Docker Cloud 的支柱，但是 Docker Cloud 在 2018 年的时候就被关闭了
不但如此，随着对手 Kubernetes 的发展，我的地位不断地受到威胁。直到 2019 年，我的爸爸宣布停止对我的开发和维护，将重心转向 Kubernetes
可谓是：”跻攀分寸不可上，失势一落千丈强“
Kubernetes
哈喽大家好，我叫 Kubernetes。为了方便，你们可以叫我 K8s
想必大家都听说过我，作为迄今为止最受欢迎的容器编排器，我能够在多达数千个节点的集群上管理和分配资源
请允许我骄傲一下，我在容器编排器中地位相当于谷歌在搜素引擎中的地位，可以说是我主导了容器编排
但我能有今天，一方面归功于我的爸爸是谷歌，另一方面我得到了云原生计算基金会(Cloud Native Computing Foundation，CNCF)的支持
在 2014~2015 年间，整个容器社区可谓热闹