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）。
它提供了三个关键特性：
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)
我们将使用业界最成熟
