为什么Kubernetes Operator是游戏规则的改变者?


【编者的话】“Operators”,让Kubernetes管理更简单!本文从各个方面不同角度论证为什么Kubernetes Operator会改变整个游戏规则。

整个Web开发社区都在为Kubernetes(K8s)而沸腾。毫无疑问,去年的大会和开发人员集会上这都是最热的话题。

它并非仅仅是管理容器的工具,实际上,Kubernetes允许用户轻松地添加负载均衡,并且无需使用服务发现层(比如,不再需要eureka)。Kubernetes还能够自动化应用程序的部署和更新,更为重要的是,它让用户可以为自己的基础架构添加/编写自定义的控制器。

是不是很棒?但是管理无状态的容器毕竟并不是那么复杂,它们本质上是短暂的,你可以随意杀死并且重新启动实例,并不会带来什么副作用。

但是这只是故事的一部分,应用程序不可能全部无状态,在大多数情况下,我们简单地将状态推送到下层去处理。因此,在Kubernetes里如何处理有状态的应用程序呢?幸运的是,从1.5版本开始出现了StatefulSet。

有状态容器

Kubernetes StatefulSet提供了一系列资源来处理有状态的容器,比如:volume,stable network id, 从0到N的顺序索引等。volume是其中的核心特性之一,让用户可以在Kubernetes上运行有状态的应用,让我们看看目前支持的两大主要类型:

短暂的存储卷

短暂存储的行为和我们在Docker里使用的有所区别,在Kubernetes里,短暂存储在容器外存在,在Pod里运行,数据可以跨容器的重启保留。但是如果Pod被杀死,这个卷就会被自动移除。

持久化存储卷

在持久化存储里,正如名字所示,数据的生命周期独立于Pod的生命周期。因此,即使当Pod不存在或者移动到另外的节点上后,数据仍然会存在,直到被用户显式删除为止。在这种类型的卷里,数据通常存储在远程。

我们希望Kubernetes能够支持本地持久化存储,因为这将最适合运行数据库,但是同时,默认使用短暂的存储卷。这里,你可能会问为什么使用短暂存储而不是持久化存储呢?不用太惊讶,有很多原因:
  • 短暂存储比持久化存储更快更便宜。使用持久化存储对基础架构/网络要求更高,因为需要来回发送数据
  • Kubernetes 1.9开始支持Raw Block,让用户可以应用里访问物理磁盘。
  • 维护网络存储系统并不是必需的
  • 永远可以先首先尝试重启容器,而不是杀死整个Pod:kubectl exec POD_NAME -c CONTAINER_NAME reboot
  • 可以配置Couchbase来自动化复制数据,因此即使N个Pod都不存在了,数据也不会丢失
  • Kubernetes的部分工作是在不同的地方运行Pod从而避免大规模故障。


但是,有一些场景里值得使用远程持久化存储,即使会带来额外的延迟,比如大部分数据库,当rebalancing进程需要几分钟来完成的时候。这也正是为什么会支持远程持久化存储的原因。

Statefullset的一个缺点是受限的管理,这也是我们决定通过使用自定义资源定义(CRD)扩展Kubernetes API的原因,这让我们可以在Kubernetes上创建自定义的原生资源,就像StatefulSet或者Deployment一样,但是是为管理Counchbase实例而特别设计的。

太好了!使用StatefulSet/CRD我们处理好了所有硬件运维,这里还漏了一个“小”事情,应用程序本身的状态如何处理呢?比如,在数据库里,向集群里添加一个新节点很可能不够,你还需要触发一些进程,比如rebalancing进程来将一些数据移动/复制到新增节点上,从而让这个新节点真正起作用。这也正是Kubernetes Operator出场的原因。

Kubernetes Operator

Kubernetes 1.7增加了一个重要特性,称为自定义控制器。总的来说,它让开发人员可以扩展以及增加新功能,替换已有的功能(比如替换kuber-proxy),并且能够自动化管理任务,就像它们是原生的Kubernetes组件一样。

Operator就是一系列应用程序特定的自定义控制器。那么,为什么说它是游戏规则改变者呢?控制器能够直接访问Kubernetes API,这意味着它们可以监控集群,改变Pod/服务,扩容/缩容,以及调用运行着的应用程序的endpoint,所有这些都根据编写在这些控制器里的自定义规则来实现。

为了更好的解释它的行为,让我们看看当一个Pod被杀死时,Couchbase的Operator是如何工作的:
Picture1.png

正如上图所示,Operator监控并且分析集群,同时基于一系列参数,触发一系列行为来达到所需状态。这样的调和进程在Kubernetes里到处都是。但是并非所有行为都是平等的,在本文示例里,有两大主要类别:
  • 基础架构-添加新节点:Operator通过Kubernetes API请求启动一个运行Couchbase Server的新Pod。
  • 域特定 - 将节点添加到集群里/触发数据rebalancing:Operator知道Couchbase是如何工作的,调用正确的REST endpoint将新节点添加到集群里并且触发数据relalancing。


这就是Operator的真正能力,它们允许用户编写的应用程序能够完整管理其他应用程序,猜猜什么类型的有状态应用程序最难管理?对了,就是:数据库。

开发人员永远期望数据库能开箱即用,但是实际情况通常和期望恰恰相反。我们甚至还有专门负责管理数据库的特定职位,数据库管理员。

Couchbase的Operator致力于改变这样的场景,让数据库更易于管理,让用户无需锁定在特定的云供应商上。目前,它支持自动的集群预配,弹性伸缩,自动恢复,日志,并且提供Web控制台的访问,将来还会推出更多的特性。如果想了解更多,请看这篇文章或者查阅Couchbase的正式文档

我还需要说一下,这是针对数据库的第一个正式的Operator,还有一些小社区项目正在尝试为MySQL,Postrgres和其他数据库构建Operator。

Operator的生态系统正在迅速成长,比如rook,让用户可以部署非常类似于AWS S3的东西。Apache Kafka Operator即将推出,我们期待在接下来的几个月里出现更多的Operator,毕竟所有主流云供应商都已经支持Kubernetes了。

最后,Kubernetes提供了和云平台无关的应用程序部署和管理方式。它非常强大,可能会让云供应商变成某种日用品,因为用户将能够在云供应商之间随意迁移。

未来,对云供应商的选择可能就是去选择谁能够提供最佳的性能/花费而已。这种根本的改变会带来的市场影响目前还不是很明朗,但是作为开发人员来说,我们肯定是最大的赢家。

原文链接:Why Kubernetes Operators are a game changer(翻译:崔婧雯)
===========================
译者介绍
崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。

0 个评论

要回复文章请先登录注册