探针 on Liangweidong's blog

K8s 资源限制与健康探针：limits / requests / livenessProbe / readinessProbe

Tue, 15 Mar 2022 00:00:00 +0800

写于 2022-03，背景：K8s 1.23 GA，1.24 即将引入对 dockershim 移除。本文聚焦"Pod 资源调优"——关闭 swap、CPU/内存单位、requests/limits 区别、3 类探针最佳实践。

一、为什么 K8s 强制关 swap

K8s 安装文档里第一条永远是"关闭 swap"，很多人不知道为什么。根本原因是 Kubelet 设计哲学：

在计算集群中，我们希望 OOM 时直接杀进程，报错让运维处理，故障转移到其他节点重启。而不是用 swap 续命，导致节点 hang 住，集群性能大幅下降，运维还收不到报警。

机械盘 swap 更糟：swap 写磁盘，性能掉到个位数；机器卡死，连 SSH 都登不进去，结局就是硬重启。

类型	是否需要 swap	原因
计算集群（批处理、Spark、Flink）	不需要	OOM 立即杀，故障转移
服务型集群（MySQL、K8s、Redis）	不需要	性能稳定，OOM 即报警
个人开发机	保留	内存偶尔不够，swap 救命

swapoff -a + /etc/fstab 注释 swap 行，双保险：

1
2
3


free -m
swapoff -a
sed -ri 's/.*swap.*/#&/' /etc/fstab

iptables 不用关（K8s 自己用 iables 做 Service 转发），但 firewalld / ufw 建议关，避免端口冲突。

二、CPU / 内存单位

2.1 CPU 单位

1
2
3
4
5
6
7


resources:
 requests:
 cpu: 2000m  # 2000 毫核 = 2 核
 memory: 512Mi
 limits:
 cpu: 2000m
 memory: 512Mi

CPU 后缀：

m：毫核（millicores），1 Core = 1000m
数字（不带 m）：直接写核数（cpu: 2 = 2 Core = 2000m）

CPU 是可压缩资源：

超过 limits → 容器被节流（throttled），不是杀掉
requests = 调度保证（这台节点上至少有这么多 CPU 可用）

2.2 内存单位

单位	进制	例子
K / M / G / T / P / E	1000	`500M` = 500 × 1000 字节
Ki / Mi / Gi / Ti / Pi / Ei	1024	`512Mi` = 512 × 1024 × 1024 字节

内存是不可压缩资源：

超过 limits → 容器被 OOMKilled（Exit Code 137）

三、requests vs limits

字段	含义	作用
`requests`	调度的"最低保证"	调度器看节点剩余资源够不够 requests
`limits`	容器能用的"上限"	CPU 节流 / 内存 OOM

Java 应用特殊坑：

JVM 默认堆内存 = 物理内存的 1/4
Pod memory.limits: 1Gi 时，JVM 堆可能只分到 256MB
必须显式设 -Xmx / -Xms

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


env:
- name: JAVA_OPTS
 value: "-Xms512m -Xmx512m"
resources:
 requests:
 memory: 1Gi  # 给 JVM 堆 + 堆外 + native + OS
 cpu: 500m
 limits:
 memory: 1Gi
 cpu: 1000m

四、QoS 等级

K8s 根据 requests/limits 设置给 Pod 打 3 个 QoS 等级：

QoS 等级	特征	驱逐顺序
Guaranteed	requests == limits（CPU 和 memory 都设了）	最后被驱逐
Burstable	requests < limits	中间
BestEffort	requests 和 limits 都没设	最先被驱逐（节点压力时）

生产建议：

核心服务用 Guaranteed（不设 requests = BestEffort，节点紧张第一个杀）
普通服务用 Burstable（设 requests，不设 limits 或 limits 更大）
批处理可用 BestEffort（节点紧张先死批处理是合理的）

五、3 类探针

K8s 有 3 类探针，每类都有 3 种检测方式：

