上一篇【第73篇】Helm——K8s的“包管理器“从此告别复制粘贴YAML的地狱下一篇【第75篇】Prometheus和Grafana——K8s监控体系搭建完全指南摘要上篇讲了Helm——它把部署应用标准化了。但部署只是开始真正的麻烦在运维MySQL主从怎么自动故障切换Redis哨兵挂了怎么自动重建ETCD集群怎么滚动升级不丢数据备份怎么定时做这些领域专家知识Helm表达不了——它是静态模板不懂应用的运行时逻辑。这就需要Operator模式用CRD定义我想要一个什么样的MySQL集群用自定义控制器把DBA的运维经验写进代码让K8s自动照料这个应用的一生。这篇文章讲清Operator的本质、Operator Framework三件套并用Kubebuilder演示写一个Redis Operator的思路。一、Operator的本质1.1 CRD Controller【Operator CRD (我要啥) Controller (你怎么实现)】 回忆第072篇的CRD: • CRD 只定义MysqlCluster长什么样 • 创建了存etcd但没人实现它 Operator补上实现那部分: • 一个自定义控制器(Controller) • 盯着MysqlCluster资源 • 把领域专家知识写成代码: - 创建StatefulSet Headless Service - 初始化主从复制 - 监控主节点健康 - 主挂了 → 选新主 → 重配从节点 - 定时备份 - 滚动升级不停服要点Operator的核心思想是把人类专家的运维经验代码化。一个资深DBA知道MySQL主从怎么搭、怎么切换、怎么备份——Operator就是把这些知识写成一个永远在线的控制器。它让部署运维全自动化用户只需声明我要一个3节点的MySQL 8.0集群剩下的K8s自己搞定。二、Operator Framework三件套2.1 官方工具链【Operator Framework (CNCF项目)】 ┌──────────────────────────────────────────┐ │ 1. Operator SDK │ │ • 脚手架工具快速生成代码骨架 │ │ • 支持 Go / Ansible / Helm 三种语言写 │ │ • 一条命令生成CRDController模板 │ └──────────────────────────────────────────┘ ┌──────────────────────────────────────────┐ │ 2. Operator Lifecycle Manager (OLM) │ │ • 管理Operator的安装/升级/依赖 │ │ • 像Operator的应用商店 │ │ • 处理Operator自身的版本迭代 │ └──────────────────────────────────────────┘ ┌──────────────────────────────────────────┐ │ 3. OperatorHub │ │ • 公开 registry找现成Operator │ │ • Redis/MySQL/ETCD/Prometheus...都有 │ │ • 大部分场景不用自己写直接用现成 │ └──────────────────────────────────────────┘组件作用类比Operator SDK写Operator的工具脚手架OLM管Operator生命周期包管理器OperatorHub找现成Operator应用商店三、实战用Kubebuilder写Redis Operator3.1 脚手架# 1. 初始化项目kubebuilder init--domainexample.com--repogithub.com/me/redis-operator# 生成: main.go, Dockerfile, Makefile, config/ ...# 2. 创建API (CRD Controller骨架)kubebuilder create api--groupcache--versionv1--kindRedisCluster# 生成: api/v1/rediscluster_types.go (CRD Go定义)# controllers/rediscluster_controller.go (控制器骨架)# 3. 在 types.go 里定义Spec/Status# RedisClusterSpec:# replicas: 3# version: 7.0# storage: 10Gi# RedisClusterStatus:# phase: Running / Failed# readyReplicas: 33.2 控制器逻辑伪代码// controllers/rediscluster_controller.gofunc(r*RedisClusterReconciler)Reconcile(ctx,req){// 1. 拿到用户声明的RedisClustervarrc RedisCluster r.Get(ctx,req.NamespacedName,rc)// 2. 确保StatefulSet存在(3个Redis节点)if!statefulSetExists(rc){createStatefulSet(rc)// 用Headless Service(第022篇)}// 3. 确保主从复制配置ensureReplication(rc)// 选主、配从// 4. 监控健康ifmasterDown(rc){electNewMaster(rc)// 自动故障切换!reconfigureSlaves(rc)}// 5. 更新statusrc.Status.ReadyReplicascountReady(rc)r.Status().Update(ctx,rc)// 6. 定期requeue(持续监控)returnctrl.Result{RequeueAfter:30*time.Second},nil}# 部署后用户只需一句话kubectl apply-f-EOF apiVersion: cache.example.com/v1 kind: RedisCluster metadata: name: my-redis spec: replicas: 3 version: 7.0 storage: 10Gi EOF# Operator自动: 起3节点StatefulSet、配主从、监控、故障切换要点Kubebuilder生成的骨架已经把Informer/WorkQueue/Reconcile那套第063篇搭好了你只需填空在Reconcile里写让实际状态靠拢期望状态的逻辑。这就是标准的控制器模式——只不过管的是你自己的CRD。你写的Operator跑在集群里永远在线、永远对账把DBA的活自动化了。四、Operator vs Helm4.1 定位不同【Helm 管部署 vs Operator 管运维】 Helm: • 静态模板 → 渲染 → apply • 部署完就不管了 • 适合: 无状态/标准化应用(nginx/web) • 不懂应用的运行时逻辑 Operator: • 常驻控制器 → 持续监视 → 自动调谐 • 部署完一直在管 • 适合: 复杂有状态应用(数据库/中间件) • 把运维专家知识代码化 配合: 很多Operator用Helm打包分发自己!维度HelmOperator运行一次性(渲染部署)常驻(持续调谐)智能无(静态)有(含逻辑)适合无状态应用有状态/复杂应用编写难度低(YAML)高(Go代码)五、什么时候该写Operator【决策树】 你要部署的是? │ ├─ 标准无状态应用(web/nginx) │ → Helm 足够(别过度设计) │ ├─ 复杂有状态应用(MySQL/Redis/ETCD) │ ├─ 社区有现成Operator? │ │ → 直接用(OperatorHub上找) │ │ │ └─ 没有现成的 / 特别定制? │ → 自己写Operator │ └─ 只是部署简单配置? → Helm(别为简单需求写Operator)本篇小结OperatorCRD自定义控制器把人类运维专家的领域知识代码化让K8s自动照料复杂有状态应用的一生部署、主从、故障切换、备份、升级。Operator Framework提供SDK脚手架、OLM生命周期管理、OperatorHub现成仓库。用Kubebuilder写Operator时骨架已搭好Informer/Reconcile你只需在Reconcile里写对齐逻辑。Operator管运维、Helm管部署定位互补很多Operator还用Helm打包自己。决策口诀标准无状态用Helm复杂有状态先找现成Operator没有再自己写。下篇讲监控——PrometheusGrafana。上一篇【第73篇】Helm——K8s的“包管理器“从此告别复制粘贴YAML的地狱下一篇【第75篇】Prometheus和Grafana——K8s监控体系搭建完全指南