如何在 Kubernetes 上优雅的运行一个 MySQL 主从架构集群

一般情况下Kubernetes可以通过ReplicaSet以一个Pod模板创建多个Pod副本，但是它们都是无状态的，任何时候它们都可以被一个全新的Pod替换。然而有状态的Pod需要另外的方案确保当一个有状态的Pod挂掉后，这个Pod实例需要在别的节点上重建，但是新的实例必须与被替换的实例拥有相同的名称、网络标识和状态。这就是StatefulSet管理Pod的手段。

对于容器集群，有状态服务的挑战在于，通常集群中的任何节点都并非100%可靠的，服务所需的资源也会动态地更新改变。当节点由于故障或服务由于需要更多的资源而无法继续运行在原有节点上时，集群管理系统会为该服务重新分配一个新的运行位置，从而确保从整体上看，集群对外的服务不会中断。

若采用本地存储，当服务漂移后数据并不会随着服务转移到新的节点，重启服务就会出现数据丢失的困境。本文目的是通过一个MySQL的主从集群搭建，深入了解Kubernetes的StatfulSet管理。为了降低实验的外部依赖，存储层面上，我采用的是本地存储，当然生产上不建议这样做，生产环境的存储推荐官方介绍到的的GCE、NFS、Ceph等存储方案，因为这些方案支持动态供给的特性，允许开发人员通过PVC的定义，快速实现数据有效存储，所以你绝不应该把一个宿主机上的目录当作PV使用，只是本文用于实验需要，采用Local Persistent Volume的手段，目的只是为了验证StatefulSet的状态管理功能。

Kubernetes Master
Kubernetes Node （测试演示，所有的副本都会在其上运行）