本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
容器中的有状态应用程序！？Kubernetes 1.3说“是！”
祝贺 Kubernetes 社区再次发布充满价值的版本。对有状态应用程序和联邦集群的关注是我对 1.3 版本感到如此兴奋的两个原因。Kubernetes 对 Cassandra、Kafka 和 MongoDB 等有状态应用程序的支持至关重要。重要的服务依赖于数据库、键值存储、消息队列等等。此外，仅仅依赖一个数据中心或容器集群是行不通的，因为应用程序的增长会为世界各地数百万用户提供服务。集群联邦允许用户跨多个集群和数据中心部署应用程序，以实现规模和弹性。
您可能之前听我说过，容器是下一个伟大的应用程序平台。Diamanti 正在加速生产中用于有状态应用程序的容器采用，而性能和易于部署至关重要。
应用程序需要的不仅仅是牲畜
除了像 Web 服务器这样的无状态容器（所谓的“牲畜”，因为它们可以互换）之外，用户越来越多地使用容器部署有状态工作负载，以从“构建一次，随处运行”中获益，并提高裸机效率/利用率。这些“宠物”（之所以这么称呼，是因为每个宠物都需要特殊处理）带来了新的需求，包括更长的生命周期、配置依赖性、有状态故障转移和性能敏感性。容器编排必须解决这些需求，才能成功部署和扩展应用程序。
进入 Pet Set，这是 Kubernetes 1.3 中的一个新对象，用于改进有状态应用程序支持。Pet Set 按顺序执行每个数据库副本的启动阶段（例如），确保有序的主/从配置。Pet Set 还通过利用无处不在的 DNS SRV 记录（一种公认且长期理解的机制）简化了服务发现。
Diamanti 对 Kubernetes 的 FlexVolume 贡献 通过提供具有低延迟存储和有保障的性能（包括从容器到介质的强制服务质量）的持久卷来实现有状态工作负载。
一个联邦主义者
计划应用程序可用性的用户必须应对跨地域的故障转移和扩展问题。跨集群联邦服务允许容器化应用程序轻松地跨多个集群部署。联邦服务解决了诸如管理多个容器集群以及协调跨联邦集群的服务部署和服务发现等挑战。
像严格的集中式模型一样，联邦提供了一个通用的应用程序部署接口。但是，由于每个集群都保留自主权，因此联邦在网络中断和其他事件期间增加了在本地管理集群的灵活性。跨集群联邦服务还可以在容器集群中应用一致的服务命名和采用，从而简化 DNS 解析。
很容易想象在未来的版本中，跨集群联邦服务有强大的多集群用例。一个例子是根据治理、安全性和性能要求调度容器。Diamanti 的调度程序扩展就是考虑到这个概念而开发的。我们的首次实施使 Kubernetes 调度程序能够感知每个集群节点本地的网络和存储资源。未来，类似的概念可以应用于更广泛的跨集群联邦服务的位置控制。
参与进来
随着对有状态应用程序的兴趣日益增长，已经开始进一步增强 Kubernetes 存储。存储特别兴趣小组正在讨论支持本地存储资源的提案。Diamanti 期待扩展 FlexVolume，以包括更丰富的 API，从而实现本地存储和存储服务，包括数据保护、复制和缩减。我们还在制定提案，以通过 Kubernetes 跨集群联邦服务改进跨容器集群的应用程序放置、迁移和故障转移。
加入对话并做出贡献！以下是一些入门的地方