摘要：Kubernetes 很多看起來比較“繁瑣”的設計的主要目的，都是希望為開發者提供更多的“可擴充套件性”，給使用者帶來更多的“穩定性”和“安全感”。
本文分享自華為雲社群《如何在 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: 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/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 多項技術，構建了一個複雜且可做生產使用的單例項資料庫。
本文原始碼：https://github.com/zuozewei/b...
參考資料：
[1]：《深入剖析Kubernetes》