Kubernets存储之StatefulSet控制器

一、简介

使用StatefulSet 控制器可以去运行一个有状态的应用程序
PV和PVC的设计，使得StatefulSet对存储状态的管理成为了可能:
• Pod的创建也是严格按照编号顺序进行的。比如在web-0进入到running状态，并且Conditions为Ready之前，web-1一直会处于pending状态。
StatefulSet还会为每一个Pod分配并创建一个同样编号的PVC。这样，kubernetes就可以通过Persistent Volume机制为这个PVC绑定对应的PV，从而保证每一个Pod都拥有一个独立的Volume。

二、一个简单的例子

创建无头服务

创建StatefulSet控制器
由上图可以得知，StatefulSet控制器创建的pod是有顺序和编号的，通过编号使得每个pod具有唯一的网络标识
StatefulSet将应用状态抽象成了两种情况：
拓扑状态：应用实例必须按照某种顺序启动。新创建的Pod必须和原来Pod的网络标识一样
存储状态：应用的多个实例分别绑定了不同存储数据。
StatefulSet给所有的Pod进行了编号，编号规则是：statefulset名称-序号，从0开始。Pod被删除后重建，重建Pod的网络标识也不会改变,Pod的拓扑状态按照Pod的“名字+编号”的方式固定下来,并且为每个Pod提供了一个固定且唯一的访问入口,即Pod对应的DNS记录。
回收pod时将副本数改为0，不是直接delete，这样就会从控制器走并且倒着删除
在控制器中加上存储，会为每一个pod提供唯一的存储
每创建一个pod就会有一个pvc

访问域名可以实现负载均衡
当回收pod时，pvc不会删除，当重建pod后，pvc中的内容和pod又会重新绑定

三、一主多从的 MySQL 集群

ConfigMap
这个 ConfigMap 提供 my.cnf 覆盖，使您可以独立控制 MySQL 主服务器和从服务器的配置。 在这种情况下，您希望主服务器能够将复制日志提供给从服务器，并且希望从服务器拒绝任何不是通过复制进行的写操作。

ConfigMap 本身没有什么特别之处，它可以使不同部分应用于不同的 Pod。 每个 Pod 都会决定在初始化时要看基于 StatefulSet 控制器提供的信息。

Services
Headless Service 给 StatefulSet 控制器为集合中每个 Pod 创建的 DNS 条目提供了一个宿主。因为 Headless Service 名为 mysql，所以可以通过在同一 Kubernetes 集群和 namespace 中的任何其他 Pod 内解析 <pod-name>.mysql 来访问 Pod。

客户端 Service 称为 mysql-read，是一种常规 Service，具有其自己的群集 IP，该群集 IP 在报告为就绪的所有MySQL Pod 中分配连接。可能端点的集合包括 MySQL 主节点和所有从节点。

请注意，只有读取查询才能使用负载平衡的客户端 Service。因为只有一个 MySQL 主服务器，所以客户端应直接连接到 MySQL 主服务器 Pod (通过其在 Headless Service 中的 DNS 条目)以执行写入操作。

StatefulSet

mysql中从节点从master节点copy数据是一个重要的问题，我们用xtrabackup打开3307端口来传输数据
mysql容器和xtrabackup在同一个pod内，相当于访问了同样的存储，


slave节点copy数据成功

slave端也会打开一个xtrabackup，下一个slave节点是从前一个slave节点复制数据的
在master节点上创建databases
从节点上可以看到创建的databases