Docker，容器和状态

分布式云原生应用的状态管理问题并不是Kubernetes独有的。搜索一下就能发现，其他容器编排系统，如Mesos和Docker Swarm等也都一直在关注有状态工作负载。究其原因，一方面与容器编排的性质有关，另一方面则是由容器本身的性质决定的。

下面来谈一谈容器。容器的一大关键价值定位就是临时性。因为容器的设计初衷就是可以随用随建并且可以替换，所以容器要能快速启动并使用尽可能少的资源来节省开销。基于此，大多数容器镜像都是在基础镜像中创建的。这些基础镜像包含精简的、基于Linux的开源操作系统，如Ubuntu，这些系统可以快速启动，并且仅包含容器化应用或微服务的基本库。顾名思义，容器的设计是自包含的，将所有依赖项都整合到不可变镜像中，而将容器自身的配置和数据都存储在容器外。这些特性赋予了容器可移植性，即容器可以在任何兼容的容器运行时运行。

如图2-1所示，与传统的虚拟机相比，容器所需的开销更少。每个虚拟机上都运行一个客户机操作系统，并通过Hypervisor（见网址列表条目[17]）调用底层的主机操作系统。

图2-1 容器化方案与虚拟化方案的对比

尽管容器技术使得应用更具可移植性，但事实证明，移植应用数据的难度也随之加大。由于容器本身是临时的，因此任何需要超出容器生命周期的数据都必须定义在容器外。容器技术的关键特性是提供相关机制以便连接到持久化存储，而容器编排技术的关键特性则是调用容器以便高效地访问持久化存储。