想提高运维效率，那就把MySQL数据库部署到Kubernetes 集群中

喜欢ヅ旅行 2022-09-15 11:54 6阅读 0赞

> **摘要：**Kubernetes 很多看起来比较“繁琐”的设计的主要目的，都是希望为开发者提供更多的“可扩展性”，给使用者带来更多的“稳定性”和“安全感”。

本文分享自华为云社区《[如何在 Kubernetes 集群中搭建一个复杂的 MySQL 数据库？][Kubernetes _ MySQL]》，作者：zuozewei 。

## 前言 ##

实际生产环境中，为了稳定和高可用，运维团队一般不会把 MySQL 数据库部署在 Kubernetes 集群中，一般是用云厂商的数据库或者自己在高性能机器（如裸金属服务器）上搭建。

但是，对于测试开发环境，我们完全可以把 MySQL 部署到各自的 Kubernetes 集群中,非常有助于提升运维效率，而且还有助于Kubernetes 使用的经验积累。

## 简易部署 ##

如下所示，我们仅需设置 root 用户密码（环境变量 MYSQL\_ROOT\_PASSWORD）， 便可轻松的使用 MySQL 官方镜像构建一个 MySQL 数据库。

apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      labels:
        app: mysql-min
      name: mysql-min
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: mysql-min
      template:
        metadata:
          labels:
            app: mysql-min
        spec:
          containers:
          - image: centos/mysql-57-centos7:latest
            name: mysql-min
            imagePullPolicy: IfNotPresent
            env:
            - name: MYSQL_ROOT_PASSWORD
              value: admin@123

创建一 Service 以便集群内外均可访问数据库，其中集群外需通过 nodePort 设置的 30336 端口访问。

apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: mysql-min
        release: mysql-min
      name: mysql-min
      namespace: default
    spec:
      ports:
      - name: mysql
        port: 3306
        protocol: TCP
        nodePort: 30336
        targetPort: mysql
      selector:
        app: mysql-min
      #目前sessionAffinity可以提供"None""ClientIP"两种设定:
      #None: 以round robin的方式轮询下面的Pods。
      #ClientIP: 以client ip的方式固定request到同一台机器。
      sessionAffinity: None
      type: NodePort
    #status:
    #  loadBalancer: {}

接着，访问数据库并验证其运行正常：

# kubectl get pod   # 当前Pod名称
    NAME                     	READY     STATUS    RESTARTS   AGE
    mysql-min-5b5668c448-t44ml   1/1       Running   0          3h
    
    # 通过本机访问
    # kubectl exec -it mysql-min-5b5668c448-t44ml -- mysql -uroot -padmin@123
    mysql> select 1;
    +---+
    | 1 |
    +---+
    | 1 |
    +---+
    
    # 集群内部通过mysql service访问：
    # kubectl exec -it mysql-min-5b5668c448-t44ml -- mysql -uroot -padmin@123 -hmysql
    
    mysql> select now();
    +---------------------+
    | now()               |
    +---------------------+
    | 2021-03-13 07:19:14 |
    +---------------------+
    
    # 集群外部，可通过任何一个 K8S 节点访问数据库：
    # mysql -uroot -padmin@123 -hworker-1 -P30336 
    
    mysql> show databases;
    +--------------------+
    | Database           |
    +--------------------+
    | information_schema |
    | mysql              |
    | performance_schema |
    | sys                |
    +--------------------+

## 扩展部署 ##

### 持久化存储 ###

若要确保 MySQL 重启后数据仍然存在，我们需为其配置可持久化存储，我这里的实验环境使用的是 Local Persistent Volume，也就是说，我希望 Kubernetes 能够直接使用宿主机上的本地磁盘目录，而不依赖于远程存储服务，来提供“持久化”的容器 Volume。这样做的好处很明显，由于这个 Volume 直接使用的是本地磁盘，尤其是 SSD 盘，它的读写性能相比于大多数远程存储来说，要好得多。这个需求对本地物理服务器部署的私有 Kubernetes 集群来说，非常常见。

