StatefulSet 更适合 MySQL，因其提供稳定网络标识、有序启停、PV 自动绑定；需配合 Headless Service，InitContainer 初始化主从，CSI 存储保障 I/O，租约机制防脑裂。
StatefulSet 为什么比 Deployment 更适合 MySQL
MySQL 是有状态服务，实例间存在主从关系、数据一致性要求和网络标识依赖，Deployment 的无序扩缩容和 Pod 名随机性会直接破坏集群稳定性。StatefulSet 提供稳定的网络标识（mysql-0.mysql-headless.default.svc.cluster.local）、有序部署/滚动更新、以及与 PV 的自动绑定能力——这是实现高可用的底层前提。
关键点：
- 必须配合 Headless Service（
clusterIP: None）使用，否则无法通过 DNS 解析到具体 Pod 的稳定域名 - 每个 Pod 按序启动（
mysql-0→mysql-1），便于初始化主节点并让从节点按序加入复制 - Pod 删除后重建，仍挂载原 PV，避免数据丢失；而 Deployment + PVC 会因标签选择器不匹配导致新 Pod 绑定失败
动态 PV 需要满足哪些存储特性
MySQL 对存储的 I/O 延迟、随机读写吞吐和持久性极其敏感。动态供给的 PV 必须由支持 ReadWriteOnce 且具备真实块存储语义的插件提供，比如 hostPath 仅用于测试，nfs-client 不推荐用于生产——它不保证 fsync 落盘，容易导致 binlog 或 InnoDB redo 日志损坏。
实操建议：
- 生产环境优先用 CSI 驱动：如
aws-ebs-csi-driver（AWS）、gce-pd-csi-driver（GCP）、或本地集群的longhorn.io/openebs.io - StorageClass 中必须设置
volumeBindingMode: WaitForFirstConsumer，确保调度器先选定 Node，再创建 PV，避免跨节点挂载失败 - PVC 的
accessModes只能是ReadWriteOnce，且resources.requests.storage建议显式指定（如20Gi），防止底层存储池超售
如何用 InitContainer 初始化主从拓扑
StatefulSet 自身不处理 MySQL 实例间的角色协调。你需要靠 InitContainer 在容器启动前完成身份识别、配置生成和主节点就绪等待——否则多个 Pod 同时尝试写入同一数据目录，或从节点在主节点未启动时就开始连接，都会导致崩溃。
典型做法：
- InitContainer 运行脚本，检查当前 Pod 序号：
hostname为mysql-0则设为 master，其余为 slave - 向 ConfigMap 挂载的模板生成
/etc/mysql/conf.d/replication.cnf，包含server-id、read_only=1等差异化配置 - 用
nc -z mysql-0.mysql-headless 3306轮询等待主节点 mysqld 就绪（注意加 timeout 和重试，避免卡死） - 主节点需提前初始化数据目录并启动 mysqld，从节点首次启动时执行
CHANGE MASTER TO ...（建议封装进主容器 entrypoint）
常见脑裂与数据不一致怎么防
MySQL 主从在 K8s 网络分区下极易出现双主写入，尤其当 StatefulSet 控制器误判 Pod 失联并重建 mysql-0 时——旧主可能仍在运行，新主已接管流量，造成数据分裂。
必须叠加外部控制机制：
- 禁用自动故障转移：不要依赖
mysql-operator类工具的“自动选主”，它缺乏对网络分区的准确判断 - 引入分布式锁：用 etcd 或 Consul 实现主节点租约（lease），所有写请求必须先获取锁；可借助
orchestrator或patroni（需额外部署） - 监控关键指标：持续检查
SHOW SLAVE STATUS\G中的Seconds_Behind_Master、Slave_IO_Running和Slave_SQL_Running，告警值不能只看 0 - 备份策略不可少：即使高可用，也得每天全量 + binlog 增量，否则某次误操作或逻辑错误仍会导致不可逆丢失
真正难的不是部署三个 Pod，而是让它们在节点宕机、网络抖动、滚动更新时始终维持单一写入点和线性一致的复制流。这需要存储层、调度层、数据库自身和运维脚本四者严丝合缝，漏掉任意一环，高可用就变成高风险。
