乐趣区

关于kubernetes:K8S-有状态的应用和示例多副本MySQL

本页展现如何应用 StatefulSet 控制器运行一个有状态的应用程序。此例是多正本的 MySQL 数据库。示例利用的拓扑构造有一个主服务器和多个正本,应用异步的基于行(Row-Based)的数据复制。

阐明:

这不是生产环境下配置。 尤其留神,MySQL 设置都应用的是不平安的默认值,这是因为咱们想把重点放在 Kubernetes 中运行有状态应用程序的个别模式上。

一、筹备

你必须领有一个 Kubernetes 的集群(至多 5 个子节点,1 主 4 子),同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。

如果你还没有集群,参考 用 kubeadm 在 Debian 或 Ubuntu 中创立 k8s 集群,不要用 Debian,用 Ubuntu

要实现本教程,你应该曾经相熟 Pod,Service 和 StatefulSet。

您正在应用 默认命名空间 或不蕴含任何抵触对象的另一个命名空间。

二、指标

  • 应用 StatefulSet 控制器部署多正本 MySQL 拓扑架构。
  • 发送 MySQL 客户端申请
  • 察看对宕机的抵抗力
  • 扩缩 StatefulSet 的规模

三、教程

1 部署 MySQL

MySQL 示例部署蕴含一个 ConfigMap、两个 Service 与一个 StatefulSet。

1.1 ConfigMap

应用以下的 YAML 配置文件创立 ConfigMap:

mysql-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql
  labels:
    app: mysql
data:
  master.cnf: |
    # Apply this config only on the master.
    [mysqld]
    log-bin
    skip_name_resolve
  slave.cnf: |
    # Apply this config only on slaves.
    [mysqld]
    super-read-only
    skip_name_resolve
kubectl apply -f ./mysql-configmap.yaml

这个 ConfigMap 提供 my.cnf 笼罩设置,使你能够独立管制 MySQL 主服务器和从服务器的配置。在这里,你心愿主服务器可能将复制日志提供给正本服务器,并且心愿正本服务器回绝任何不是通过复制进行的写操作。

ConfigMap 自身没有什么特别之处,因此也不会呈现不同局部利用于不同的 Pod 的状况。每个 Pod 都会在初始化时基于 StatefulSet 控制器提供的信息决定要查看的局部。

1.2 服务

应用以下 YAML 配置文件创立服务:

mysql-services.yaml