探针	检测目标	失败后果
`livenessProbe`	容器是否存活	kubelet 重启容器
`readinessProbe`	容器是否就绪	从 Service Endpoints 移除
`startupProbe`	容器是否启动完成	阻断 liveness / readiness

3 种检测方式：

httpGet：HTTP GET 请求（最常用）
tcpSocket：TCP 端口
exec：执行命令

5.1 livenessProbe：活人检测

作用：容器是不是死了？死了 kubelet 重启它。

关键参数：

initialDelaySeconds：第一次探测前等多久（启动慢的应用要加大）
periodSeconds：探测间隔
timeoutSeconds：单次探测超时
failureThreshold：连续失败几次标记失败
successThreshold：连续成功几次标记成功（liveness 必须是 1）

1
2
3
4
5
6
7
8
9


livenessProbe:
 httpGet:
 path: /actuator/health/liveness
 port: management-port
 initialDelaySeconds: 900 # 15 分钟
 periodSeconds: 30
 timeoutSeconds: 10
 successThreshold: 1
 failureThreshold: 3 # 连续失败 3 次重启

为什么 initialDelaySeconds 要大？ JVM 启动慢，启动 5~10 分钟常见。如果 initialDelaySeconds = 60，JVM 还没启动完就被杀了，反复重启。

5.2 readinessProbe：就绪检测

作用：容器是不是能接流量了？没就绪就从 Service Endpoints 摘掉。

1
2
3
4
5
6
7
8
9


readinessProbe:
 httpGet:
 path: /actuator/health/readiness
 port: management-port
 initialDelaySeconds: 600 # 10 分钟
 periodSeconds: 20
 timeoutSeconds: 5
 successThreshold: 1
 failureThreshold: 5 # 连续失败 5 次摘流量

liveness 与 readiness 的区别：

liveness 是"是不是活着"（死 → 重启）
readiness 是"是不是能干活"（不能 → 摘流量，不重启）

典型场景：

启动期间：readiness 失败 → 流量不来，但容器继续启动
运行时下游 DB 挂：readiness 失败 → 摘流量，但容器不重启
应用死锁：liveness 失败 → 重启容器

5.3 startupProbe：启动检测（K8s 1.16+）

作用：慢启动应用（如 Java）需要更长探测时间，用 startupProbe 替代 liveness 的 initialDelaySeconds。

1
2
3
4
5
6
7
8


startupProbe:
 httpGet:
 path: /actuator/health
 port: management-port
 failureThreshold: 30 # 最多失败 30 次
 periodSeconds: 10 # 每 10 秒探一次
# 总允许启动时间 = 30 * 10 = 300 秒（5 分钟）
# startupProbe 成功前，liveness 和 readiness 都不启用

好处：不用猜 initialDelaySeconds 该设多久。

5.4 Spring Boot 完整示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55


apiVersion: apps/v1
kind: Deployment
metadata:
 name: springboot-app
spec:
 replicas: 3
 selector:
 matchLabels:
 app: springboot-app
 template:
 metadata:
 labels:
 app: springboot-app
 spec:
 containers:
 - name: app
 image: my-app:1.0
 ports:
 - containerPort: 8080
 - name: management
 containerPort: 8081
 env:
 - name: JAVA_OPTS
 value: "-Xms512m -Xmx512m -XX:+UseG1GC"
 - name: SPRING_PROFILES_ACTIVE
 value: "prod"
 resources:
 requests:
 cpu: 500m
 memory: 1Gi
 limits:
 cpu: 1000m
 memory: 1Gi
 startupProbe:
 httpGet:
 path: /actuator/health
 port: management
 failureThreshold: 30
 periodSeconds: 10
 readinessProbe:
 httpGet:
 path: /actuator/health/readiness
 port: management
 periodSeconds: 20
 timeoutSeconds: 5
 successThreshold: 1
 failureThreshold: 5
 livenessProbe:
 httpGet:
 path: /actuator/health/liveness
 port: management
 periodSeconds: 30
 timeoutSeconds: 10
 successThreshold: 1
 failureThreshold: 3

