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