容器中运行有状态服务? 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）

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