六、Node 资源预留

K8s 节点本身要跑 kubelet、kube-proxy、containerd 等系统进程，需要预留资源：

1
2
3
4


# kubelet 启动参数
--kube-reserved=cpu=500m,memory=1Gi
--system-reserved=cpu=500m,memory=1Gi
--eviction-hard=memory.available<500Mi,nodefs.available<10%

作用：保留资源给系统，避免 Pod 把节点搞崩。

驱逐条件（eviction-hard）：

memory.available < 500Mi：驱逐 BestEffort → Burstable
nodefs.available < 10%：磁盘满了开始杀 Pod
imagefs.available < 15%：镜像存储满了

七、LimitRange 与 ResourceQuota

7.1 LimitRange：namespace 默认值

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


apiVersion: v1
kind: LimitRange
metadata:
 name: default
 namespace: dev
spec:
 limits:
 - type: Container
 default: # limits 默认值
 cpu: 500m
 memory: 512Mi
 defaultRequest: # requests 默认值
 cpu: 200m
 memory: 256Mi
 max: # 上限
 cpu: 2000m
 memory: 2Gi

不设 requests/limits 的 Pod 会用 defaultRequest 和 default 兜底。

7.2 ResourceQuota：namespace 总配额

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


apiVersion: v1
kind: ResourceQuota
metadata:
 name: dev-quota
 namespace: dev
spec:
 hard:
 requests.cpu: "10"
 requests.memory: 20Gi
 limits.cpu: "20"
 limits.memory: 40Gi
 pods: "100"
 services: "50"
 configmaps: "50"
 secrets: "50"
 persistentvolumeclaims: "20"

超过配额就拒绝创建新资源。

八、Pod 调度与资源

8.1 资源不够 Pod 怎么调度失败

1
2
3
4
5
6


# Pod Pending 状态
kubectl describe pod <pod>
# Events:
# Warning FailedScheduling ... 0/5 nodes are available:
# 3 node(s) didn't match Pod's node affinity/selector.
# 2 node(s) didn't have enough free cpu.

解决：

加节点
减小 requests
用 HPA 自动扩

8.2 Pod 资源使用率监控

1
2
3
4
5
6
7


# 实时（依赖 metrics-server）
kubectl top pod -A --sort-by=memory | head -10
kubectl top pod -A --sort-by=cpu | head -10

# 历史（用 Prometheus）
container_cpu_usage_seconds_total
container_memory_working_set_bytes

九、常见坑

Java 没设 -Xmx：JVM 堆自动算 = 物理内存 / 4，1Gi limit 时只分到 256MB，应用反复 OOM
liveness initialDelaySeconds 太短：慢启动应用被反复杀
liveness 检测太严格：临时 GC pause 30 秒就触发重启
readiness 失败后没流量：Spring Boot /actuator/health/readiness 没启用或路径写错
requests/limits 单位错：500 不是 500m，是 500 核（不可能）
BestEffort 服务被先杀：核心服务忘设 requests

十、生产清单

检查项	推荐值
requests.requests.memory	Java 1Gi 起，Go 256Mi 起
limits.requests.memory	requests 的 1.5~2 倍
limits.requests.cpu	requests 的 1.5~2 倍（突发流量）
liveness failureThreshold	3
readiness failureThreshold	5
startupProbe periodSeconds × failureThreshold	> JVM 启动时间
JVM 启动慢应用	必加 startupProbe
节点 kube-reserved	cpu=500m, memory=1Gi
节点 eviction-hard	memory.available<500Mi

十一、前置知识 / 下一步

前置：

Pod 基础概念（参考 2017-06-15《Kubernetes 入门》）
Deployment 配置

下一步：

