Adam Chow's Life Journals

Appearance

在云原生的世界里，Kubernetes (K8s) 已成为容器编排的事实标准。它在管理无状态应用方面表现出色，但当我们面对数据库、消息队列、监控系统等复杂的有状态应用时，挑战便接踵而至。部署仅仅是第一步，“第二天运维”（Day-2 Operations）——如升级、备份、恢复、扩缩容——才是真正考验我们的地方。

这时候，Kubernetes Operator 模式闪亮登场。它不仅是管理复杂应用的最佳实践，更是将运维工作自动化、规模化、并融入 K8s 生态的“终极武器”。

本文将带你深入理解 Operator 的核心思想，并通过一个实际案例，让你亲手体验它的强大之处。

一、Why：为何我们需要 Operator？ ​

想象一下，你是一位负责在 K8s 上维护一个高可用 PostgreSQL 数据库集群的运维工程师。

最初的部署可能很简单： 你用一个 StatefulSet 来保证 Pod 的稳定运行，用 PersistentVolume 来存储数据，用 Service 来暴露访问端点。这看起来很美好。

但很快，你就陷入了繁琐的“第二天运维”泥潭：

  1. 扩容：业务增长，需要增加一个只读副本。你不能简单地增加 StatefulSet 的 replicas。你需要手动进入主库，配置流复制，然后在新 Pod 上启动备库并指向主库。整个过程涉及多个手动步骤和配置更改。
  2. 故障恢复：主库 Pod 所在的节点宕机了。K8s 会在别的节点上重新拉起这个 Pod，但 PostgreSQL 集群本身并不知道需要进行主备切换。你需要手动介入，将一个备库提升为新的主库，并修改其他备库的复制源，同时还要更新 Service 指向新的主库。
  3. 版本升级：需要将 PostgreSQL 从 13 版本升级到 14 版本。这是一个高风险操作，需要精细的滚动升级策略：先升级一个备库，验证数据一致性，再进行主备切换，然后升级旧的主库…… 每一步都不能出错。
  4. 备份与恢复：你需要定期执行 pg_dump 或 pg_basebackup，并将备份文件安全地存储到对象存储中。当需要恢复时，又是一系列复杂的手动流程。

这些操作繁琐、易错、且严重依赖资深工程师的“祖传”脚本和经验。这显然不符合 Kubernetes 提倡的声明式、自动化的理念。我们希望像管理 Pod 一样，通过一个简单的 YAML 文件来描述我们期望的状态（比如“我需要一个3节点的、版本为14的、每天自动备份的PostgreSQL集群”），然后让系统自动完成所有工作。

这就是 Operator 诞生的原因：将人类运维专家的知识和经验，编码成一个在 K8s 集群中持续运行的、自动化的软件。

二、What：Operator 究竟是什么？ ​

从概念上讲，Operator = 自定义资源 (CRD) + 自定义控制器 (Controller)。

让我们拆解这两个核心组件：

1. 自定义资源 (Custom Resource Definition, CRD) ​

CRD 是 K8s API 的一种扩展机制。它允许我们创建新的、自定义的资源类型，就像 K8s 内置的 Pod、Deployment、Service 一样。

对于上面的 PostgreSQL 案例，我们可以创建一个名为 PostgresCluster 的新资源。这个资源可以有自己的 spec 字段，用来描述我们期望的数据库集群状态：

yaml
apiVersion: "db.example.com/v1alpha1"
kind: "PostgresCluster"
metadata:
  name: "my-production-db"
spec:
  version: "14.5"
  instances: 3
  storage: "100Gi"
  backup:
    schedule: "0 2 * * *" # 每天凌晨2点备份
    storageLocation: "s3://my-backup-bucket/postgres"

看到这个 YAML，你是不是觉得运维工作瞬间清晰简单了？我们不再关心底层的 StatefulSet、ConfigMap 或 PVC，而是直接与一个代表“数据库集群”的高级抽象进行交互。

2. 自定义控制器 (Custom Controller) ​

有了新的资源类型 PostgresCluster，谁来理解它并执行相应的操作呢？这就是自定义控制器的职责。

控制器是一个在 K8s 集群中运行的程序（通常是一个 Pod），它遵循 K8s 标志性的**调和循环（Reconciliation Loop）**模式：

  1. Observe (观察)：控制器通过 K8s API Server 持续“监听” PostgresCluster 这种资源的变化。比如，用户创建、更新或删除了一个 PostgresCluster 对象。
  2. Analyze (分析)：控制器获取到 PostgresCluster 对象的期望状态（Desired State，即 spec 字段中的内容），并检查集群中与该对象相关的当前状态（Current State，例如实际运行的 Pod 数量、数据库版本等）。
  3. Act (行动)：比较期望状态和当前状态的差异，并采取行动来弥合这个差异。
    • 差异：期望 instances: 3，但当前只有 2 个 Pod。行动：创建一个新的 Pod，并配置好主从复制。
    • 差异：期望 version: "14.5"，但当前 Pod 运行的是 13.8。行动：执行一个安全的滚动升级流程。
    • 差异：一个数据库 Pod 意外挂了。行动：K8s 会重启 Pod，而 Operator 会检查集群健康状况，必要时执行主备切换。

这个 Observe -> Analyze -> Act 的循环会永不停止地运行，确保真实世界的系统状态始终与用户在 CRD 中定义的期望状态保持一致。

总结一下： Operator 将复杂的应用生命周期管理逻辑封装在一个控制器中，并通过 CRD 提供了一个简单、声明式的 API 接口给用户。它让管理复杂应用变得像管理 K8s 原生资源一样简单。

