Redis Operator 升到 0.26.0：哨兵打散与 Harbor 循环依赖

三个哨兵，为什么仍然不够#

原来的结构是三台 Kubernetes 节点、九个 RedisReplication。每套两个 Redis 数据 Pod，嵌套三个 Sentinel，quorum: "2"。

问题不在副本数量，而在它们落在哪里。升级前的 Pod 清单里，Harbor 那套哨兵分布类似这样：

如果 B 故障，一次就失去两个 Sentinel。quorum 用来判断主节点是否客观下线，真正发起故障转移还需要多数 Sentinel 授权；它不参与 Kubernetes 的节点选择。三个进程不等于三个故障域。Redis Sentinel 官方说明

检查配置时要分清两层：

• RedisReplication.spec 的调度字段作用于 Redis 数据 Pod。
• RedisReplication.spec.sentinel 的字段作用于这套实例的嵌套 Sentinel。

v0.24.0 的 CRD 已经有顶层调度字段，但嵌套 sentinel 没有 affinity、topologySpreadConstraints 等字段。旧备份和当时的 kubectl explain 都能确认这一点。直接把新字段写进旧 CR，不能指望它生效；根据提交方式和校验设置，未知字段可能被拒绝或裁剪。

上游 PR #1786 给嵌套 Sentinel 补上了调度字段，并把它们传到 StatefulSet 的 PodSpec；v0.26.0 发布说明包含这项变更。因此这次继续保留嵌套 Sentinel，升级 Operator 和 CRD，再把调度写回 CR。

直接编辑生成的 StatefulSet 不能作为长期配置：后续 reconcile 仍以 CR 为准。本次也没有启用 webhook，最终保持 webhook: false。

三节点上的取舍：哨兵打散，避开 Redis 用软约束#

三台机器上，每套两个数据 Pod、三个哨兵，不可能同时满足“哨兵每台一个”和“哨兵完全不与本套 Redis 同机”。

如果给哨兵配置硬反亲和，禁止它与本套 Redis 同机，两个 Redis 分别占住两台后，哨兵就只剩第三台可选。没有哨兵互斥规则时会集中到一台；再加严格打散规则，又可能使 Pod Pending。

本次采用下面这组规则：

下面是合并到原 RedisReplication 的 spec 片段。example-redis 要替换为自己的实例名；原有镜像、凭据引用、存储和 Redis 配置继续保留，不能拿这个片段替换完整 CR。

1
spec:
2
  clusterSize: 2
3
  topologySpreadConstraints:
4
    - maxSkew: 1
5
      topologyKey: kubernetes.io/hostname
6
      whenUnsatisfiable: DoNotSchedule
7
      labelSelector:
8
        matchLabels:
9
          app: example-redis
10
          role: replication
11
  pdb:
12
    enabled: true
13
    minAvailable: 1
14

15
  sentinel:
16
    size: 3
17
    quorum: "2"
18
    resources:
19
      requests:
20
        cpu: 50m
21
        memory: 64Mi
22
      limits:
23
        cpu: 200m
24
        memory: 128Mi
25
    topologySpreadConstraints:
26
      - maxSkew: 1
27
        topologyKey: kubernetes.io/hostname
28
        whenUnsatisfiable: DoNotSchedule
29
        labelSelector:
30
          matchLabels:
31
            app: example-redis-s
32
            role: sentinel
33
    affinity:
34
      podAntiAffinity:
35
        preferredDuringSchedulingIgnoredDuringExecution:
36
          - weight: 100
37
            podAffinityTerm:
38
              topologyKey: kubernetes.io/hostname
39
              labelSelector:
40
                matchLabels:
41
                  app: example-redis
42
                  role: replication

selector 必须对应 Operator 实际生成的 Pod 标签。这里同时使用实例的 app 和 role，避免把同一命名空间的其他 Redis 也算进来。

v0.26.0 的嵌套 Sentinel 仍没有 pdb 字段。所以数据面 PDB 交给 Operator，哨兵 PDB 单独保存为 sentinel-pdb.yaml：

1
apiVersion: policy/v1
2
kind: PodDisruptionBudget
3
metadata:
4
  name: example-redis-s
5
  namespace: example
6
spec:
7
  minAvailable: 2
8
  selector:
9
    matchLabels:
10
      app: example-redis-s
11
      role: sentinel

这里有两个需要保留的边界。

首先，maxSkew: 1 控制的是符合条件的拓扑域之间的数量偏差。本次三台节点可参与调度时，三个 Sentinel 最终是 1 / 1 / 1；配置没有设置 minDomains，不能据此承诺节点减少后仍一定每台最多一个。它也不会自动搬迁已经运行的 Pod，本次重新分布发生在模板变更后的滚动过程中。Kubernetes 拓扑打散说明

其次，PDB 约束的是 Eviction API，例如正常的 kubectl drain。它不能防止机器故障，也不会拦住 StatefulSet 控制器自身的滚动更新。因此“有 PDB”不能推出“这次升级不会影响业务”。Kubernetes Disruptions

第一次升级：Harbor 等 Redis，Redis 等 Harbor#

这套部署开启了 GenerateConfigInInitContainer=true。Redis 数据 Pod 里有一个 init-config 容器，使用的也是 Operator 镜像，但它的版本可以通过 redisOperator.initContainerImageTag 单独控制。

当晚 Helm 历史 manifest 展示了关键转折：