值得指出的是其次，相比于正常的 PV，一旦这些节点宕机且不能恢复时，本地存储 Volume 的数据就可能丢失。这就要求使用 其的应用必须具备数据备份和恢复的能力，允许你把这些数据定时备份在其他位置。

不难想象， Local Persistent Volume 的设计，主要面临两个难点。

**第一个难点在于：如何把本地磁盘抽象成 PV。**

可能你会说，Local Persistent Volume 不就等同于 hostPath 加 NodeAffinity 吗？

比如，一个 Pod 可以声明使用类型为 Local 的 PV，而这个 PV 其实就是一个 hostPath 类型的 Volume。如果这个 hostPath 对应的目录，已经在节点 A 上被事先创建好了。那么，我只需要再给这个 Pod 加上一个 nodeAffinity=nodeA，不就可以使用这个 Volume 了吗？

事实上，你绝不应该把一个宿主机上的目录当作 PV 使用。这是因为，这种本地目录的存储行为完全不可控，它所在的磁盘随时都可能被应用写满，甚至造成整个宿主机宕机。而且，不同的本地目录之间也缺乏哪怕最基础的 I/O 隔离机制。

所以，一个 本地存储 Volume 对应的存储介质，一定是一块额外挂载在宿主机的磁盘或者块设备（“额外”的意思是，它不应该是宿主机根目录所使用的主硬盘）。这个原则，我们可以称为“**一个 PV 一块盘**”。

**第二个难点在于：调度器如何保证 Pod 始终能被正确地调度到它所请求的本地 Volume 所在的节点上呢？**

造成这个问题的原因在于，对于常规的 PV 来说，Kubernetes 都是先调度 Pod 到某个节点上，然后，再通过“两阶段处理”来“持久化”这台机器上的 Volume 目录，进而完成 Volume 目录与容器的绑定挂载。

可是，对于 Local PV 来说，节点上可供使用的磁盘（或者块设备），必须是运维人员提前准备好的。它们在不同节点上的挂载情况可以完全不同，甚至有的节点可以没这种磁盘。

所以，这时候，调度器就必须能够知道所有节点与 Local Persistent Volume 对应的磁盘的关联关系，然后根据这个信息来调度 Pod。

这个原则，我们可以称为“在调度的时候考虑 Volume 分布”。在 Kubernetes 的调度器里，有一个叫作 VolumeBindingChecker 的过滤条件专门负责这个事情。在 Kubernetes v1.11 中，这个过滤条件已经默认开启了。

基于上述讲述，在开始使用 Local Persistent Volume 之前，你首先需要在集群里配置好磁盘或者块设备。在公有云上，这个操作等同于给虚拟机额外挂载一个磁盘，比如 GCE 的 Local SSD 类型的磁盘就是一个典型例子。

而在我们部署的私有环境中，你有两种办法来完成这个步骤。

*  第一种，当然就是给你的宿主机挂载并格式化一个可用的本地磁盘，这也是最常规的操作；
 *  第二种，对于实验环境，你其实可以在宿主机上挂载几个 RAM Disk（内存盘）来模拟本地磁盘。

接下来，我会使用第二种方法，在我们之前部署的 Kubernetes 集群上进行实践。首先，在名叫 node-1 的宿主机上创建一个挂载点，比如 /mnt/disks；然后，用几个 RAM Disk 来模拟本地磁盘，如下所示：

# 在node-1上执行
    $ mkdir /mnt/disks
    $ for vol in vol1 vol2 vol3; do
        mkdir /mnt/disks/$vol
        mount -t tmpfs $vol /mnt/disks/$vol
    done

需要注意的是，如果你希望其他节点也能支持 Local Persistent Volume 的话，那就需要为它们也执行上述操作，并且确保这些磁盘的名字（vol1、vol2 等）都不重复。接下来，我们就可以为这些本地磁盘定义对应的 PV 了，如下所示：

apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: mysql-min-pv-local
      namespace: default
    spec:
      capacity:
        storage: 5Gi
      volumeMode: Filesystem
      accessModes:
        - ReadWriteOnce
      storageClassName: "mysql-min-storageclass-local"
      persistentVolumeReclaimPolicy: Retain
      #表示使用本地存储
      local:
        path: /mnt/disks/vol1
      #使用local pv时必须定义nodeAffinity，Kubernetes Scheduler需要使用PV的nodeAffinity描述信息来保证Pod能够调度到有对应local volume的Node上。
      #创建local PV之前，你需要先保证有对应的storageClass已经创建。
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              # pod 需要分不到的主机名，这台主机上开启了 local-pv 资源。
              - node-1

可以看到，这个 PV 的定义里：local 字段，指定了它是一个 Local Persistent Volume；而 path 字段，指定的正是这个 PV 对应的本地磁盘的路径，即：/mnt/disks/vol1。

当然了，这也就意味着如果 Pod 要想使用这个 PV，那它就必须运行在 node-1 上。所以，在这个 PV 的定义里，需要有一个 nodeAffinity 字段指定 node-1 这个节点的名字。这样，调度器在调度 Pod 的时候，就能够知道一个 PV 与节点的对应关系，从而做出正确的选择。这正是 Kubernetes 实现“在调度的时候就考虑 Volume 分布”的主要方法。

接下来要创建一个 StorageClass 来描述这个 PV，如下所示：

kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: mysql-min-storageclass-local
    #指定存储类的供应者,比如aws, nfs等，具体取值参考官方说明。
    #存储类有一个供应者的参数域，此参数域决定PV使用什么存储卷插件。参数必需进行设置
    #由于demo中使用的是本地存储，所以这里写kubernetes.io/no-provisioner.
    provisioner: kubernetes.io/no-provisioner
    #volumeBindingMode 参数将延迟PVC绑定，直到 pod 被调度。
    volumeBindingMode: WaitForFirstConsumer

这个 StorageClass 的名字，叫作 local-storage。需要注意的是，在它的 provisioner 字段，我们指定的是 no-provisioner。这是因为 Local Persistent Volume 目前尚不支持 Dynamic Provisioning，所以它没办法在用户创建 PVC 的时候，就自动创建出对应的 PV。也就是说，我们前面创建 PV 的操作，是不可以省略的。

与此同时，这个 StorageClass 还定义了一个 volumeBindingMode=WaitForFirstConsumer 的属性。它是 Local Persistent Volume 里一个非常重要的特性，即：延迟绑定。

> 通过这个延迟绑定机制，原本实时发生的 PVC 和 PV 的绑定过程，就被延迟到了 Pod 第一次调度的时候在调度器中进行，从而保证了这个绑定结果不会影响 Pod 的正常调度。

接下来，我们只需要定义一个非常普通的 PVC，就可以让 Pod 使用到上面定义好的 Local Persistent Volume 了，如下所示：

apiVersion: v1
    items:
    - apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        #当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。PVC 的删除将被推迟，直到 PVC 不再被任何 pod 使用。
        #可以看到，当 PVC 的状态为 Teminatiing 时，PVC 受到保护，Finalizers 列表中包含 kubernetes.io/pvc-protection：
        finalizers:
        - kubernetes.io/pvc-protection
        labels:
          app: mysql-min
          release: mysql-min
        name: mysql-min
        namespace: default
      spec:
        #PV 的访问模式（accessModes）有三种：
        #ReadWriteOnce（RWO）：是最基本的方式，可读可写，但只支持被单个 Pod 挂载。
        #ReadOnlyMany（ROX）：可以以只读的方式被多个 Pod 挂载。
        #ReadWriteMany（RWX）：这种存储可以以读写的方式被多个 Pod 共享。
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi
        storageClassName: mysql-min-storageclass-local
        #表示使用本地磁盘，实际生产中一般都使用nfs。
        volumeMode: Filesystem
        volumeName: mysql-min-pv-local
    #  status:
    #    accessModes:
    #    - ReadWriteOnce
    #    capacity:
    #      storage: 1Gi
    kind: List

