Skip to content

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 monitoring

CRD 存在但 controller 不在,资源只会被 API Server 保存,不会被处理。

二、安装方式 ​

Operator 常见安装方式:

方式说明
Helm Chart最常见,方便指定 values、版本和 namespace
原生 YAML官方提供清单,适合简单安装或离线整理
OLMOperator 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 wide

Operator 创建出来的资源一般带有 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.yaml

CRD 不是普通业务配置。某些 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 CrashLoopBackOffvalues 配置错误、webhook 证书错误、版本不兼容
资源卡 Terminatingfinalizer 清理失败
升级后无法创建 CRCRD 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=.lastTimestamp

Operator 的日志通常比业务 Pod 日志更关键。业务 Pod 只是被管理对象,真正说明“为什么改成这样”的信息在 controller 里。

七、运维记录 ​

Operator 管理的系统要留几类记录:

记录用途
Chart 版本 / Operator 镜像版本判断 CRD 和控制器兼容性
CRD 版本升级和回滚时定位风险
values / 自定义资源 YAML恢复和迁移
关联 PVC / Secret数据和凭据恢复
controller 日志关键错误分析 reconcile 失败

平台组件越来越多后,Operator 本身也会成为运维对象。它既是自动化入口,也是故障入口。