摘要：Kubernetes 很多看起来比拟“繁琐”的设计的次要目标，都是心愿为开发者提供更多的“可扩展性”，给使用者带来更多的“稳定性”和“安全感”。
本文分享自华为云社区《如何在 Kubernetes 集群中搭建一个简单的 MySQL 数据库？》，作者：zuozewei 。
前言
理论生产环境中，为了稳固和高可用，运维团队个别不会把 MySQL 数据库部署在 Kubernetes 集群中，个别是用云厂商的数据库或者本人在高性能机器（如裸金属服务器）上搭建。
然而，对于测试开发环境，咱们齐全能够把 MySQL 部署到各自的 Kubernetes 集群中,十分有助于晋升运维效率，而且还有助于Kubernetes 应用的教训积攒。
繁难部署
如下所示，咱们仅需设置 root 用户明码（环境变量 MYSQL_ROOT_PASSWORD）， 便可轻松的应用 MySQL 官网镜像构建一个 MySQL 数据库。
apiVersion: extensions/v1beta1kind: Deploymentmetadata: labels: app: mysql-min name: mysql-minspec: 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: v1kind: Servicemetadata: labels: app: mysql-min release: mysql-min name: mysql-min namespace: defaultspec: 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 AGEmysql-min-5b5668c448-t44ml 1/1 Running 0 3h# 通过本机拜访# kubectl exec -it mysql-min-5b5668c448-t44ml -- mysql -uroot -padmin@123mysql> select 1;+---+| 1 |+---+| 1 |+---+# 集群外部通过mysql service拜访：# kubectl exec -it mysql-min-5b5668c448-t44ml -- mysql -uroot -padmin@123 -hmysqlmysql> 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/$voldone须要留神的是，如果你心愿其余节点也能反对 Local Persistent Volume 的话，那就须要为它们也执行上述操作，并且确保这些磁盘的名字（vol1、vol2 等）都不反复。接下来，咱们就能够为这些本地磁盘定义对应的 PV 了，如下所示：
apiVersion: v1kind: PersistentVolumemetadata: name: mysql-min-pv-local namespace: defaultspec: 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: StorageClassapiVersion: storage.k8s.io/v1metadata: 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: v1items:- 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: 1Gikind: List能够看到，这个 PVC 没有任何特地的中央。惟一须要留神的是，它申明的 storageClassName 是 mysql-min-storageclass-local。所以，未来 Kubernetes 的 Volume Controller 看到这个 PVC 的时候，不会为它进行绑定操作。
最初，咱们创立 Local Persistent Volume 资源文件：
kubectl apply -f mysql-min-pv-local.yamlkubectl apply -f mysql-min-storageclass-local.yamlkubectl 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: v1kind: ConfigMapmetadata: name: mysql-configdata: 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: v1data: #将mysql数据库的所有user的password配置到secret，对立治理 mysql-password: YWRtaW4= mysql-root-password: OVplTmswRGdoSA==kind: Secretmetadata: 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: OpaqueSecret 创立实现后，咱们将用户明文明码从 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/v1kind: Deploymentmetadata: annotations: deployment.kubernetes.io/revision: "1" generation: 1 labels: app: mysql-min release: mysql-min name: mysql-min namespace: defaultspec: 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 AGEpod/mysql-min-f9c9b7b5-q9br4 1/1 Running 6 14d# Service：NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEservice/mysql-min NodePort 10.96.184.130 <none> 3306:30336/TCP 16d# MySQL Deployment：NAME READY UP-TO-DATE AVAILABLE AGEdeployment.apps/mysql-min 1/1 1 1 16d# 正本集ReplicaSet被Deployment调用，其是主动生成的NAME DESIRED CURRENT READY AGEreplicaset.apps/mysql-min-587cf9fd48 0 0 0 16dreplicaset.apps/mysql-min-589bf8cdc5 0 0 0 16dreplicaset.apps/mysql-min-6b7447c7dd 0 0 0 14dreplicaset.apps/mysql-min-6cc9887459 0 0 0 16dreplicaset.apps/mysql-min-7759579d77 0 0 0 16dreplicaset.apps/mysql-min-84d4d6bd56 0 0 0 15dreplicaset.apps/mysql-min-f9c9b7b5 1 1 1 14d# Pvc：NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpersistentvolumeclaim/mysql-min Bound mysql-min-pv-local 5Gi RWO mysql-min-storageclass-local 16d# Secret：NAME TYPE DATA AGEsecret/mysql-min Opaque 2 16d定期主动备份
思考到数据安全性，咱们定期备份数据库，在K8S集群中，咱们可配置 CronJob 实现主动备份作业。首先，创立一个长久化存储供备份用：
apiVersion: v1items:- 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: 1Gikind: List继而，配置理论的自动化作业工作，如下所示，每天凌晨零点点将应用 mysqldump 备份 mall 数据库。
apiVersion: batch/v1beta1kind: CronJobmetadata: name: mysql-backupspec: 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 多项技术，构建了一个简单且可做生产应用的单实例数据库。
本文源码：https://github.com/zuozewei/b...
参考资料：
[1]：《深刻分析Kubernetes》
点击关注，第一工夫理解华为云陈腐技术~