薄情先生|Docker，容器，编排，和基于容器的系统设计模式( 三 ) 都2020年了

答案在他的设计上，这个说起来得详细介绍k8s才能说明白。从设计上说， k8s整体是基于API设计，即整体架构中涉及的组件都可插拔，以容器举例，在k8s中，容器是可替换的，只要满足对应的接口设计的标准即可， docker是其中一种方案，而其他容器技术也是可选方案。和容器类似的还有网络插件， volume插件等等。有关k8s的详细内容这里不多介绍，有兴趣的童鞋可以参考以下文档：

kubernetes设计理念
Kubernetes设计架构

即整个设计是以集群管理为核心，整体架构都是松散的，可插拔的。而swarm则是以docker为核心，两者设计就存在本质上的区别。
而后在容器的基础上， k8s添加了另一层的封装，即Pod ，所谓Pod ，是一组相同或功能类似的容器所组成的组（task group）。为什么要有Pod呢？还记得容器的本质是什么吗，是操作系统中的一组进程，从某种程度上来说，从进程这个层次来进行管理，有些繁杂了。比如Linux都有进程组这个概念管理相同或彼此联系的一些进程（比如一个功能由多个进程协作完成，这多个进程构成一个进程组）。
在容器编排中，往往多个容器间也会有类似进程和进程组的关系（这里就不举例了，很多分布式组件都有这种情况），所以需要一个更高层次的抽象来帮助我们对容器进行管理。在k8s中，承担类似进程组的就是Pod ， Pod是一种逻辑上的概念，同时Pod也是k8s中最小的调度单位，同组Pod中的容器都是共享volumns 。

有了Pod ，也就是组这个概念后，就能够更加方便对不同服务进行管理。但是它还有个更重要的意义，那就是基于容器的系统设计模式。
基于容器的分布式系统设计之道让我们回到1980年，假设你是一个写惯了C的程序员，你接触到一个名叫面向对象的编程概念，你会怎么看待这个东西呢？能够想象这个东西在30年后会占据编程领域的大半壁江山吗？
而如今，docker容器（或者说Pod）就是一种类似OOP的东西，核心都是通过模块化封装，将不同的东西相互隔离，让它们相互配合，完成某些事情。
从这个角度，或许就能明白为什么前面说到的，容器价值不高，真正有价值的是编排。因为我们同样不会觉得一个java object有多大价值， OOP的编程思想，及其衍生的设计模式才是精髓。
那么从分布式系统的设计模式的角度来说，容器可以有多少种分类呢？和分布式系统的搭建模式类似，有三种。

单容器模式（single-container patterns for container management）
单节点协作模式（single-node patterns of closely cooperating containers）
和多节点协作模式（multi-node patterns）

PS：这部分内容多参考自google的Design patterns for container-based distributed systems ，想看原味论文的童鞋请戳最下方的链接。
单容器模式和单节点协作模式看起来相似，但实际是完全不同的东西。
单容器模式，简单说就是在传统Docker的基础上（传统docker的行为比较简单，只有run() ， pause() ， stop()），提供更加丰富的功能和生命周期的管理。说得更简单点，使用k8s管理单个docker服务。
我们主要介绍单节点协作模式和多节点协作模式。
单节点协作模式单节点协作模式，简单说就是在一个分布式的容器服务环境中，通过一个单节点的服务辅助进行管理的这类模式。在这种模式中，需要依赖于k8s中， Pod这个概念的抽象， Pod即task group ，一组相同或类似服务的容器的集合。