Operator工作原理 - Operator原理与实践 - 入门 - 含官方翻译中文文档 - Operator好处？含webhook概念

yuezhilangniao

已于 2024-02-07 16:21:00 修改

阅读量433

点赞数 1

分类专栏： k8s-docker-service-mesh go语言文章标签： kubernetes java docker

于 2023-02-08 17:51:59 首次发布

原文链接：https://blog.csdn.net/u014229282/article/details/109294829

版权

k8s-docker-service-mesh 同时被 2 个专栏收录

138 篇文章 9 订阅

订阅专栏

go语言

4 篇文章 0 订阅

订阅专栏

一简单理解

推荐阅读1：https://developer.aliyun.com/article/798703

我们将 CRD, Controller, Webhook 三者合起来叫 Operator。一个 Operator 工程一般必须包含 CRD 和 Controller，Admission 是可选的。如果说 Kubernetes 是 "操作系统" 的话，Operator 是 Kubernetes 的第一层应用，它部署在 Kubernetes 里，使用 Kubernetes "扩展资源" 接口的方式向更上层用户提供服务。

阅读2：webhook简而言之，它可以认为是拦截器，类似web框架中的middleware。

基于 kubebuilder 的 operators 的 webhook 设计&二次开发_thingsboard 二次开发 webhook-CSDN博客

阅读3：webhook实践：Operator 开发实践四（WebHook）_operator-sdk 开发 admisson-webhook-CSDN博客

# 阅读4：https://zhuanlan.zhihu.com/p/404764407

https://www.cnblogs.com/wangguishe/p/17606485.html

Kubernetes 项目中的大部分编排对象（比如 Deployment、StatefulSet、DaemonSet，以及 Job），“有状态应用”的管理方法， Kubernetes 添加自定义 API 对象和编写自定义控制器。

可能你已经感觉到，在 Kubernetes 中，管理“有状态应用”是一个比较复杂的过程，尤其是编写 Pod 模板的时候，总有一种“在 YAML 文件里编程序”的感觉，让人很不舒服。

而在 Kubernetes 生态中，还有一个相对更加灵活和编程友好的管理“有状态应用”的解决方案，它就是：Operator。
————————————————
版权声明：本文为CSDN博主「Zeb-D」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u014229282/article/details/109294829

二翻译官方文档

https://www.bookstack.cn/read/kubernetes-1.23-zh/83e827d61b58b652.mdhttps://www.bookstack.cn/read/kubernetes-1.23-zh/83e827d61b58b652.md

初衷

Operator 模式旨在捕获（正在管理一个或一组服务的）运维人员的关键目标。负责特定应用和 service 的运维人员，在系统应该如何运行、如何部署以及出现问题时如何处理等方面有深入的了解。

在 Kubernetes 上运行工作负载的人们都喜欢通过自动化来处理重复的任务。 Operator 模式会封装你编写的（Kubernetes 本身提供功能以外的）任务自动化代码。

Kubernetes 上的 Operator

Kubernetes 为自动化而生。无需任何修改，你即可以从 Kubernetes 核心中获得许多内置的自动化功能。你可以使用 Kubernetes 自动化部署和运行工作负载，甚至可以自动化 Kubernetes 自身。

Kubernetes 的 Operator 模式概念允许你在不修改 Kubernetes 自身代码的情况下，通过为一个或多个自定义资源关联控制器来扩展集群的能力。 Operator 是 Kubernetes API 的客户端，充当自定义资源的控制器。

Operator 示例

使用 Operator 可以自动化的事情包括：

按需部署应用
获取/还原应用状态的备份
处理应用代码的升级以及相关改动。例如，数据库 schema 或额外的配置设置
发布一个 service，要求不支持 Kubernetes API 的应用也能发现它
模拟整个或部分集群中的故障以测试其稳定性
在没有内部成员选举程序的情况下，为分布式应用选择首领角色

想要更详细的了解 Operator？下面是一个示例：

有一个名为 SampleDB 的自定义资源，你可以将其配置到集群中。
一个包含 Operator 控制器部分的 Deployment，用来确保 Pod 处于运行状态。
Operator 代码的容器镜像。
控制器代码，负责查询控制平面以找出已配置的 SampleDB 资源。
Operator 的核心是告诉 API 服务器，如何使现实与代码里配置的资源匹配。
如果添加新的 SampleDB，Operator 将设置 PersistentVolumeClaims 以提供持久化的数据库存储，设置 StatefulSet 以运行 SampleDB，并设置 Job 来处理初始配置。
如果你删除它，Operator 将建立快照，然后确保 StatefulSet 和 Volume 已被删除。
Operator 也可以管理常规数据库的备份。对于每个 SampleDB 资源，Operator 会确定何时创建（可以连接到数据库并进行备份的）Pod。这些 Pod 将依赖于 ConfigMap 和/或具有数据库连接详细信息和凭据的 Secret。
由于 Operator 旨在为其管理的资源提供强大的自动化功能，因此它还需要一些额外的支持性代码。在这个示例中，代码将检查数据库是否正运行在旧版本上，如果是，则创建 Job 对象为你升级数据库。