浅谈Kubernetes Operator模式的开发 [draft]
前言 这篇博客是属于对《Kubernetes Operator 进阶开发》的初步章节一个笔记总结,作为 2023 第一篇博文,也作为重新深入梳理 K8s 的基础,往后会逐步将之前的坑给填上 Operator的基本概念 作为最入门的篇章,我们将从写一个 Demo 开始,在这里将默认已经存在了一个可用的集群环境,当然如果在开始学习之前,你能有一些 Client-Go 基础那就再好不过了 控制器模式 控制器模式在日常生活中的应用非常广泛,也是根据原书的例子进行举例,当然这里缩减了非常多,也加入了些个人的想法 夏天我们需要调整空调制冷,现在过程如下: 空调启动后设置一个温度,例如 25 度 空调检测室温,确定室温是否高于目标值 如果高于目标阈值,例如室温 27 度,则开始制冷操作 如果低于目标阈值,保持静默到下一个探测周期 这其实就是控制器模式典型的工作流程,外部输入一个 “期望值”,期间一个 “控制器” 不断按照 “周期” 观测 “环境状态” 的 “实际值” 和 “期望值” 之间的差异,然后不断调整两者,以便维持平衡,这个过程则被称为 “调谐” Kubernetes中的控制器 Kubernetes 中通过 “声明式API” 定义了一系列的资源对象,然后通过许多的 Controllers 来 “调谐” 这些资源对象的实际状态以向期待状态靠拢,从而实现整个集群 “尽可能” 靠拢配置中声明的期望状态 一个Deployment的创建 我们都知道集群中有个组件,叫做 Kube-Controller-Manager,这个组件就是一系列控制器的集合,现在可以重新梳理一下这个面试中经常被问到的问题了 在编辑好一个 Deployment YAML 配置文件并使用 Kubectl 提交后,这个资源声明就被传递给了 Kube-ApiServer,接着 Kube-Controller-Manager 中的 Deployment 控制器监听到了消息,注意 K8s 中的组件传递原则 — 是上层组件先将自身置于被修改后的状态,即先假设资源已经被创建,而下层组件监听到了上游变化后,将自身或者环境状态 “调谐” 为上游一致,在这里 Deployment Controller 根据 Spec 字段的定义创建对应的 ReplicaSet 资源,而 RS Controller 监听到了 RS 的变化,并也根据 Spec 字段中声明创建了 Pod,这里其实还有一个 Kubelet 的环节在中间,只是这里被我们抽象掉了...