Appearance
Operator 运维
Operator 是把某类系统的运维动作写成控制器。它通常通过 CRD 暴露“想要什么”,再由 controller 执行安装、配置、扩缩容、故障恢复、证书维护、备份恢复等动作。Prometheus Operator、cert-manager、Elastic Operator、Argo CD、Nginx Gateway Fabric 都属于这个方向。
Operator 降低的是重复操作成本,不会消除底层复杂度。Prometheus Operator 能管理 Prometheus 资源,但 PromQL、存储容量、采集基数、告警规则仍然需要理解;数据库 Operator 能创建集群,但备份、恢复和数据一致性仍然是运维重点。
一、Operator 的组成
一个 Operator 通常包含:
| 组成 | 说明 |
|---|---|
| CRD | 新增资源类型,比如 Prometheus、Certificate、Application |
| Controller | 监听资源变化并执行 reconcile |
| RBAC | 授权 controller 读取和修改相关资源 |
| Webhook | 做默认值、校验或转换,部分 Operator 才有 |
| 示例 CR | 创建具体实例的 YAML |
安装 Operator 后先确认这些对象:
bash
kubectl get crd | grep prometheus
kubectl get deploy -n monitoring
kubectl get sa,role,rolebinding,clusterrole,clusterrolebinding -n monitoringCRD 存在但 controller 不在,资源只会被 API Server 保存,不会被处理。
二、安装方式
Operator 常见安装方式:
| 方式 | 说明 |
|---|---|
| Helm Chart | 最常见,方便指定 values、版本和 namespace |
| 原生 YAML | 官方提供清单,适合简单安装或离线整理 |
| OLM | Operator Lifecycle Manager,偏平台化管理 |
| Argo CD | 从 Git 同步 Operator 和实例资源 |
以 Helm 安装为例:
bash
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
# kube-prometheus-stack 会安装 CRD、Operator、Prometheus、Alertmanager、Grafana 等资源
helm install kps prometheus-community/kube-prometheus-stack \
-n monitoring \
--create-namespace \
-f values.yaml这类 Chart 往往同时安装 Operator 和默认实例。升级前要看 Chart 版本、Operator 镜像版本、CRD 版本之间的关系。
三、实例资源和状态
Prometheus Operator 里的实例资源示例:
yaml
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: k8s
namespace: monitoring
spec:
replicas: 1
retention: 7d
serviceMonitorSelector:
matchLabels:
release: kps
resources:
requests:
cpu: 500m
memory: 2Gi查看状态:
bash
kubectl get prometheus -n monitoring
kubectl describe prometheus k8s -n monitoring
kubectl get pod -n monitoring -l app.kubernetes.io/name=prometheus -o wideOperator 创建出来的资源一般带有 ownerReference 和标签。排查时可以从自定义资源一路追到 StatefulSet、Pod、Service、Secret。
四、升级前检查
Operator 升级比普通 Deployment 更敏感,因为它管理的是一批资源和 CRD。
升级前至少确认:
| 检查项 | 说明 |
|---|---|
| CRD 变更 | 是否有字段废弃、版本升级、conversion webhook |
| 实例备份 | 自定义资源 YAML、values、相关 Secret |
| 控制器权限 | 新版本是否需要新增 RBAC |
| 数据目录 | Prometheus、数据库、存储类 Operator 是否涉及 PVC 数据 |
| 回滚路径 | 旧版本 Operator 是否能识别升级后的 CRD 和资源 |
备份自定义资源:
bash
kubectl get prometheus,servicemonitor,prometheusrule -A -o yaml > monitoring-cr-backup.yaml
helm get values kps -n monitoring > kps-values-backup.yamlCRD 不是普通业务配置。某些 CRD 一旦升级 storage version,回滚旧版本控制器可能无法识别新对象。
五、权限和安全
Operator 经常需要较高权限。比如监控 Operator 要 list/watch 多个 namespace 的 Service、Pod、Endpoints;证书 Operator 要读写 Secret;存储 Operator 可能要操作节点和卷。
查看权限:
bash
kubectl get clusterrole | grep operator
kubectl describe clusterrole <operator-clusterrole>
kubectl auth can-i list pods --as=system:serviceaccount:monitoring:prometheus-operator -A权限不足时,controller 日志里通常有 forbidden。这类问题不会在创建 CRD 时暴露,而是在控制器处理资源时出现。
六、常见故障
| 现象 | 常见原因 |
|---|---|
| 自定义资源创建成功但无变化 | controller 没运行、selector 不匹配、RBAC 不足 |
| controller CrashLoopBackOff | values 配置错误、webhook 证书错误、版本不兼容 |
| 资源卡 Terminating | finalizer 清理失败 |
| 升级后无法创建 CR | CRD schema 变化、字段废弃、webhook 异常 |
| Operator 管理的 Pod 反复重建 | controller 不断 reconcile,实际状态无法满足 spec |
排查顺序:
bash
kubectl get crd | grep <keyword>
kubectl get deploy,pod -n <operator-namespace>
kubectl logs deploy/<operator-deployment> -n <operator-namespace>
kubectl describe <custom-resource> <name> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestampOperator 的日志通常比业务 Pod 日志更关键。业务 Pod 只是被管理对象,真正说明“为什么改成这样”的信息在 controller 里。
七、运维记录
Operator 管理的系统要留几类记录:
| 记录 | 用途 |
|---|---|
| Chart 版本 / Operator 镜像版本 | 判断 CRD 和控制器兼容性 |
| CRD 版本 | 升级和回滚时定位风险 |
| values / 自定义资源 YAML | 恢复和迁移 |
| 关联 PVC / Secret | 数据和凭据恢复 |
| controller 日志关键错误 | 分析 reconcile 失败 |
平台组件越来越多后,Operator 本身也会成为运维对象。它既是自动化入口,也是故障入口。