如何在 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 (测试演示,所有的副本都会在其上运行) Kubernetes DNS服务已开启1实验目的
搭建一个主从复制(Master-Slave)的MySQL集群 从节点可以水平扩展 所有的写操作只能在MySQL主节点上执行 读操作可以在MySQL主从节点上执行 从节点能同步主节点的数据2本地存储原理
为了快速搭建测试环境,我们这里使用了本地存储,也就是说,用户希望Kubernetes能够直接使用宿主机上的本地磁盘目录,而不依赖于远程存储服务,来提供持久化的容器Volume。不过这里有个难点:
我们把存储固定在一个节点上,但是Pod在调度的时候,是飘来飘去的,怎么能让Pod通过PVC也能固定在PVC上? 给这个Pod加上一个nodeAffinity行不行?当然行,但是这变相破坏了开发人员对资源对象的定义规范了,开发人员应该不需要时刻考虑调度的细节。调度的改动应该交给运维就行。所以我们为了实现本地存储,我们采用了延迟绑定的方法。方法很简单,我们都知道StorageClass一般由运维人员设计,我们只需要在StorageClass指定no-provisioner。这是因为Local Persistent Volume目前尚不支持Dynamic Provisioning,所以它没办法在用户创建PVC的时候,就自动创建出对应的PV。与此同时,这个StorageClass还定义了一个volumeBindingMode=WaitForFirstConsumer的属性。它是Local Persistent Volume里一个非常重要的特性,即:延迟绑定。
StorageClass
apiVersion: storage.k8s.io/v1
metadata: name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer1.2.3.4.5.6.3实验步骤
创建PV
先在Node (实验用的Node节点IP是node1)节点上,预先分配几个PV(不建议在生产上这样操作),要保证在node1上有对应的目录
复制ssh root@node1
mkdir -pv /data/svr/projects/{mysql,mysql2,mysql3}1.2.v1
kind:PersistentVolume
metadata: name: example-mysql-pv
spec: capacity: storage: 15Gi
volumeMode:Filesystem
accessModes: -ReadWriteOnce
persistentVolumeReclaimPolicy: Delete storageClassName: local-storage
local: path: /data/svr/projects/mysql
nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname
operator: In values: - node11.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.v1
kind:PersistentVolume
metadata: name: example-mysql-pv-2spec: capacity: storage: 15Gi
volumeMode:Filesystem
accessModes: -ReadWriteOnce
persistentVolumeReclaimPolicy: Delete storageClassName: local-storage
local: path: /data/svr/projects/mysql2
nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname
operator: In values: - node11.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.v1
kind:PersistentVolume
metadata: name: example-mysql-pv-3spec: capacity: storage: 15Gi
volumeMode:Filesystem
accessModes: -ReadWriteOnce
persistentVolumeReclaimPolicy: Delete storageClassName: local-storage
local: path: /data/svr/projects/mysql3
nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname
operator: In values: - node11.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.记住,这是在生产上不推荐的做法,我只是实验用途才这样手动预先创建,正规的做法应该通过StorageClass采用Dynamic Provisioning, 而不是Static Provisioning机制生产PV。
pv1 created
persistentvolume/example-mysql-pv2 created
persistentvolume/example-mysql-pv3 created1.2.3.4.创建StorageClass
02-storageclass.yamlStorageClass
apiVersion: storage.k8s.io/v1
metadata: name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer1.2.3.4.5.6.执行创建:
创建Namespace
03-mysql-namespace.yamlv1
kind:Namespace
metadata: name:mysql
labels: app: mysql1.2.3.4.5.6.执行创建:
创建数据库的配置文件configmap
使用ConfigMap为Master/Slave节点分配不同的配置文件
04-mysql-configmap.yamlv1
kind:ConfigMap
metadata: name:mysql
namespace:mysql
labels: app:mysql
data: master.cnf: |# Master配置
[mysqld] log-bin=mysqllog
skip-name-resolve
slave.cnf: |# Slave配置
[mysqld] super-read-only
skip-name-resolve
log-bin=mysql-bin
replicate-ignore-db=mysql1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.创建执行:
创建MySQL密码Secret
05-mysql-secret.yamlv1
kind:Secret
metadata: name: mysql-secret
namespace:mysql
labels: app:mysql
type:Opaque
data: password: MTIzNDU2 # echo -n "123456" | base641.2.3.4.5.6.7.8.9.10.创建执行:
使用Service为MySQL提供读写分离
06-mysql-services.yamlv1
kind:Service
metadata: name:mysql
namespace:mysql
labels: app:mysql
spec: ports: - name:mysql
port: 3306 clusterIP:None
selector: app:mysql
---apiVersion:v1
kind:Service
metadata: name: mysql-read
namespace:mysql
labels: app:mysql
spec: ports: - name:mysql
port: 3306 selector: app: mysql1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.n mysql
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)AGE
mysql ClusterIP None <none> 3306/TCP 20s
mysql-read ClusterIP 10.0.0.63 <none> 3306/TCP 20s1.2.3.4.5.创建MySQL集群实例
使用StatefulSet搭建MySQL主从集群
07-mysql-statefulset.yamlv1
kind:StatefulSet
metadata: name:mysql
namespace:mysql
labels: app:mysql
spec: selector: matchLabels: app:mysql
serviceName:mysql
replicas: 2 template: metadata: labels: app:mysql
spec: initContainers: - name: init-mysql
image: mysql:5.7 env: - name:MYSQL_ROOT_PASSWORD
valueFrom: secretKeyRef: name: mysql-secret
key:password
command: -bash
- "-c" - | set -ex
# 从Pod的序号,生成server-id
[[ $(hostname) =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} echo [mysqld] > /mnt/conf.d/server-id.cnf # 由于server-id不能为0,因此给ID加100来避开它
echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf # 如果Pod的序号为0,说明它是Master节点,从ConfigMap里把Master的配置文件拷贝到/mnt/conf.d目录下
# 否则,拷贝ConfigMap里的Slave的配置文件
if [[ ${ordinal} -eq 0 ]];then
cp /mnt/config-map/master.cnf /mnt/conf.delse
cp /mnt/config-map/slave.cnf /mnt/conf.dfi
volumeMounts: - name:conf
mountPath: /mnt/conf.d - name: config-map
mountPath: /mnt/config-map
- name: clone-mysql
image: gcr.io/google-samples/xtrabackup:1.0 env: - name:MYSQL_ROOT_PASSWORD
valueFrom: secretKeyRef: name: mysql-secret
key:password
command: -bash
- "-c" - | set -ex
# 拷贝操作只需要在第一次启动时进行,所以数据已经存在则跳过
[[ -d /var/lib/mysql/mysql ]] && exit 0 # Master 节点(序号为 0)不需要这个操作
[[ $(hostname) =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} [[ $ordinal == 0 ]] && exit 0# 使用ncat指令,远程地从前一个节点拷贝数据到本地
ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql # 执行 --prepare,这样拷贝来的数据就可以用作恢复了 xtrabackup --prepare --target-dir=/var/lib/mysql volumeMounts: - name:data
mountPath: /var/lib/mysql
subPath:mysql
- name:conf
mountPath: /etc/mysql/conf.d containers: - name:mysql
image: mysql:5.7 env: # - name:MYSQL_ALLOW_EMPTY_PASSWORD
# value: "1" - name:MYSQL_ROOT_PASSWORD
valueFrom: secretKeyRef: name: mysql-secret
key:password
ports: - name:mysql
containerPort: 3306 volumeMounts: - name:data
mountPath: /var/lib/mysql
subPath:mysql
- name:conf
mountPath: /etc/mysql/conf.d resources: requests: cpu: 500m
memory: 1Gi
livenessProbe: exec: command: ["mysqladmin", "ping", "-uroot", "-p${MYSQL_ROOT_PASSWORD}"] initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 readinessProbe: exec: command: ["mysqladmin", "ping", "-uroot", "-p${MYSQL_ROOT_PASSWORD}"] initialDelaySeconds: 5 periodSeconds: 2 timeoutSeconds: 1 - name:xtrabackup
image: gcr.io/google-samples/xtrabackup:1.0 ports: - name:xtrabackup
containerPort: 3307 env: - name:MYSQL_ROOT_PASSWORD
valueFrom: secretKeyRef: name: mysql-secret
key:password
command: -bash
- "-c" - | set -ex
cd /var/lib/mysql
# 从备份信息文件里读取MASTER_LOG_FILE和MASTER_LOG_POS这2个字段的值,用来拼装集群初始化SQL
if [[ -f xtrabackup_slave_info ]];then
# 如果xtrabackup_slave_info文件存在,说明这个备份数据来自于另一个Slave节点
# 这种情况下,XtraBackup工具在备份的时候,就已经在这个文件里自动生成了“CHANGE MASTER TO”SQL语句
# 所以,只需要把这个文件重命名为change_master_to.sql.in,后面直接使用即可
mv xtrabackup_slave_info change_master_to.sql.in# 所以,也就用不着xtrabackup_binlog_info了
rm -f xtrabackup_binlog_info
elif [[ -f xtrabackup_binlog_info ]];then
# 如果只是存在xtrabackup_binlog_info文件,说明备份来自于Master节点,就需要解析这个备份信息文件,读取所需的两个字段的值
[[ $(cat xtrabackup_binlog_info) =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1rm xtrabackup_binlog_info
# 把两个字段的值拼装成SQL,写入change_master_to.sql.in文件
echo "CHANGE MASTER TO MASTER_LOG_FILE=${BASH_REMATCH[1]},\ MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.infi
# 如果存在change_master_to.sql.in,就意味着需要做集群初始化工作
if [[ -f change_master_to.sql.in ]];then
# 但一定要先等MySQL容器启动之后才能进行下一步连接MySQL的操作
echo "Waiting for mysqld to be ready(accepting connections)" until mysql -h 127.0.0.1 -uroot -p${MYSQL_ROOT_PASSWORD} -e "SELECT 1"; do sleep 1;done
echo "Initializing replication from clone position" # 将文件change_master_to.sql.in改个名字
# 防止这个Container重启的时候,因为又找到了change_master_to.sql.in,从而重复执行一遍初始化流程
mv change_master_to.sql.in change_master_to.sql.orig # 使用change_master_to.sql.orig的内容,也就是前面拼装的SQL,组成一个完整的初始化和启动Slave的SQL语句
mysql -h 127.0.0.1 -uroot -p${MYSQL_ROOT_PASSWORD} <<EOF
$(< change_master_to.sql.orig), MASTER_HOST=mysql-0.mysql.mysql, MASTER_USER=root, MASTER_PASSWORD=${MYSQL_ROOT_PASSWORD}, MASTER_CONNECT_RETRY=10; START SLAVE;EOF
fi
# 使用ncat监听3307端口。
# 它的作用是,在收到传输请求的时候,直接执行xtrabackup --backup命令,备份MySQL的数据并发送给请求者 exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \ "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root --password=${MYSQL_ROOT_PASSWORD}" volumeMounts: - name:data
mountPath: /var/lib/mysql
subPath:mysql
- name:conf
mountPath: /etc/mysql/conf.d volumes: - name:conf
emptyDir: {} - name: config-map
configMap: name:mysql
volumeClaimTemplates: - metadata: name:data
spec: accessModes: - "ReadWriteOnce" storageClassName: local-storage
resources: requests: storage: 3Gi1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.70.71.72.73.74.75.76.77.78.79.80.81.82.83.84.85.86.87.88.89.90.91.92.93.94.95.96.97.98.99.100.101.102.103.104.105.106.107.108.109.110.111.112.113.114.115.116.117.118.119.120.121.122.123.124.125.126.127.128.129.130.131.132.133.134.135.136.137.138.139.140.141.142.143.144.145.146.147.148.149.150.151.152.153.154.155.156.157.158.159.160.161.162.163.164.165.166.167.168.169.170.171.172.173.174.175.176.177.178.179.180.181.182.183.184.185.186.187.188.189.190.191.192.193.整体的StatefulSet有两个Replicas,一个Master,一个Slave,然后使用init-mysql这个initContainers进行配置文件的初始化。接着使用clone-mysql这个initContainers进行数据的传输;同时使用xtrabackup这个sidecar容器进行SQL初始化和数据传输功能。
创建 StatefulSet:
可以看到,StatefulSet启动成功后,会有两个Pod运行。接下来,我们可以尝试向这个MySQL集群发起请求,执行一些SQL操作来验证它是否正常。整个过程因为拉取mysql和一个gcr.io/google-samples/xtrabackup:1.0国外的镜像会很慢,但是在创建mysql-0拉取一次之后,后续创建mysql-1就相对很快了。
最后,容器检查pod的运行状态
服务验证
验证主从状态:the command line interface can be insecure.
*************************** 1. row *************************** Slave_IO_State:Waiting for master to send event
Master_Host: mysql-0.mysql.mysql Master_User:root
Master_Port: 3306 Connect_Retry: 10 Master_Log_File: mysqllog.000003 Read_Master_Log_Pos: 154 Relay_Log_File: mysql-1-relay-bin.000002 Relay_Log_Pos: 319 Relay_Master_Log_File: mysqllog.000003 Slave_IO_Running:Yes
Slave_SQL_Running:Yes
Replicate_Do_DB: Replicate_Ignore_DB:mysql
Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 154 Relay_Log_Space: 528 Until_Condition:None
Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed:No
Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert:No
Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 100 Master_UUID: 1bad4d64-6290-11ea-8376-0242ac113802
Master_Info_File: /var/lib/mysql/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log;waiting for more updates
Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version:1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.c
1231.2.3.当看到输出结果,主从同步正常了。
扩展从节点
在有了StatefulSet以后,你就可以像Deployment那样,非常方便地扩展这个MySQL集群,比如:
n mysql
NAME READY STATUS RESTARTS AGE
mysql-0 2/2 Running 0 22m
mysql-1 2/2 Running 0 22m
mysql-2 2/2 Running 0 20s1.2.3.4.5.6.这时候,一个新的mysql-2就创建出来了,我们继续验证新扩容的节点是否都同步到主节点的数据。
c
1231.2.3.当看到输出结果,主从同步正常了。也就是说从StatefulSet为我们新创建的mysql-2上,同样可以读取到之前插入的记录。也就是说,我们的数据备份和恢复,都是有效的。