来了解一下 k8s 的 Operator 模式

最新推荐文章于 2024-06-12 08:56:36 发布

ChaITSimpleLove

最新推荐文章于 2024-06-12 08:56:36 发布

阅读量4.9k

点赞数 1

分类专栏： Kubernetes & 容器化资源编排管理文章标签： kubernetes Operator DevOps 容器化运维云原生

原文链接：https://blog.csdn.net/kevin_tech/article/details/113362038

版权

Kubernetes & 容器化资源编排管理专栏收录该内容

27 篇文章 10 订阅

订阅专栏

前面的文章介绍了 Kubernetes 自带的管理有状态应用的控制器 StatefulSet ，它能够完成应用的拓扑顺序状态管理（比如，重启时按照顺序重建 Pod）以及结合 PVC 完成应用的存储状态管理。不过在 Kubernetes 生态中还有一种更灵活、编程友好的解决方案 – Operator，它能让使用者根据自己应用的特性定义应用对象和管理对象的控制器。

在这里插入图片描述

这篇文章都是一些概念性的文字描述，阅读起来比较轻松，后面会再专门写怎么编码自己实现一个 Operator。

什么是 Operator ?

Operator 模式是 Kubernetes 的扩展软件，它利用 定制资源 管理应用及其组件。 Operator 遵循 Kubernetes 的理念，特别是在 控制器 方面。

Operator 概念是由 CoreOS 的工程师于 2016 年提出的，它让工程师可以根据应用独有的领域逻辑为应用编写自定义的控制器。这句话说的有点虚空，我们通过一个简单的例子理解一下 Operator 。

假设有一个连接数据库的 .NET Web 程序。你想将其部署到您的 k8s 集群。理想情况下，你会希望用 Deployment 部署应用然后暴露给 Service，对于应用服务的后端则是使用 StatuflSet 部署数据库。所以需要完成两部分的部署才能把整个应用服务部署完成：

无状态部分：.NET Web 应用。
有状态部分：数据库。

在上面的例子中，我们可以应用我们对应用程序与数据库之间的关系的了解，创建一个控制器，该控制器将以某种特定方式运行时执行某些操作。比如备份、更新、数据还原这些任务该如何完成取决于应用程序本身和业务限制（领域知识）。这些与应用强相关的操作就是 Kubernetes Operator 要做的：代替原本需要由 SRE（Site Reliability Engineers）和 Ops（运维工程师）来完成操作的执行。

自定义资源和控制器

Operator 模型基于 Kubernetes 中的两个概念结合而成：自定义资源和自定义控制器。

自定义资源

在 Kubernetes 中，资源是 Kubernetes API 中的一个端点，用于存储一堆特定类型的 API 对象。它允许我们通过向集群添加更多种类的对象来扩展 Kubernetes。添加新种类的对象之后，我们可以像其他任何内置对象一样，使用 kubectl 来访问我们自定义的 API 对象。

以 Pod 或 Deployment 为例。编写清单时，必须在 YAML 文件中指定一种类型（是 Pod 还是 Deployment）。自定义资源就是不由 Kubernetes 原生提供的资源对象。

自定义控制器

Kubernetes 的所有控制器，都有一个控制循环，负责监控集群中特定资源的更改，并确保特定资源在集群里的当前状态与控制器自身定义的期望状态保持一致。

举例来说有一个 Deployment 控制器管控值集群里的一组 Pod，当你 Kill 掉一个 Pod。控制器发现定义中期望的 Pod 数量与当前的数量不匹配，它就会马上创建一个 Pod 让当前状态与期望状态匹配。控制器这种让关联资源的当前状态向期望状态迈进的过程叫做 调谐（reconcile）。

那么，像 Deployment 这样的内置控制器也叫做 Operator 吗？其实不是，因为这些控制器不是特定于特定的应用程序的，而是内置类型资源的上游控制器。