可以看到，这个 PVC 没有任何特别的地方。唯一需要注意的是，它声明的 storageClassName 是 mysql-min-storageclass-local。所以，将来 Kubernetes 的 Volume Controller 看到这个 PVC 的时候，不会为它进行绑定操作。  
  
最后，我们创建 Local Persistent Volume 资源文件：

kubectl apply -f mysql-min-pv-local.yaml
    kubectl apply -f mysql-min-storageclass-local.yaml
    kubectl apply -f mysql-min-pvc.yaml

而后，调整 Deploy 并挂载卷：

spec:
          containers:
          - image: centos/mysql-57-centos7:latest
    ...
            volumeMounts:
            - name: data
              mountPath: /var/lib/mysql
          volumes:
          - name: data
            persistentVolumeClaim:
              claimName: mysql-min

### 自定义配置文件 ###

通过创建 configmap 并挂载到容器中，我们可自定义 MySQL 配置文件。如下所示，名为 mysql-config 的 cm 包含一个 my.cnf 文件:

apiVersion: v1
    kind: ConfigMap
    metadata:
      name: mysql-config
    data:
      my.cnf: |
        [mysqld]
        default_storage_engine=innodb
        skip_external_locking
        lower_case_table_names=1
        skip_host_cache
        skip_name_resolve
        max_connections=2000
        innodb_buffer_pool_size=8589934592
        init_connect='SET collation_connection = utf8_unicode_ci'
        init_connect='SET NAMES utf8'
        character-set-server=utf8
        collation-server=utf8_unicode_ci
        skip-character-set-client-handshake
        query_cache_type=0
        innodb_flush_log_at_trx_commit = 0
        sync_binlog = 0
        query_cache_size = 104857600
        slow_query_log =1
        slow_query_log_file=/var/lib/mysql/slow-query.log
        log-error=/var/lib/mysql/mysql.err
        long_query_time = 0.02
        table_open_cache_instances=16
        table_open_cache = 6000
        skip-grant-tables
        sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

将 configmap 挂载到容器内：

spec:
    ...
          containers:
          - image: centos/mysql-57-centos7:latest
    ...
            volumeMounts:
            - name: mysql-config
              mountPath: /etc/my.cnf.d/my.cnf
              subPath: my.cnf
    ...
          volumes:
          - name: mysql-config
            - name: mysql-config
              configMap:
                name: mysql-config
    ...

### 设置容器时区 ###

最傻瓜也最方便的处理方式，设置宿主机时区和时间文件与容器的映射。

spec:
    ...
          containers:
          - image: centos/mysql-57-centos7:latest
    ...
            volumeMounts:
            - name: localtime
              readOnly: true
              mountPath: /etc/localtime
    ...
          volumes:
           - name: localtime
             hostPath:
               type: File
               path: /etc/localtime
    ...

### 加密敏感数据 ###

用户密码等敏感数据以 Secret 加密保存，而后被 Deployment 通过 volume 挂载或环境变量引用。如本例，我们创建root、user用户，将用户的密码加密保存：

apiVersion: v1
    data:
      #将mysql数据库的所有user的password配置到secret，统一管理
      mysql-password: YWRtaW4=
      mysql-root-password: OVplTmswRGdoSA==
    kind: Secret
    metadata:
      labels:
        app: mysql-min
        release: mysql-min
      name: mysql-min
      namespace: default
    #Secret有三种类型：
    #Opaque：base64编码格式的Secret，用来存储密码、密钥等；但数据也通过base64 –decode解码得到原始数据，所有加密性很弱。
    #kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。
    #kubernetes.io/service-account-token： 用于被serviceaccount引用。serviceaccout创建时Kubernetes会默认创建对应的secret。Pod如果使用了serviceaccount，对应的secret会自动挂载到Pod目录/run/secrets/ kubernetes.io/serviceaccount中。
    type: Opaque

Secret 创建完成后，我们将用户明文密码从 Deployment 去除，采用环境变量方式引用 Secret 数据，参见如下 Yaml 修改：

*  root 用户及 MYSQL\_USER 用户，其密码均通过 secretKeyRef 从 secret 获取。

