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