亲历者说: Kubernetes API 与 Operator, 不为人知的开发者战争( 五 )_如果我问你

但是，在容器的世界里，分布式应用却成了一个“异类” 。我们知道，容器的本质，其实就是一个被限制了“世界观”的进程。在这种隔离和限制的大基调下，容器技术本身的“人格基因” ，就是对外部世界（即：宿主机）的“视而不见”和“充耳不闻” 。所以我们经常说，容器的“状态”一定是“易失”的。其实，容器对它的“小世界”之外的状态和数据漠不关心，正是这种“隔离性”的主要体现。

但状态“易失”并不能说是容器的缺陷：我们既然对容器可以重现完整的应用执行环境的“一致性”拍手称赞，那就必然要对这种能力背后的限制了然于心。这种默契，也正是早期的 Docker 公司所向披靡的重要背景：在这个阶段，相比于“容器化”的巨大吸引力，开发者是可以暂时接受一部分应用不能运行在容器里的。

而分布式应用容器化的困境，其实就在于它成为了这种“容器化”默契的“终极破坏者” 。

一个应用本身可以拥有多个可扩展的实例，这本来是容器化应用令人津津乐道的一个优势。但是一旦这些实例像分布式应用这样具有了拓扑关系，以及，这些实例本身不完全等价的时候，容器化的解决方案就再次变得“丑陋”起来：这种情况下，应用开发者们不仅又要为这些容器实例编写一套难以维护的管理脚本，还必须要想办法应对容器重启后状态丢失的难题。而这些容器状态的维护，实际上往往需要打破容器的隔离性、让容器对外部世界有所感知才能做到，这就使得容器化与有状态，成为了两种完全相悖的需求。