spec:
    ...
          containers:
          - image: centos/mysql-57-centos7:latest
            name: mysql-min
            imagePullPolicy: IfNotPresent
            env:
               #password存储在secret中
               - name: MYSQL_ROOT_PASSWORD
                 valueFrom:
                   secretKeyRef:
                     key: mysql-root-password
                     name: mysql-min
               - name: MYSQL_PASSWORD
                 valueFrom:
                   secretKeyRef:
                     key: mysql-password
                     name: mysql-min
               - name: MYSQL_USER
                 value: zuozewei

### 容器健康检查 ###

K8S 镜像控制器可通过 livenessProbe 判断容器是否异常，进而决定是否重建容器；而 Service 服务可通过 readinessProbe 判断容器服务是否正常，从而确保服务可用性。

本例配置的 livenessProbe 与 readinessProbe 是一样的，即连续 3 次查询数据库失败，则定义为异常。对 livenessProbe 与readinessProbe 详细用法，不在本文的讨论范围内，可参考 K8S 官方文档：

*  Configure Liveness and Readiness Probes
 *  Pod Lifecycle

spec:
          containers:
              image: centos/mysql-57-centos7:latest
    ...
              #kubelet 使用 liveness probe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness 探针将捕获到 deadlock，重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去
              livenessProbe:
                exec:
                  command:
                    - /bin/sh
                    - "-c"
                    - MYSQL_PWD="${MYSQL_ROOT_PASSWORD}"
                    - mysql -h 127.0.0.1 -u root -e "SELECT 1"
                failureThreshold: 3 #探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3。最小值是 1。
                initialDelaySeconds: 30 #容器启动后第一次执行探测是需要等待多少秒。
                periodSeconds: 10 #执行探测的频率。默认是10秒，最小1秒。
                successThreshold: 1 #探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1。对于 liveness 必须是 1。最小值是 1。
                timeoutSeconds: 5 #探测超时时间。默认1秒，最小1秒。
              #Kubelet 使用 readiness probe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当 Pod 中的容器都处于就绪状态时 kubelet 才会认定该 Pod处于就绪状态。该信号的作用是控制哪些 Pod应该作为service的后端。如果 Pod 处于非就绪状态，那么它们将会被从 service 的 load balancer中移除。
              readinessProbe:
                exec:
                  command:
                    - /bin/sh
                    - "-c"
                    - MYSQL_PWD="${MYSQL_ROOT_PASSWORD}"
                    - mysql -h 127.0.0.1 -u root -e "SELECT 1"
                failureThreshold: 3
                initialDelaySeconds: 5
                periodSeconds: 10
                successThreshold: 1
                timeoutSeconds: 1

### 容器初始化 ###

容器的一些初始化操作显然适合通过 InitContainer 来完成，这里的 initContainer 是为了保证在 POD 启动前，PV盘 要先行绑定成功，同时为了避免 MySQL 数据库目录内的 lost+found 目录被误认为是数据库，初始化容器中将其删除；

#Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。 然而，Init 容器对资源请求和限制的处理稍有不同，在下面 资源 处有说明。 而且 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。
          #如果为一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。 每个 Init 容器必须运行成功，下一个才能够运行。 当所有的 Init 容器运行完成时，Kubernetes 初始化 Pod 并像平常一样运行应用容器。
          #mysql这里的initContainer是为了保证在POD启动前，PV盘要先行绑定成功。
          initContainers:
            - command:
                - rm
                - -fr
                - /var/lib/mysql/lost+found
              image: busybox:1.29.3
              imagePullPolicy: IfNotPresent
              name: remove-lost-found
              resources: {}
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
              volumeMounts:
                - mountPath: /var/lib/mysql
                  name: data
          restartPolicy: Always
          #scheduler 是 kubernetes 的调度器，主要的任务是把定义的 pod 分配到集群的节点上。
          schedulerName: default-scheduler
          securityContext: {}
          #如果您的Pod通常需要超过30秒才能关闭，请确保增加优雅终止宽限期。可以通过在Pod YAML中设置terminationGracePeriodSeconds选项来实现.
          #如果容器在优雅终止宽限期后仍在运行，则会发送SIGKILL信号并强制删除。与此同时，所有的Kubernetes对象也会被清除。
          terminationGracePeriodSeconds: 30
          #定义数据卷PVC,与PV匹配。
          volumes:
            - name: data
              persistentVolumeClaim:
                claimName: mysql-min
            - name: mysql-config
              configMap:
                name: mysql-config
            - name: localtime
              hostPath:
                type: File
                path: /etc/localtime

