2.4 中间件实战：MySQL、Kafka、Redis 在 K8s 上的高可用部署方案
1. 引言：K8s 的“阿喀琉斯之踵”
Kubernetes 最初是为无状态应用（Stateless App）设计的。Nginx 挂了？随便重启一个就行。
但对于有状态应用（Stateful App），如数据库、消息队列，事情就变得复杂了：
- 数据持久化：Pod 挂了，数据不能丢。
- 网络标识：主从切换时，Slave 必须知道 Master 是谁（不能只是随机 IP）。
- 启动顺序：MySQL 从节点不能比主节点先启动。
虽然云厂商提供了托管的 RDS/Redis，但在私有云或成本敏感的场景下，我们依然需要在 K8s 上自建中间件。
本节将带你挑战 K8s 运维的“深水区”，实战 MySQL、Redis 和 Kafka 的高可用部署。
2. 理论基石：StatefulSet 与 Operator
在部署之前，必须掌握两个核心概念。
2.1 StatefulSet：有状态应用的守护神
Deployment认为所有的 Pod 都是一样的（cattle）。StatefulSet认为每个 Pod 都是独一无二的（pet）。
它提供了三个关键特性：
- 稳定的网络 ID：Pod 名固定为
mysql-0,mysql-1。 - 有序部署/扩容：先启动
mysql-0，这就绪了才启动mysql-1。 - 稳定的存储：
mysql-0永远挂载pvc-0，即使它漂移到了别的节点。
2.2 Operator：把运维专家的智慧代码化
部署一个 MySQL 集群不仅是启动 Pod，还包括：
- 生成
my.cnf配置文件。 - 启动后初始化 Master/Slave 复制关系。
- 监控主节点健康，故障时执行 Failover。
- 定期备份。
StatefulSet只能管“启动”，管不了“运维”。
Operator模式出现了。它是一个自定义的 Controller，专门负责管理复杂的有状态应用。它把人的经验写成了代码。
3. 实战一：Redis 高可用 (Sentinel vs Cluster)
在 K8s 上部署 Redis，通常有两种架构：哨兵模式 (Sentinel)和集群模式 (Cluster)。
3.1 方案选型
- Sentinel: 适合数据量较小（< 20GB），读多写少。架构简单（1 Master + N Slaves）。
- Cluster: 适合海量数据，高并发写。数据分片（Sharding）。
3.2 部署实战 (Bitnami Helm Chart)
我们将使用业界最成熟
