浅谈Kubernetes Operator模式的开发
前言 这篇博客是属于对《Kubernetes Operator 进阶开发》的初步章节一个笔记总结,作为 2023 第一篇博文,也作为重新深入梳理 K8s 的基础部分,往后会逐步将之前的坑给填上 Operator的基本概念 作为最入门的篇章,我们将从写一个 Demo 开始,在这里将默认已经存在了一个可用的集群环境,当然如果在开始学习之前,你能有一些 Client-Go 基础那就再好不过了 控制器模式 控制器模式在日常生活中的应用非常广泛,也是根据原书的例子进行举例,当然这里缩减了非常多,也加入了些个人的想法 夏天我们需要调整空调制冷,现在过程如下: 空调启动后设置一个温度,例如 25 度 空调检测室温,确定室温是否高于目标值 如果高于目标阈值,例如室温 27 度,则开始制冷操作 如果低于目标阈值,保持静默到下一个探测周期 这其实就是控制器模式典型的工作流程,外部输入一个 “期望值”,期间一个 “控制器” 不断按照 “周期” 观测 “环境状态” 的 “实际值” 和 “期望值” 之间的差异,然后不断调整两者,以便维持平衡,这个过程则被称为 “调谐” Kubernetes中的控制器与CRD Kubernetes 中通过 “声明式API” 定义了一系列的资源对象,然后通过许多的 Controllers 来 “调谐” 这些资源对象的实际状态以向期待状态靠拢,从而实现整个集群 “尽可能” 靠拢配置中声明的期望状态,注意 CRD (Custom Resource Definition)是 Kubernetes 提供的一种机制,允许用户定义新的资源类型,通过定义 CRD,你可以扩展 Kubernetes 的 API,创建和管理自定义资源(Custom Resource,CR),Controller 则是一个自定义的控制器程序,它监视并响应 Kubernetes 集群中的资源变化。对于自定义资源,Controller 用于实现资源的创建、更新和删除逻辑 还是上面空调的例子,我们可以定义一个新的资源类型 AirConditioner,它包含空调的目标温度和当前状态等信息,CR 是基于 CRD 实例化的具体资源。每个空调的具体配置实例就是一个 CR,其包含了目标温度和当前温度等具体值,同样给空调 A (my-airconditioner-A) 和空调 B (my-airconditioner-B) 分别创建了两个温度,每个温度集合的格式都需要符合 CRD 的声明,实例中 Controller 是用于监控 CR 并执行相应操作的程序,它负责监控 AirConditioner 资源,并根据当前温度和目标温度来决定是否启动制冷 ...