Kubeadm 一键部署（2022-06-15）—— 生产部署实战
K8s 集群插件（2021-09-15）—— CNI/CoreDNS/Metrics/Dashboard

参考资料

K8s 实战：Deployment/StatefulSet/DaemonSet 区别 + 探针 + hostNetwork

Thu, 15 Aug 2019 00:00:00 +0800

K8s 三种核心控制器

K8s 应用的"控制器"决定了 Pod 的行为模式。生产环境用错控制器，轻则"Pod 不断重启"，重则"数据全丢"。

1. Deployment：无状态

1.1 原理

Deployment 通过 ReplicaSet 管 Pod 副本——保证"指定数量的 Pod 副本在运行"，Pod 之间无差别。

适用场景：

Web 服务（nginx / Spring Boot）
API 服务
微服务（无状态）
任何"可以随时被 kill + 重建"的应用

1.2 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-deployment
spec:
 replicas: 3
 selector:
 matchLabels:
 app: my-app
 template:
 metadata:
 labels:
 app: my-app
 spec:
 containers:
 - name: my-container
 image: nginx:latest
 ports:
 - containerPort: 80

2. StatefulSet：有状态

2.1 原理

StatefulSet 给每个 Pod 分配：

稳定的网络标识：my-sts-0、my-sts-1、my-sts-2
稳定的持久存储：每个 Pod 绑定独立 PVC
有序部署 / 扩容 / 缩容：my-sts-0 先 Ready，my-sts-1 才创建

适用场景：

数据库（MySQL、MongoDB、PostgreSQL）
消息队列（Kafka、RabbitMQ 集群模式）
分布式存储节点
任何"必须有持久身份"的应用

2.2 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: my-statefulset
spec:
 replicas: 3
 serviceName: my-service
 selector:
 matchLabels:
 app: my-app
 template:
 metadata:
 labels:
 app: my-app
 spec:
 containers:
 - name: my-container
 image: nginx:latest
 ports:
 - containerPort: 80
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: [ReadWriteOnce]
 resources:
 requests:
 storage: 10Gi

2.3 关键：serviceName 必填

StatefulSet 必须有 serviceName（Headless Service 的名字），K8s 通过这个 Service 给每个 Pod 生成 DNS 记录：

1
2


my-sts-0.my-service.default.svc.cluster.local
my-sts-1.my-service.default.svc.cluster.local

3. DaemonSet：节点守护

3.1 原理

DaemonSet 在每个 Node 上都跑一个 Pod 副本。新节点加入集群 → 自动创建 Pod；节点删除 → 自动清理。

适用场景：

日志收集（Promtail / Filebeat / Fluentd）
节点监控（node-exporter / cadvisor）
网络组件（calico-node / flannel / cilium）
存储守护进程

3.2 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: my-daemonset
spec:
 selector:
 matchLabels:
 app: my-app
 template:
 metadata:
 labels:
 app: my-app
 spec:
 containers:
 - name: my-container
 image: nginx:latest
 ports:
 - containerPort: 80

DaemonSet 不关心 replicas 数量，只关心"每个节点都有"。

3.3 节点选择器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


spec:
 template:
 spec:
 nodeSelector:
 node-role: worker  # 只在打了这个标签的节点跑
 tolerations:
 - key: dedicated
 operator: Equal
 value: ceph
 effect: NoSchedule  # 能容忍 NoSchedule 污点

4. 三者对比

维度	Deployment	StatefulSet	DaemonSet
副本数	任意	任意	节点数
Pod 名称	随机	有序稳定	稳定
存储	共享 PVC	独立 PVC	hostPath / 共享
扩缩容	无序	有序	自动跟随节点
滚动更新	任意	有序	任意
删除	一起删	有序删	节点没了才删
适用	Web / API	DB / 消息队列	监控 / 日志 / 网络

5. 健康探针（Probe）

5.1 3 种探针