### 完整Deployment ###

通过如上多步调整，MySQL 数据库的 Deplyment 如下所示：

apiVersion: apps/v1
    kind: Deployment
    metadata:
      annotations:
        deployment.kubernetes.io/revision: "1"
      generation: 1
      labels:
        app: mysql-min
        release: mysql-min
      name: mysql-min
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: mysql-min
      strategy:
        rollingUpdate:
          maxSurge: 1 #滚动升级时会先启动1个pod
          maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
        type: RollingUpdate #滚动升级
      template:
        metadata:
          labels:
            app: mysql-min
        spec:
          containers:
            - env:
                #password存储在secret中
                - name: MYSQL_ROOT_PASSWORD
                  valueFrom:
                    secretKeyRef:
                      key: mysql-root-password
                      name: mysql-min
                - name: MYSQL_PASSWORD
                  valueFrom:
                    secretKeyRef:
                      key: mysql-password
                      name: mysql-min
                - name: MYSQL_USER
                  value: apollo
              image: centos/mysql-57-centos7:latest
              imagePullPolicy: IfNotPresent
              #kubelet 使用 liveness probe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness 探针将捕获到 deadlock，重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去
              livenessProbe:
                exec:
                  command:
                    - /bin/sh
                    - "-c"
                    - MYSQL_PWD="${MYSQL_ROOT_PASSWORD}"
                    - mysql -h 127.0.0.1 -u root -e "SELECT 1"
                failureThreshold: 3 #探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3。最小值是 1。
                initialDelaySeconds: 30 #容器启动后第一次执行探测是需要等待多少秒。
                periodSeconds: 10 #执行探测的频率。默认是10秒，最小1秒。
                successThreshold: 1 #探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1。对于 liveness 必须是 1。最小值是 1。
                timeoutSeconds: 5 #探测超时时间。默认1秒，最小1秒。
              name: mysql-min
              ports:
                - containerPort: 3306
                  name: mysql
                  protocol: TCP
              #Kubelet 使用 readiness probe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当 Pod 中的容器都处于就绪状态时 kubelet 才会认定该 Pod处于就绪状态。该信号的作用是控制哪些 Pod应该作为service的后端。如果 Pod 处于非就绪状态，那么它们将会被从 service 的 load balancer中移除。
              readinessProbe:
                exec:
                  command:
                    - /bin/sh
                    - "-c"
                    - MYSQL_PWD="${MYSQL_ROOT_PASSWORD}"
                    - mysql -h 127.0.0.1 -u root -e "SELECT 1"
                failureThreshold: 3
                initialDelaySeconds: 5
                periodSeconds: 10
                successThreshold: 1
                timeoutSeconds: 1
              resources:
                requests:
                  cpu: 100m
                  memory: 256Mi
              #为了达到一个相当高水平的实用性，特别是为了积极开发应用，快速调试失败是很重要的。除了一般的日志采集，Kubernetes还能通过查出重大错误原因来加速调试，并在某种程度上通过kubectl或者UI陈列出来。可以指定一个’terminationMessagePath’来让容器写下它的“death rattle“，比如声明失败消息，堆栈跟踪，免责条款等等。默认途径是‘/dev/termination-log’。
              terminationMessagePath: /dev/termination-log
              # 此字段默认为 “File“，这意味着仅从终止消息文件中检索终止消息。 通过将 terminationMessagePolicy 设置为 “FallbackToLogsOnError“，你就可以告诉 Kubernetes，在容器因错误退出时，如果终止消息文件为空，则使用容器日志输出的最后一块作为终止消息。 日志输出限制为 2048 字节或 80 行，以较小者为准。
              terminationMessagePolicy: File
              #要使用的数据盘目录，在initContainer中会关联此处目录。
              volumeMounts:
                - mountPath: /var/lib/mysql
                  name: data
                - name: mysql-config
                  mountPath: /etc/my.cnf.d/my.cnf
                  subPath: my.cnf
                - name: localtime
                  readOnly: true
                  mountPath: /etc/localtime
          dnsPolicy: ClusterFirst
          #Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。 然而，Init 容器对资源请求和限制的处理稍有不同，在下面 资源 处有说明。 而且 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。
          #如果为一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。 每个 Init 容器必须运行成功，下一个才能够运行。 当所有的 Init 容器运行完成时，Kubernetes 初始化 Pod 并像平常一样运行应用容器。
          #mysql这里的initContainer是为了保证在POD启动前，PV盘要先行绑定成功。
          initContainers:
            - command:
                - rm
                - -fr
                - /var/lib/mysql/lost+found
              image: busybox:1.29.3
              imagePullPolicy: IfNotPresent
              name: remove-lost-found
              resources: {}
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
              volumeMounts:
                - mountPath: /var/lib/mysql
                  name: data
          restartPolicy: Always
          #scheduler 是 kubernetes 的调度器，主要的任务是把定义的 pod 分配到集群的节点上。
          schedulerName: default-scheduler
          securityContext: {}
          #如果您的Pod通常需要超过30秒才能关闭，请确保增加优雅终止宽限期。可以通过在Pod YAML中设置terminationGracePeriodSeconds选项来实现.
          #如果容器在优雅终止宽限期后仍在运行，则会发送SIGKILL信号并强制删除。与此同时，所有的Kubernetes对象也会被清除。
          terminationGracePeriodSeconds: 30
          #定义数据卷PVC,与PV匹配。
          volumes:
            - name: data
              persistentVolumeClaim:
                claimName: mysql-min
            - name: mysql-config
              configMap:
                name: mysql-config
            - name: localtime
              hostPath:
                type: File
                path: /etc/localtime

