k8s集群部署mysql mgr 集群？

记住有一点，以后不管mysql，oracle，hadoop全家桶，这一类的都是有状态服务，通常来说，kubernetes管理无状态到有状态的服务经历过漫长的时间，也迭代了好多的功能组件，部署mysqlmgr其实也是kubernetes管理有状态服务的一种方式。
最适合的是参考这篇文章，kubernetes对有状态的服务进行部署和管理，https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/?spm=a2c4e.10696291.0.0.1db919a4JQ5S4s
回到题主的问题，我们进行了简单的提炼。
Deployment、ReplicationController是为无状态服务而设计的，它们中 pod 的名称、主机名、存储都是不稳定的，且 pod 的启动、销毁顺序随机，并不适合数据库这样的有状态应用。为此，k8s 推出了面向有状态服务的工作负载StatefulSet。其管理的 pod 具有如下特点：
1、唯一性 - 对于包含 N 个副本的 StatefulSet，每个 pod 会被分配一个 [0，N)范围内的唯一序号。
2、顺序性 - StatefulSet 中 pod 的启动、更新、销毁默认都是按顺序进行的。
3、稳定的网络身份标识 - pod 的主机名、DNS 地址不会随着 pod 被重新调度而发生变化。
4、稳定的持久化存储 - 当 pod 被重新调度后，仍然能挂载原有的 PersistentVolume，保证了数据的完整性和一致性。
除了 StatefulSet 之外，还需要使用许多其它类型的 k8s 资源对象，包括 ConfigMap 、 Headless Service、 ClusterIP Service等。正是它们间的相互配合，才能让 MySQL 这样的有状态服务有条件运行在 k8s 之上。

ConfigMap

为了便于维护应用配置，大型系统和分布式应用常常采用集中式的配置管理策略。在 k8s 环境下，用户可以通过 ConfigMap 将配置和 pod 分离，这有助于保持工作负载的可移植性，使其配置更易于更改和管理。
样例包含一个名为mysql的 ConfigMap，当 StatefulSet 中的 pod 启动时，会根据自己的角色从 ConfigMap 中读取合适的配置。

Headless Service

Headless Service 会为关联的每一个 pod 提供对应的 DNS 地址，格式为.。这样，客户端就可以自由地选择想要访问的应用实例，同时也能够解决分布式环境下不同实例之间身份识别的问题。
样例包含一个名为mysql的 Headless Service，该 service 与 StatefulSet 中的 pod 相关联，这些 pod 将被分配如下 DNS 地址mysql-0.mysql、mysql-1.mysql、mysql-2.mysql。这样，客户端就可以通过mysql-0.mysql访问 master 节点，通过mysql-1.mysql或mysql-2.mysql访问 slave 节点。

ClusterIP Service

为了方便只读场景下的访问，样例提供了一个名为mysql-read的普通 service。该 service 拥有自己的 cluster IP，并会将请求分发至关联的 pod（包括 master 和 slave），为用户屏蔽 pod 的访问细节。

StatefulSet

StatefulSet 是服务部署的关键，它管理的每个 pod 会被分配一个唯一的名称，格式为-。样例中的 StatefulSet 名为mysql，因此这些 pod 分别被命名为mysql-0，mysql-1和mysql-2。默认情况下，它们会按顺序创建，并按逆序销毁。
如下图所示，一个 pod 包含 2 个 init container 和 2 个 app container，并且通过唯一的 PersistentVolumeClaim 和存储卷供应方提供的 PersistentVolume 绑定。