第一步已经分开了控制器和 init 的版本，但紧接着就更新了 init，尚未把新镜像在所有节点上的可用性处理好。init 镜像变化进入 Redis StatefulSet 的 Pod 模板，多套数据 Pod 随之滚动，其中包含 Harbor 自己的 Redis。

操作记录中的恢复阻塞链是：

1
更新 init-config 镜像 → 多套 Redis 开始滚动
2
                            ↓
3
                    Harbor 的 Redis 暂时不可用
4
                            ↓
5
                    Harbor core 连接失败，入口 503
6
                            ↓
7
                    待启动容器经 Harbor 拉镜像失败
8
                            ↓
9
                    Redis 恢复被镜像拉取挡住

Harbor 的 Redis 主容器原本就使用 quay.io/opstree/redis，但 init-config 仍使用 Harbor 代理地址。只检查业务容器的镜像来源，会漏掉这条启动依赖。控制器自身当时又是 Always，重建时也需要访问仓库。

Always 不表示每次都重新下载全部镜像层，但容器运行时仍需联系仓库解析镜像。仓库返回 503 时，已有缓存不一定能让它启动。IfNotPresent 才会在本地已有所需镜像时跳过拉取。Kubernetes 镜像拉取策略

随后几次 revision 尝试恢复旧 init、暂停控制器并预热镜像。02:27 决定全量撤回这轮变更，02:29:24 的 revision 8 明确记录为 Rollback to 2。

回退也不只有一条 helm rollback：旧 Chart、CRD 和实例配置一并恢复，新增调度字段、18 个 PDB 及预热资源被撤掉。Redis 再滚动后恢复，Harbor /v2/ 回到 401。这个回退恢复的是部署配置，不能把它等同于 Redis 持久数据恢复。

第二轮：把会引发滚动的变化拆开#

1
initContainerImageTag → imageTag → v + Chart.appVersion

1
replicas: 1
2
redisOperator:
3
  imageName: harbor.example.com/quay/opstree/redis-operator
4
  imageTag: ""
5
  initContainerImageTag: v0.24.0
6
  imagePullPolicy: IfNotPresent
7
  webhook: false
8
featureGates:
9
  GenerateConfigInInitContainer: true

1
for node in node-a node-b node-c; do
2
  ssh "$node" \
3
    'crictl pull harbor.example.com/quay/opstree/redis-operator:v0.26.0' \
4
    || exit 1
5
done

1
kubectl apply --server-side --force-conflicts \
2
  -f ./redis-operator/crds/crds.yaml
3

4
kubectl explain redisreplication.spec.sentinel.affinity
5
kubectl explain redisreplication.spec.sentinel.topologySpreadConstraints
6

7
helm upgrade redis-operator ./redis-operator \
8
  -n ot-operators \
9
  --reuse-values \
10
  --set replicas=1 \
11
  --set redisOperator.imagePullPolicy=IfNotPresent \
12
  --set redisOperator.initContainerImageTag=v0.24.0 \
13
  --wait --timeout 3m

1
kubectl apply \
2
  -f ./example/redis-replication.yaml \
3
  -f ./example/sentinel-pdb.yaml

1
helm upgrade redis-operator ./redis-operator \
2
  -n ot-operators \
3
  --reuse-values \
4
  --set redisOperator.initContainerImageTag=v0.26.0 \
5
  --set redisOperator.imagePullPolicy=IfNotPresent \
6
  --wait --timeout 3m

最后验收到了哪一层#

02:59 的只读复核结果如下：

复核时的核心只读命令可以保留：

1
helm history redis-operator -n ot-operators
2

3
kubectl get pods -A -l 'role in (replication,sentinel)' \
4
  -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,NODE:.spec.nodeName,PHASE:.status.phase,ROLE:.metadata.labels.redis-role'
5

6
kubectl get pdb -A
7

8
kubectl -n harbor get endpointslices \
9
  -l kubernetes.io/service-name=harbor-redis-master
10

11
curl -sS -o /dev/null -w '%{http_code}\n' \
12
  --connect-timeout 5 --max-time 10 \
13
  https://harbor.example.com/v2/

上面的 Pod 命令展示落点和 phase；Ready 还需要检查 Pod conditions 和容器状态。主从标签也只是 Operator 的观察结果，不能代替 Redis 协议层的复制状态检查。

这份记录没有据此宣称零停机、零数据丢失，也没有把它当成九套业务的完整回归、主动故障转移测试或数据恢复演练。短暂 503 在第二轮仍然发生，只是恢复没有再次卡在镜像获取上。

还留下了一条启动依赖#

最终镜像来源没有统一改成同一个仓库：

因此这次完成的是：用预拉缓存和拉取策略，让这轮维护在 Harbor 短暂不可用时仍能继续恢复。Harbor Redis 的 init 仍依赖 Harbor 镜像引用，循环依赖没有从架构上完全消失。 新增节点、缓存被回收或下一次换 tag 时，还需要重新核对所有启动镜像，包括 init 容器和 sidecar。

这次升级解决了最初那个具体问题：嵌套 Sentinel 的调度终于能由 CR 声明，并在本次三节点环境中按预期打散；数据面也补上了分布约束，维护驱逐有了 PDB，哨兵有了资源声明。

升级顺序则留下了另一条经验：控制器版本、init 镜像和业务 Pod 模板是不同的变更面。先确认恢复时需要的镜像在哪里，再决定哪一步允许业务滚动，才能避免把自己的镜像仓库一起困在恢复路径里。