创建此 Deployment 后，我们有如下组件：

# kubectl get all,pvc,cm,secret -l app=mysql-min
    # MySQL pod：
    NAME                           READY   STATUS    RESTARTS   AGE
    pod/mysql-min-f9c9b7b5-q9br4   1/1     Running   6          14d
    
    # Service：
    NAME                TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
    service/mysql-min   NodePort   10.96.184.130   <none>        3306:30336/TCP   16d
    
    # MySQL Deployment：
    NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/mysql-min   1/1     1            1           16d
    
    # 副本集ReplicaSet被Deployment调用，其是自动生成的
    NAME                                   DESIRED   CURRENT   READY   AGE
    replicaset.apps/mysql-min-587cf9fd48   0         0         0       16d
    replicaset.apps/mysql-min-589bf8cdc5   0         0         0       16d
    replicaset.apps/mysql-min-6b7447c7dd   0         0         0       14d
    replicaset.apps/mysql-min-6cc9887459   0         0         0       16d
    replicaset.apps/mysql-min-7759579d77   0         0         0       16d
    replicaset.apps/mysql-min-84d4d6bd56   0         0         0       15d
    replicaset.apps/mysql-min-f9c9b7b5     1         1         1       14d
    
    # Pvc：
    NAME                              STATUS   VOLUME               CAPACITY   ACCESS MODES   STORAGECLASS                   AGE
    persistentvolumeclaim/mysql-min   Bound    mysql-min-pv-local   5Gi       RWO            mysql-min-storageclass-local   16d
    
    # Secret：
    NAME               TYPE     DATA   AGE
    secret/mysql-min   Opaque   2      16d

## 定期自动备份 ##

考虑到数据安全性，我们定期备份数据库，在K8S集群中，我们可配置 CronJob 实现自动备份作业。首先，创建一个持久化存储供备份用：