探针	作用	失败后果
livenessProbe	容器是否"活着"	重启容器
readinessProbe	容器是否"准备好接流量"	从 Service Endpoints 移除
startupProbe	启动是否完成	慢启动场景，避免 liveness 过早失败

5.2 Spring Boot 应用示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


spec:
 containers:
 - name: springboot-app
 image: my-app:1.0
 ports:
 - name: http
 containerPort: 8080
 - name: management
 containerPort: 9090
 livenessProbe:
 httpGet:
 path: /actuator/health/liveness
 port: management
 initialDelaySeconds: 180 # 启动后等 3 分钟
 periodSeconds: 10
 timeoutSeconds: 1
 successThreshold: 1
 failureThreshold: 6 # 连续失败 6 次才重启
 readinessProbe:
 httpGet:
 path: /actuator/health/readiness
 port: management
 initialDelaySeconds: 180
 periodSeconds: 10
 timeoutSeconds: 5
 successThreshold: 1
 failureThreshold: 9 # 连续失败 9 次才下线

坑：initialDelaySeconds 设太短（如 10s）会导致慢启动应用被频繁重启；设太长（>10min）会拖慢故障恢复。

5.3 tcpSocket 探针

1
2
3
4
5


livenessProbe:
 tcpSocket:
 port: 8080
 initialDelaySeconds: 30
 periodSeconds: 10

5.4 exec 探针

1
2
3
4
5
6
7


livenessProbe:
 exec:
 command:
 - cat
 - /tmp/healthy
 initialDelaySeconds: 5
 periodSeconds: 5

6. hostNetwork 调度

6.1 为什么用

有些场景 Pod 必须用宿主网络命名空间：

Ingress-nginx（DaemonSet + hostNetwork 监听 80/443）
监控 agent（采集宿主机 metrics）
端口被固定需要"独占"某端口

6.2 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


apiVersion: apps/v1
kind: Deployment
metadata:
 name: safety-powerjob-worker
 namespace: test
spec:
 replicas: 1
 template:
 metadata:
 labels:
 app: safety-powerjob-worker
 spec:
 hostNetwork: true
 hostAliases:
 - ip: 10.100.99.252
 hostnames: ["extend-service.test"]
 affinity:
 podAntiAffinity:
 preferredDuringSchedulingIgnoredDuringExecution:
 - weight: 100
 podAffinityTerm:
 labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values: [safety-powerjob-worker]
 topologyKey: "kubernetes.io/hostname"
 containers:
 - name: safety-powerjob-worker
 image: my-app:latest

6.3 关键风险

端口冲突：hostNetwork 模式下 Pod 直接占用宿主机端口。如果 2 个 Pod 调度到同一节点都想占用 8080 → 后启动的 CrashLoopBackOff。

症状：

1
2


kubectl describe pod <pod>
# Events: ... failed to bind port 8080

解决：

DaemonSet + hostAntiAffinity（推荐）
用 DaemonSet 而不是 Deployment（每节点最多 1 个）
指定 nodeName 强制单节点

6.4 实战：hostNetwork + 端口冲突排查

1
2


journalctl -u kubelet | grep "<pod-name>"
# 看到 "port already in use"

常见原因：calico-kube-controllers 用了 hostNetwork，端口被其他 Pod 抢占。

7. 节点亲和与反亲和

7.1 软亲和 / 反亲和（preferred）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


affinity:
 podAntiAffinity:
 preferredDuringSchedulingIgnoredDuringExecution:
 - weight: 100
 podAffinityTerm:
 labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values: [my-app]
 topologyKey: "kubernetes.io/hostname"

软约束：尽量不调度到一起，但不保证。生产用得最多。

7.2 硬亲和 / 反亲和（required）

1
2
3
4
5
6
7
8
9


affinity:
 podAntiAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 - labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values: [my-app]
 topologyKey: "kubernetes.io/hostname"

