容器中运行有状态服务? Kubernetes Says “Yes!”

编者按：本文做者是 Diamanti 的产品 VP Mark Balch，他将更多的分享他们向 Kubernetes作出的一些贡献。这篇文章是关于 Kubernetes 1.3 新功能的一系列深刻文章中的第五篇。

首先，祝贺 Kubernetes 社区最近又发布了一个带来丰富价值的版本。对有状态应用和联邦集群的更好支持，是我对 Kubernetes 1.3 版本如此兴奋的两个主要缘由。

Kubernetes对有状态应用的支持是很是关键的，好比 Cassandra，Kafka 和 MongoDB。一些重要的服务都会依赖于数据库，键值存储、消息队列等其余存储服务。

此外，随着应用访问量的不断增长，可能须要服务于全球数以百万计的用户，而依赖于一个数据中心或容器集群将没法知足这样的需求。联邦集群则能够知足规模和弹性的灵活需求，容许用户跨多个集群和数据中心进行应用部署。

你之前可能听我说过，容器将会是下一个重要的应用平台。Diamanti 正在加速以容器技术运行有状态服务在生产环境中的采用，这时咱们就更须要关心性能和易于部署。

应用须要的不止是 Cattle

除了无状态的容器服务，好比 Web服务器（之因此称之为“Cattle”由于这些实例是彼此能够替代的），用户也愈来愈多的使用容器部署有状态的工做任务，这样才能从 “build once, run anywhere” 的优点中受益，并能够改善裸机的效率和利用率。

这些 “pets” （运行有状态服务的容器 ,须要特殊处理）就带来了新的需求，包括更长的生命周期，配置依赖，有状态的故障转移以及对性能的要求。为了成功的部署和伸缩应用，容器编排系统就必须解决这些需求。

下面咱们来看一下 Pet Set，它是 Kubernetes 1.3 引入的对象类型，目的是改善对有状态服务的支持。

例如 Pet Set 经过每一个数据库副本的启动阶段进行排序，确保有序的主/从配置。

Pet Set 也经过无处不在的DNS SRV 记录简化了服务发现，一个熟知和简单明了的处理机制。

Diamanti 将 FlexVolume 贡献给Kubernetes社区，经过提供低延时、可保证性能的持久化存储卷，来更好的支持有状态的工做负载，包括从容器到存储介质的强制 QoS。

联邦集群

规划应用程序可用性的用户必须面对跨地域的故障转移和弹性伸缩的问题。跨集群的联合服务容许容器化应用跨多个集群的轻松部署。

联邦服务将会处理各类挑战，好比跨联邦集群来管理多个容器集群，协调服务部署和服务发现。

就像一个严格中心化的模型，联邦提供一个通用的应用程序部署接口。每个集群仍然保持自制，然而在网络中断和其余异常事件发生时，联邦为本地管理集群带来了很大灵活性。

跨集群联邦服务也应用于一致服务命名和跨容器集群部署，简化了DNS解析。

在将来的版本中，很容易想象使用跨集群联邦服务带来的强大的多集群使用案例。

一个例子是基于管理要求，安全性和性能需求来调度容器。 Diamanti 的调度扩展模块就是根据这个概念开发出来的。

咱们的第一个实现使 Kubernetes 调度器能够感知对于每一个集群节点的本地网络和存储资源。相似的概念在将来能够应用于跨集群联邦服务的更普遍的调度控制。

如何参与？

随着对有状态应用的兴趣的日益提高，进一步加强 Kubernetes 存储的工做已经开始了。

存储特别兴趣小组（SIG）正在讨论支持本地存储资源的提议。 Diamanti 也在期待扩展FlexVolume 来包括更丰富的API，从而支持本地存储和存储服务，包括数据保护，复制和还原。

咱们还致力于一些其余相关提议，包括改善跨集群联邦服务下容器的存放、迁移和故障转移。

加入相关会话并做出贡献！你能够先从这些地方开始：

产品管理组（https://groups.google.com/for...!forum/kubernetes-pm）

Kubernetes 存储 SIG （https://groups.google.com/for...!forum/kubernetes-sig-storage）

Kubernetes 集群联邦 SIG（https://groups.google.com/for...!forum/kubernetes-sig-federation）

本文由时速云翻译，如若转载，需注明转载自“时速云”

原文连接：http://blog.kubernetes.io/201...