# Headless service for stable DNS entries of StatefulSet members.
apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  ports:
  - name: mysql
    port: 3306
  clusterIP: None
  selector:
    app: mysql
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv-2
  labels:
    type: local
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/tmp"
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  serviceName: mysql
  replicas: 3
  template:
    metadata:
      labels:
        app: mysql
    spec:
      initContainers:
      - name: init-mysql
        image: mysql:5.7
        args:
          - "--ignore-db-dir=lost+found"
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Generate mysql server-id from pod ordinal index.
          [[`hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          echo [mysqld] > /mnt/conf.d/server-id.cnf
          # Add an offset to avoid reserved server-id=0 value.
          echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
          # Copy appropriate conf.d files from config-map to emptyDir.
          if [[$ordinal -eq 0]]; then
            cp /mnt/config-map/master.cnf /mnt/conf.d/
          else
            cp /mnt/config-map/slave.cnf /mnt/conf.d/
          fi          
        volumeMounts:
        - name: conf
          mountPath: /mnt/conf.d
        - name: config-map
          mountPath: /mnt/config-map
      - name: clone-mysql
        image: registry.cn-hangzhou.aliyuncs.com/google_samples_thepoy/xtrabackup:1.0
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Skip the clone if data already exists.
          [[-d /var/lib/mysql/mysql]] && exit 0
          # Skip the clone on master (ordinal index 0).
          [[`hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          [[$ordinal -eq 0]] && exit 0
          # Clone data from previous peer.
          ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql
          # Prepare the backup.
          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
        args:
          - "--ignore-db-dir=lost+found"
        env:
        - name: MYSQL_ALLOW_EMPTY_PASSWORD
          value: "1"
        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"]
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
        readinessProbe:
          exec:
            # Check we can execute queries over TCP (skip-networking is off).
            command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
          initialDelaySeconds: 5
          periodSeconds: 2
          timeoutSeconds: 1
      - name: xtrabackup
        image: registry.cn-hangzhou.aliyuncs.com/google_samples_thepoy/xtrabackup:1.0
        ports:
        - name: xtrabackup
          containerPort: 3307
        command:
        - bash
        - "-c"
        - |
          set -ex
          cd /var/lib/mysql

          # Determine binlog position of cloned data, if any.
          if [[-f xtrabackup_slave_info && "x$(<xtrabackup_slave_info)" != "x" ]]; then
            # XtraBackup already generated a partial "CHANGE MASTER TO" query
            # because we're cloning from an existing slave. (Need to remove the tailing semicolon!)
            cat xtrabackup_slave_info | sed -E 's/;$//g' > change_master_to.sql.in
            # Ignore xtrabackup_binlog_info in this case (it's useless).
            rm -f xtrabackup_slave_info xtrabackup_binlog_info
          elif [[-f xtrabackup_binlog_info]]; then
            # We're cloning directly from master. Parse binlog position.
            [[`cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
            rm -f xtrabackup_binlog_info xtrabackup_slave_info
            echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
                  MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
          fi

          # Check if we need to complete a clone by starting replication.
          if [[-f change_master_to.sql.in]]; then
            echo "Waiting for mysqld to be ready (accepting connections)"
            until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done

            echo "Initializing replication from clone position"
            mysql -h 127.0.0.1 \
                  -e "$(<change_master_to.sql.in), \
                          MASTER_HOST='mysql-0.mysql', \
                          MASTER_USER='root', \
                          MASTER_PASSWORD='', \
                          MASTER_CONNECT_RETRY=10; \
                        START SLAVE;" || exit 1
            # In case of container restart, attempt this at-most-once.
            mv change_master_to.sql.in change_master_to.sql.orig
          fi

          # Start a server to send backups when requested by peers.
          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"          
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
      volumes:
      - name: conf
        emptyDir: {}
      - name: config-map
        configMap:
          name: mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

要应用 MySQL 5.6 镜像,不然在初始化时会出错。如果肯定要应用 5.7 镜像,须要增加参数"--ignore-db-dir=lost+found"

name: mysql
image: mysql:5.7
args:
  - "--ignore-db-dir=lost+found"
kubectl apply -f ./mysql-statefulset.yaml

你能够通过运行以下命令查看启动进度:

kubectl get pods -l app=mysql --watch

一段时间后,你应该看到 3 个 Pod 都进入了 Running 状态:

NAME      READY   STATUS    RESTARTS   AGE
mysql-0   2/2     Running   0          15m
mysql-1   2/2     Running   0          15m
mysql-2   2/2     Running   0          15m

3 个正本别离运行在一个子节点上

2 理解有状态的 Pod 初始化

StatefulSet 控制器按序数索引程序地启动每一个 Pod。它始终期待前一个 Pod 筹备好后才启动下一个 Pod。

此外,控制器为每个 Pod 调配一个惟一、稳固的名称,形如 <statefulset 名称 >-< 序数索引 >,其后果是 Pods 名为 mysql-0mysql-1mysql-2

上述 StatefulSet 清单中的 Pod 模板利用这些属性来执行 MySQL 正本的有序启动。

2.1 生成配置

在启动 Pod 规约中的任何容器之前,Pod 首先按程序运行所有的 Init 容器。

第一个名为 init-mysql 的 Init 容器依据序号索引生成非凡的 MySQL 配置文件。

该脚本通过从 Pod 名称的开端提取索引来确定本人的序号索引,而 Pod 名称由 hostname 命令返回。而后将序数(带有数字偏移量以防止保留值)保留到 MySQL conf.d 目录中的文件 server-id.cnf。这一操作将 StatefulSet 所提供的惟一、稳固的标识转换为 MySQL 服务器的 ID,而这些 ID 也是须要唯一性、稳定性保障的。

通过将生成的配置文件复制到 conf.d 目录中,init-mysql 容器中的脚本也能够利用 ConfigMap 中的 primary.cnfreplica.cnf。因为示例部署构造由单个 MySQL 主节点和任意数量的正本节点组成,因而脚本仅将序数 0 指定为主节点,而将其余所有节点指定为正本节点。

与 StatefulSet 控制器的 部署程序保障 相结合,能够确保 MySQL 主服务器在创立正本服务器之前已准备就绪,以便它们能够开始复制。

2.2 克隆现有数据

通常,当新 Pod 作为正本节点退出汇合时,必须假设 MySQL 主节点可能曾经有数据。还必须假如复制日志可能不会始终追溯到工夫的开始。

这些激进的假如是容许正在运行的 StatefulSet 随工夫扩充和放大而不是固定在其初始大小的要害。

第二个名为 clone-mysql 的 Init 容器,第一次在带有空 PersistentVolume 的正本 Pod 上启动时,会在隶属 Pod 上执行克隆操作。这意味着它将从另一个运行中的 Pod 复制所有现有数据,使此其本地状态足够统一,从而能够开始从主服务器复制。

MySQL 自身不提供执行此操作的机制,因而本示例应用了一种风行的开源工具 Percona XtraBackup。在克隆期间,源 MySQL 服务器性能可能会受到影响。为了最大水平地缩小对 MySQL 主服务器的影响,该脚本批示每个 Pod 从序号较低的 Pod 中克隆。能够这样做的起因是 StatefulSet 控制器始终确保在启动 Pod N + 1 之前 Pod N 已准备就绪。

2.3 开始复制

Init 容器胜利实现后,利用容器将运行。MySQL Pod 由运行理论 mysqld 服务的 mysql 容器和充当 辅助工具 的 xtrabackup 容器组成。

xtrabackup sidecar 容器查看克隆的数据文件,并确定是否有必要在正本服务器上初始化 MySQL 复制。如果是这样,它将期待 mysqld 准备就绪,而后应用从 XtraBackup 克隆文件中提取的复制参数 执行 CHANGE MASTER TOSTART SLAVE 命令。

一旦正本服务器开始复制后,它会记住其 MySQL 主服务器,并且如果服务器重新启动或 连贯中断也会主动从新连贯。另外,因为正本服务器会以其稳固的 DNS 名称查找主服务器(mysql-0.mysql),即便因为从新调度而取得新的 Pod IP,它们也会主动找到主服务器。

最初,开始复制后,xtrabackup 容器监听来自其余 Pod 的连贯,解决其数据克隆申请。如果 StatefulSet 扩充规模,或者下一个 Pod 失去其 PersistentVolumeClaim 并须要从新克隆,则此服务器将无限期放弃运行。

3 发送客户端申请

你能够通过运行带有 mysql:5.7 镜像的长期容器并运行 mysql 命令,将测试查问发送到 MySQL 主服务器(主机名 mysql-0.mysql):

kubectl run mysql-client --image=mysql:5.7 -i --rm --restart=Never --\
  mysql -h mysql-0.mysql <<EOF
CREATE DATABASE IF NOT EXISTS test;
CREATE TABLE IF NOT EXISTS test.messages (message VARCHAR(250));
INSERT INTO test.messages VALUES ('hello');
EOF

应用主机名 mysql-read 将测试查问发送到任何报告为就绪的服务器:

kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
  mysql -h mysql-read -e "SELECT * FROM test.messages"

你应该能看到上面的输入:

+---------+
| message |
+---------+
| hello   |
+---------+
pod "mysql-client" deleted

为了演示 mysql-read 服务在服务器之间调配连贯,你能够在循环中运行 SELECT @@server_id

+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         100 | 2021-05-27 03:53:38 |
+-------------+---------------------+
+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         100 | 2021-05-27 03:53:39 |
+-------------+---------------------+
+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         100 | 2021-05-27 03:53:40 |
+-------------+---------------------+
+-------------+---------------------+

要进行循环时能够按 Ctrl+C,然而让它在 另一个窗口中运行 十分有用,这样你就能够看到以下步骤的成果。

4 模仿 Pod 和 Node 的宕机工夫

为了证实从正本节点缓存而不是单个服务器读取数据的可用性进步,请在使 Pod 退出 Ready 状态时,放弃上述 SELECT @@server_id 循环始终运行。

4.1 毁坏就绪态探测

mysql 容器的 就绪态探测 运行命令 mysql -h 127.0.0.1 -e 'SELECT 1',以确保服务器已启动并可能执行查问。

迫使就绪态探测失败的一种办法就是停止该命令:

kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql /usr/bin/mysql.off

此命令会进入 Pod mysql-2 的理论容器文件系统,重命名 mysql 命令,导致就绪态探测无奈找到它。几秒钟后,Pod 会报告其中一个容器未就绪。你能够通过运行以下命令进行查看:

kubectl get pod mysql-2

READY 列中查找 1/2

NAME      READY     STATUS    RESTARTS   AGE
mysql-2   1/2       Running   0          3m

此时,你应该会看到 SELECT @@server_id 循环持续运行,但不再报告 102。回忆一下,init-mysql 脚本将 server-id 定义为 100 + $ordinal,因而服务器 ID 102 对应于 Pod mysql-2

当初修复 Pod,几秒钟后它应该从新呈现在循环输入中:

kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql.off /usr/bin/mysql

4.2 删除 Pods

如果删除了 Pod,则 StatefulSet 还会从新创立 Pod,相似于 ReplicaSet 对无状态 Pod 所做的操作。

kubectl delete pod mysql-2

StatefulSet 控制器留神到不再存在 mysql-2 Pod,于是创立一个具备雷同名称并链接到雷同 PersistentVolumeClaim 的新 Pod。你应该看到服务器 ID 102 从循环输入中隐没了一段时间,而后又自行呈现。

4.3 节点宕机

如果你的 Kubernetes 集群具备多个节点,则能够通过收回以下 drain 命令来模仿节点停机(就如同节点在被降级)。

或者将节点关机。

首先确定 MySQL Pod 之一在哪个节点上:

kubectl get pod mysql-2 -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP           NODE         NOMINATED NODE   READINESS GATES
mysql-2   2/2     Running   0          49m   10.244.3.2   k8s-node-2   <none>           <none>

如果将节点关机,则不须要执行上面的命令。

而后通过运行以下命令凌空节点,该命令将其爱护起来,以使新的 Pod 不能调度到该节点,而后逐出所有现有的 Pod。将 < 节点名称 > 替换为在上一步中找到的节点名称。

这可能会影响节点上的其余应用程序,因而最好 仅在测试集群中执行此操作

kubectl drain < 节点名称 > --force --delete-local-data --ignore-daemonsets

当初,你能够看到 Pod 被从新调度到其余节点上:

kubectl get pod mysql-2 -o wide --watch

响应相似:

mysql-0   0/2     Terminating   4          65m   10.244.3.10   k8s-node-3 
...
mysql-0   0/2     Pending       0          0s    <none>        <none>    
mysql-0   0/2     Pending       0          0s    <none>        k8s-node-4 
mysql-0   0/2     Init:0/2      0          0s    <none>        k8s-node-4 
mysql-0   0/2     Init:1/2      0          30m   10.244.4.2    k8s-node-4 
mysql-0   0/2     PodInitializing   0          30m   10.244.4.2    k8s-node-4 
mysql-0   1/2     Running           0          30m   10.244.4.2    k8s-node-4 
mysql-0   2/2     Running           0          30m   10.244.4.2    k8s-node-4 

再次,你应该看到服务器 ID 102SELECT @@server_id 循环输入 中隐没一段时间,而后自行呈现。

当初去掉节点爱护(Uncordon),使其复原为失常模式:

kubectl uncordon < 节点名称 >

5 扩大正本节点数量

扩大正本须要先增加对应数量的 PV,如果之前应用的是 StorageClass,则不须要进行此操作。

应用 MySQL 复制,你能够通过增加正本节点来扩大读取查问的能力。应用 StatefulSet,你能够应用单个命令执行此操作:

kubectl scale statefulset mysql --replicas=5

查看新的 Pod 的运行状况:

kubectl get pods -l app=mysql --watch

一旦 Pod 启动,你应该看到服务器 IDs 103104 开始呈现在 SELECT @@server_id 循环输入中。

你还能够验证这些新服务器在存在之前已增加了数据:

kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
  mysql -h mysql-3.mysql -e "SELECT * FROM test.messages"
+---------+
| message |
+---------+
| hello   |
+---------+
pod "mysql-client" deleted

向下压缩操作也是很简略:

kubectl scale statefulset mysql --replicas=3

然而请留神,如果你用的是 StorageClass,按比例扩大会主动创立新的 PersistentVolumeClaims,而按比例放大不会主动删除这些 PVC。这使你能够抉择保留那些初始化的 PVC,以更快地进行缩放,或者在删除它们之前提取数据。

你能够通过运行以下命令查看此信息:

kubectl get pvc -l app=mysql

这表明,只管将 StatefulSet 放大为 3,所有 5 个 PVC 依然存在:

NAME           STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
data-mysql-0   Bound     pvc-8acbf5dc-b103-11e6-93fa-42010a800002   10Gi       RWO           20m
data-mysql-1   Bound     pvc-8ad39820-b103-11e6-93fa-42010a800002   10Gi       RWO           20m
data-mysql-2   Bound     pvc-8ad69a6d-b103-11e6-93fa-42010a800002   10Gi       RWO           20m
data-mysql-3   Bound     pvc-50043c45-b1c5-11e6-93fa-42010a800002   10Gi       RWO           2m
data-mysql-4   Bound     pvc-500a9957-b1c5-11e6-93fa-42010a800002   10Gi       RWO           2m

如果你不打算重复使用多余的 PVC,则能够删除它们:

kubectl delete pvc data-mysql-3
kubectl delete pvc data-mysql-4

6 删除本示例

通过在终端上按 Ctrl+C 勾销 SELECT @@server_id 循环,或从另一个终端运行以下命令:

kubectl delete pod mysql-client-loop --now

删除 StatefulSet。这也会开始终止 Pod。

kubectl delete statefulset mysql

验证 Pod 隐没。他们可能须要一些工夫能力实现终止。

kubectl get pods -l app=mysql

删除 ConfigMap、Services 和 PersistentVolumeClaims。

kubectl delete configmap,service,pvc -l app=mysql

如果你是手动创立的 PersistentVolume,则还须要手动删除它们,并开释上层资源。如果你应用了动静预配器,当得悉你删除 PersistentVolumeClaims 时,它将主动删除 PersistentVolumes。一些动静预配器(例如用于 EBS 和 PD 的预配器)也会在删除 PersistentVolumes 时开释上层资源。

退出移动版