三、How：如何实践？——以 Etcd Operator 为例 ​

光说不练假把式。让我们通过一个经典的 etcd-operator 案例，亲身体验 Operator 的魔力。Etcd 是 K8s 自身的元数据存储，管理它同样涉及集群搭建、扩容、灾备等复杂操作。

前提条件： 你需要一个可用的 K8s 集群（例如 Minikube, Kind）。

第1步：安装 Etcd Operator ​

Operator 本身也是一个 K8s 应用，我们首先需要将它部署到集群中。这通常是通过应用一个 YAML 文件来完成，该文件包含了 Operator 的 Deployment、RBAC 权限以及它所管理的 CRD 定义。

bash
# 从官方仓库应用 Operator 的部署文件
kubectl apply -f https://raw.githubusercontent.com/coreos/etcd-operator/master/deploy/deployment.yaml

执行后，你可以检查 Operator 是否成功运行：

bash
kubectl get pods -n default | grep etcd-operator
# 你应该能看到一个名为 etcd-operator-xxxxxxxxxx-xxxxx 的 Pod 正在运行

同时，EtcdCluster 这个 CRD 也被创建了。我们可以用以下命令查看：

bash
kubectl get crd | grep etcd
# 输出应包含 etcdclusters.etcd.database.coreos.com

第2步：创建一个3节点的 Etcd 集群 ​

现在，我们可以像创建 Pod 一样，通过一个 YAML 文件来定义我们想要的 Etcd 集群。

创建一个名为 etcd-cluster.yaml 的文件：

yaml
apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
  name: "my-etcd-cluster"
spec:
  size: 3 # 我们想要一个3节点的集群
  version: "3.2.13" # 指定 etcd 版本

应用这个文件，向 K8s 声明我们的“意图”：

bash
kubectl apply -f etcd-cluster.yaml

第3步：见证奇迹的时刻 ​

Etcd Operator 在后台已经观察到了这个新的 EtcdCluster 资源。现在，它会自动开始工作：

bash
# 持续观察 Pod 的创建过程
watch kubectl get pods -l etcd_cluster=my-etcd-cluster

# 你会看到，etcd-operator 正在逐个创建3个 Pod
# NAME                      READY   STATUS    RESTARTS   AGE
# my-etcd-cluster-xxxxxxx1   1/1     Running   0          2m
# my-etcd-cluster-xxxxxxx2   1/1     Running   0          90s
# my-etcd-cluster-xxxxxxx3   1/1     Running   0          30s

无需任何手动干预，一个3节点的 Etcd 集群就搭建好了！

第4步：体验自动化运维 - 扩容 ​

现在，我们想把集群从3个节点扩展到5个。我们不需要登录任何机器，只需要修改我们最初的“意图”文件。

将 etcd-cluster.yaml 中的 size 字段从 3 改为 5：

yaml
apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
  name: "my-etcd-cluster"
spec:
  size: 5 # <-- 修改这里
  version: "3.2.13"

再次应用这个文件：

bash
kubectl apply -f etcd-cluster.yaml

再次观察 Pod：

bash
watch kubectl get pods -l etcd_cluster=my-etcd-cluster

你会惊喜地发现，Operator 自动创建了2个新的 Etcd Pod，并将它们加入了现有集群。这就是声明式 API 的威力！

第5步：体验自动化运维 - 故障自愈 ​

现在，我们来模拟一次故障。手动删除其中一个 Pod：

bash
# 随机删除一个 etcd pod
kubectl delete pod $(kubectl get pods -l etcd_cluster=my-etcd-cluster -o jsonpath='{.items[0].metadata.name}')

Operator 的调和循环会立刻检测到当前状态（只有4个Pod）与期望状态（需要5个Pod）不符。于是，它会立即采取行动：

bash
watch kubectl get pods -l etcd_cluster=my-etcd-cluster

你会看到，被删除的 Pod 很快被一个新的 Pod 替代，集群规模自动恢复到5个节点。这就是 Operator 带来的强大自愈能力。

如何构建自己的 Operator？ ​

如果你想为自己的应用构建一个 Operator，社区也提供了成熟的工具，最主流的是：

  • Operator SDK: 由 Red Hat 推出，功能全面，支持 Go, Ansible, Helm 多种方式开发。
  • Kubebuilder: Google 的项目，更专注于 Go 语言，是构建 Operator 的上游基础。

开发流程大致如下：

  1. 使用工具初始化项目骨架。
  2. 定义 CRD 的 API 结构（在 Go 代码中定义）。
  3. 在控制器的 Reconcile 函数中，实现你的核心运维逻辑（对比期望状态和当前状态，并执行操作）。
  4. 构建 Operator 镜像并部署到集群。

结论 ​

Kubernetes Operator 不仅仅是一个工具或技术，它是一种思想的转变。它将复杂的应用管理，从命令式的、手动的过程，转变为声明式的、自动化的、云原生的方式。

通过将领域专家的运维知识固化为代码，Operator 实现了：

  • 自动化：将 Day-2 运维操作（如升级、备份、故障恢复）自动化，减少人为错误。
  • 可靠性：通过持续的调和循环，确保应用始终处于健康和期望的状态。
  • K8s 原生体验：让复杂应用像 K8s 内置资源一样易于管理和消费。

下一次，当你准备在 K8s 上部署一个有状态服务时，不妨先去 OperatorHub.io 寻找一下是否已经有现成的 Operator。如果没有，也许就是你大展身手，为你的应用构建一个专属“运维专家”的时候了。