apiVersion: v1
    items:
    - apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        #当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。PVC 的删除将被推迟，直到 PVC 不再被任何 pod 使用。
        #可以看到，当 PVC 的状态为 Teminatiing 时，PVC 受到保护，Finalizers 列表中包含 kubernetes.io/pvc-protection：
        finalizers:
        - kubernetes.io/pvc-protection
        labels:
          app: mysql-min
          release: mysql-min
        name: mysql-min-backup
        namespace: default
      spec:
        #PV 的访问模式（accessModes）有三种：
        #ReadWriteOnce（RWO）：是最基本的方式，可读可写，但只支持被单个 Pod 挂载。
        #ReadOnlyMany（ROX）：可以以只读的方式被多个 Pod 挂载。
        #ReadWriteMany（RWX）：这种存储可以以读写的方式被多个 Pod 共享。
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi
        storageClassName: mysql-min-storageclass-nfs
        #表示使用本地磁盘，实际生产中一般都使用nfs。
        volumeMode: Filesystem
        volumeName: mysql-min-pv-local
    #  status:
    #    accessModes:
    #    - ReadWriteOnce
    #    capacity:
    #      storage: 1Gi
    kind: List

继而，配置实际的自动化作业任务，如下所示，每天凌晨零点点将使用 mysqldump 备份 mall 数据库。

apiVersion: batch/v1beta1
    kind: CronJob
    metadata:
      name: mysql-backup
    spec:
      schedule: "0 0 * * *"
      jobTemplate:
        spec:
          template:
            spec:
              containers:
                - name: mysql-min-backup
                  imagePullPolicy: IfNotPresent
                  image: centos/mysql-57-centos7:latest
                  env:
                    #password存储在secret中
                    - name: MYSQL_ROOT_PASSWORD
                      valueFrom:
                        secretKeyRef:
                          key: mysql-root-password
                          name: mysql-min
                    - name: MYSQL_PASSWORD
                      valueFrom:
                        secretKeyRef:
                          key: mysql-password
                          name: mysql-min
                    - name: MYSQL_HOST
                      value: mysql-min
                  command:
                    - /bin/sh
                    - -c
                    - |
                      set -ex
                      mysqldump --host=$MYSQL_HOST --user=$MYSQL_ROOT_PASSWORD \
                                --password=$mysql-root-password \
                                --routines --databases mall --single-transaction \
                                > /mysql-backup/mysql-`date +"%Y%m%d"`.sql
                  volumeMounts:
                    - name: mysql-min-backup
                      mountPath: /mysql-min-backup
              restartPolicy: OnFailure
              volumes:
                - name: mysql-min-backup
                  persistentVolumeClaim:
                    claimName: mysql-min-backup

## 小结 ##

Kubernetes 很多看起来比较“繁琐”的设计的主要目的，都是希望为开发者提供更多的“可扩展性”，给使用者带来更多的“稳定性”和“安全感”。这两个能力的高低，是衡量开源基础设施项目水平的重要标准。 示例中揉合 Kubernetes 多项技术，构建了一个复杂且可做生产使用的单实例数据库。

本文源码：

*  [blog-example/Kubernetes/k8s-mysql-pv-local at master · zuozewei/blog-example · GitHub][blog-example_Kubernetes_k8s-mysql-pv-local at master _ zuozewei_blog-example _ GitHub]

## 参考资料： ##

\[1\]：《深入剖析Kubernetes》

**[点击关注，第一时间了解华为云新鲜技术~][Link 1]**

[Kubernetes _ MySQL]: https://link.zhihu.com/?target=https%3A//bbs.huaweicloud.com/blogs/302931%3Futm_source%3Dzhihu%26utm_medium%3Dbbs-ex%26utm_campaign%3Dother%26utm_content%3Dcontent
[blog-example_Kubernetes_k8s-mysql-pv-local at master _ zuozewei_blog-example _ GitHub]: https://github.com/zuozewei/blog-example/tree/master/Kubernetes/k8s-mysql-pv-local
[Link 1]: https://link.zhihu.com/?target=https%3A//bbs.huaweicloud.com/blogs%3Futm_source%3Dzhihu%26utm_medium%3Dbbs-ex%26utm_campaign%3Dother%26utm_content%3Dcontent