硬约束：必须不调度到一起，调度不到就 Pending。

7.3 节点亲和（nodeAffinity）

1
2
3
4
5
6
7
8


affinity:
 nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms:
 - matchExpressions:
 - key: dedicated
 operator: In
 values: [ml]

把 Pod 调度到打了 dedicated=ml 标签的节点（专用机器学习节点）。

8. 节点选择与污点容忍

1
2
3
4
5
6
7
8


spec:
 nodeSelector:
 disktype: ssd
 tolerations:
 - key: dedicated
 operator: Equal
 value: ml
 effect: NoSchedule

nodeSelector 选节点，tolerations 容忍污点。

9. 实战：Spring Boot 微服务完整 yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77


apiVersion: apps/v1
kind: Deployment
metadata:
 name: user-service
 labels:
 app: user-service
spec:
 replicas: 3
 strategy:
 type: RollingUpdate
 rollingUpdate:
 maxSurge: 1
 maxUnavailable: 0
 selector:
 matchLabels:
 app: user-service
 template:
 metadata:
 labels:
 app: user-service
 spec:
 affinity:
 podAntiAffinity:
 preferredDuringSchedulingIgnoredDuringExecution:
 - weight: 100
 podAffinityTerm:
 labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values: [user-service]
 topologyKey: "kubernetes.io/hostname"
 containers:
 - name: user-service
 image: my-harbor.example.com/base/user-service:v1.2.3
 ports:
 - name: http
 containerPort: 8080
 env:
 - name: SPRING_PROFILES_ACTIVE
 value: prod
 - name: NACOS_SERVER
 value: nacos.example.com:8848
 resources:
 requests:
 cpu: 500m
 memory: 512Mi
 limits:
 cpu: 2000m
 memory: 2048Mi
 livenessProbe:
 httpGet:
 path: /actuator/health/liveness
 port: 8080
 initialDelaySeconds: 120
 periodSeconds: 10
 readinessProbe:
 httpGet:
 path: /actuator/health/readiness
 port: 8080
 initialDelaySeconds: 60
 periodSeconds: 5
 imagePullSecrets:
 - name: harbor-secret
---
apiVersion: v1
kind: Service
metadata:
 name: user-service
spec:
 selector:
 app: user-service
 ports:
 - port: 80
 targetPort: 8080
 name: http
 type: ClusterIP

10. 常见问题

10.1 Deployment 一直 RestartCount 增长

livenessProbe 失败 → kubelet 重启容器。检查：

1
2
3


kubectl describe pod <pod>
# Events: ... Liveness probe failed
kubectl logs <pod> --previous

10.2 StatefulSet 扩容后 Pod 一直 Pending

PVC 创建失败。检查：

1
2
3


kubectl get pvc -n <ns>
kubectl describe pvc <pvc-name>
# FailedBinding：节点不满足 storage class 标签

10.3 DaemonSet 一些节点没 Pod

1
2
3
4


kubectl describe daemonset <name>
# 看 Desired / Current / Ready / Available
kubectl get nodes --show-labels
# 节点有 nodeSelector 标签吗？

10.4 hostNetwork 端口冲突

1
2


journalctl -u kubelet -n 50 --no-pager
# 看到 "address already in use"

10.5 Pod 调度到 taint 节点失败

1
2


kubectl describe pod <pod>
# Events: ... 0/3 nodes are available: 3 node(s) had taint {dedicated: ceph}, that the pod didn't tolerate.

加 tolerations 或换节点。

11. 小结

K8s 控制器三件套是部署应用的"基本功"：

Deployment 是默认选择（无状态）
StatefulSet 用于有状态（必须有 serviceName）
DaemonSet 用于节点级守护
Probe + hostNetwork + Affinity 是高级调度三件套
RollingUpdate strategy 控制滚动更新节奏

下一步（其他批次的双机房双集群 / Redis Cluster 6 节点架构实践）。