執行複製的具狀態應用程式

本頁說明如何使用 StatefulSet 執行複寫的有狀態應用程式。此應用程式是複寫的 MySQL 資料庫。範例拓撲具有單一主要伺服器和多個複本，使用非同步的基於列的複寫。

注意

這不是生產環境組態。MySQL 設定仍保留不安全的預設值，以將重點放在 Kubernetes 中執行有狀態應用程式的一般模式上。

開始之前

您需要有一個 Kubernetes 叢集，並且必須設定 kubectl 命令列工具以與您的叢集通訊。建議在至少有兩個節點且不充當控制平面主機的叢集上執行本教學課程。如果您還沒有叢集，可以使用 minikube 建立一個，或者您可以使用以下 Kubernetes playground 之一
- Killercoda
- Play with Kubernetes
您需要有一個具有預設 StorageClass 的動態 PersistentVolume 佈建器，或者靜態佈建 PersistentVolumes 以滿足此處使用的 PersistentVolumeClaims。
本教學課程假設您熟悉 PersistentVolumes 和 StatefulSets，以及其他核心概念，例如 Pods、服務和 ConfigMaps。
對 MySQL 有一些熟悉度會有幫助，但本教學課程旨在介紹一般模式，這些模式對於其他系統也應該很有用。
您正在使用預設命名空間或另一個不包含任何衝突物件的命名空間。
您需要有 AMD64 相容的 CPU。

目標

使用 StatefulSet 部署複寫的 MySQL 拓撲。
傳送 MySQL 用戶端流量。
觀察對停機時間的抵抗能力。
向上和向下擴展 StatefulSet。

部署 MySQL

範例 MySQL 部署包含 ConfigMap、兩個服務和一個 StatefulSet。

建立 ConfigMap

從以下 YAML 組態檔案建立 ConfigMap

application/mysql/mysql-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql
  labels:
    app: mysql
    app.kubernetes.io/name: mysql
data:
  primary.cnf: |
    # Apply this config only on the primary.
    [mysqld]
    log-bin    
  replica.cnf: |
    # Apply this config only on replicas.
    [mysqld]
    super-read-only

kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml

此 ConfigMap 提供 my.cnf 覆寫，讓您可以獨立控制主要 MySQL 伺服器及其複本上的組態。在本例中，您希望主要伺服器能夠為複本提供複寫日誌，並且您希望複本拒絕任何非透過複寫而來的寫入。

ConfigMap 本身沒有任何特殊之處會導致不同部分應用於不同的 Pod。每個 Pod 在初始化時都會根據 StatefulSet 控制器提供的資訊，決定要查看哪個部分。

建立服務

從以下 YAML 組態檔案建立服務

application/mysql/mysql-services.yaml

# Headless service for stable DNS entries of StatefulSet members.
apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
    app.kubernetes.io/name: mysql
spec:
  ports:
  - name: mysql
    port: 3306
  clusterIP: None
  selector:
    app: mysql
---
# Client service for connecting to any MySQL instance for reads.
# For writes, you must instead connect to the primary: mysql-0.mysql.
apiVersion: v1
kind: Service
metadata:
  name: mysql-read
  labels:
    app: mysql
    app.kubernetes.io/name: mysql
    readonly: "true"
spec:
  ports:
  - name: mysql
    port: 3306
  selector:
    app: mysql

kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml

無頭服務為 DNS 條目提供了一個位置，StatefulSet 控制器為屬於該集合的每個 Pod 建立這些條目。由於無頭服務命名為 mysql，因此可以透過從同一個 Kubernetes 叢集和命名空間中的任何其他 Pod 解析 <pod-name>.mysql 來存取 Pod。

用戶端服務 (Client Service)，名為 mysql-read，是一個正常的服務 (Service)，具有自己的叢集 IP 位址，可將連線分散到所有回報為「就緒 (Ready)」狀態的 MySQL Pod。

請注意，只有讀取查詢可以使用負載平衡的用戶端服務。由於只有一個主要 MySQL 伺服器，用戶端應直接連線到主要 MySQL Pod（透過其在 Headless Service 中的 DNS 項目）以執行寫入操作。

建立 StatefulSet

最後，從下列 YAML 組態檔建立 StatefulSet

application/mysql/mysql-statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
      app.kubernetes.io/name: mysql
  serviceName: mysql
  replicas: 3
  template:
    metadata:
      labels:
        app: mysql
        app.kubernetes.io/name: mysql
    spec:
      initContainers:
      - name: init-mysql
        image: mysql:5.7
        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/primary.cnf /mnt/conf.d/
          else
            cp /mnt/config-map/replica.cnf /mnt/conf.d/
          fi          
        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
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Skip the clone if data already exists.
          [[ -d /var/lib/mysql/mysql ]] && exit 0
          # Skip the clone on primary (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
        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: gcr.io/google-samples/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 replica. (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 primary. 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

kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml

您可以執行以下指令來監看啟動進度

kubectl get pods -l app=mysql --watch

稍待片刻後，您應該會看到所有 3 個 Pod 都變成 Running 狀態

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

按下 Ctrl+C 以取消監看。

注意

如果您沒有看到任何進度，請確認您已啟用動態 PersistentVolume 佈建器 (provisioner)，如先決條件中所述。

此 Manifest 運用了多種技術來管理作為 StatefulSet 一部分的具狀態 Pod。下一節將重點介紹其中一些技術，以解釋當 StatefulSet 建立 Pod 時會發生什麼事。

理解具狀態 Pod 初始化

StatefulSet 控制器一次啟動一個 Pod，依序按照其序數索引 (ordinal index)。它會等到每個 Pod 回報為「就緒 (Ready)」狀態後，才啟動下一個。

此外，控制器會為每個 Pod 指派一個唯一且穩定的名稱，格式為 <statefulset-name>-<ordinal-index>，這會產生名為 mysql-0、mysql-1 和 mysql-2 的 Pod。

上述 StatefulSet Manifest 中的 Pod 範本利用這些屬性來執行 MySQL 複寫的有序啟動。

產生組態

在啟動 Pod Spec 中的任何容器之前，Pod 會先執行任何已定義順序的初始化容器 (init containers)。

第一個初始化容器，名為 init-mysql，會根據序數索引產生特殊的 MySQL 組態檔。

此腳本 (script) 透過從 Pod 名稱的末尾提取序數索引來確定其自身的序數索引，Pod 名稱由 hostname 命令傳回。然後，它將序數（帶有數值偏移以避免保留值）儲存到 MySQL conf.d 目錄中名為 server-id.cnf 的檔案中。這將 StatefulSet 提供的唯一、穩定身分轉換為 MySQL 伺服器 ID 的領域，後者也需要相同的屬性。

init-mysql 容器中的腳本也會從 ConfigMap 套用 primary.cnf 或 replica.cnf，方法是將內容複製到 conf.d 中。由於範例拓撲 (topology) 由單一主要 MySQL 伺服器和任意數量的副本 (replicas) 組成，因此腳本將序數 0 指派為主要伺服器，將其他所有伺服器指派為副本。結合 StatefulSet 控制器的部署順序保證，這確保了主要 MySQL 伺服器在建立副本之前已處於「就緒 (Ready)」狀態，以便它們可以開始複寫。

複製現有資料

一般來說，當新的 Pod 作為副本加入集合時，它必須假設主要 MySQL 伺服器可能已經有資料。它也必須假設複寫日誌可能不會追溯到時間的開始。這些保守的假設是允許運作中的 StatefulSet 隨著時間推移擴展和縮減，而不是固定在其初始大小的關鍵。

第二個初始化容器，名為 clone-mysql，會在副本 Pod 首次在空的 PersistentVolume 上啟動時執行複製操作。這表示它會從另一個運作中的 Pod 複製所有現有資料，使其本機狀態足夠一致，可以開始從主要伺服器進行複寫。

MySQL 本身沒有提供執行此操作的機制，因此範例使用了名為 Percona XtraBackup 的熱門開放原始碼工具。在複製期間，來源 MySQL 伺服器的效能可能會降低。為了盡量減少對主要 MySQL 伺服器的影響，腳本指示每個 Pod 從序數索引小 1 的 Pod 進行複製。這是可行的，因為 StatefulSet 控制器始終確保 Pod N 在啟動 Pod N+1 之前處於「就緒 (Ready)」狀態。

啟動複寫

在初始化容器成功完成後，常規容器開始執行。MySQL Pod 由一個執行實際 mysqld 伺服器的 mysql 容器，以及一個充當邊車 (sidecar)的 xtrabackup 容器組成。

xtrabackup 邊車會查看複製的資料檔案，並判斷是否有必要在副本上初始化 MySQL 複寫。如果需要，它會等待 mysqld 準備就緒，然後使用從 XtraBackup 複製檔案中提取的複寫參數執行 CHANGE MASTER TO 和 START SLAVE 命令。

一旦副本開始複寫，它就會記住其主要 MySQL 伺服器，並且如果伺服器重新啟動或連線中斷，它會自動重新連線。此外，由於副本在其穩定的 DNS 名稱 (mysql-0.mysql) 中尋找主要伺服器，即使主要伺服器由於重新排程而獲得新的 Pod IP 位址，它們也會自動找到主要伺服器。

最後，在啟動複寫後，xtrabackup 容器會監聽來自其他請求資料複製的 Pod 的連線。此伺服器會無限期地保持運作，以防 StatefulSet 擴展，或者以防下一個 Pod 遺失其 PersistentVolumeClaim 並需要重新執行複製。

傳送用戶端流量

您可以透過執行帶有 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 test;
CREATE TABLE test.messages (message VARCHAR(250));
INSERT INTO test.messages VALUES ('hello');
EOF

使用主機名稱 mysql-read 將測試查詢傳送到任何回報為「就緒 (Ready)」狀態的伺服器

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

您應該會得到類似這樣的輸出

Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
+---------+
| message |
+---------+
| hello   |
+---------+
pod "mysql-client" deleted

為了示範 mysql-read 服務將連線分散到多個伺服器，您可以迴圈執行 SELECT @@server_id

kubectl run mysql-client-loop --image=mysql:5.7 -i -t --rm --restart=Never --\
  bash -ic "while sleep 1; do mysql -h mysql-read -e 'SELECT @@server_id,NOW()'; done"

您應該會看到回報的 @@server_id 隨機變更，因為每次嘗試連線時都可能選取不同的端點。

+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         100 | 2006-01-02 15:04:05 |
+-------------+---------------------+
+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         102 | 2006-01-02 15:04:06 |
+-------------+---------------------+
+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         101 | 2006-01-02 15:04:07 |
+-------------+---------------------+

當您想要停止迴圈時，可以按下 Ctrl+C，但在另一個視窗中保持執行狀態很有用，這樣您就可以看到後續步驟的效果。

模擬 Pod 和節點故障

為了示範從副本集區而不是單一伺服器讀取時可用性的提高，請保持上述 SELECT @@server_id 迴圈運作，同時強制 Pod 退出「就緒 (Ready)」狀態。

中斷就緒探針 (Readiness Probe)

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 應回報其容器之一未處於「就緒 (Ready)」狀態，您可以透過執行以下指令來檢查

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

刪除 Pod

StatefulSet 也會重新建立已刪除的 Pod，類似於 ReplicaSet 對於無狀態 Pod 的操作。

kubectl delete pod mysql-2

StatefulSet 控制器注意到不再存在 mysql-2 Pod，並建立一個具有相同名稱且連結到相同 PersistentVolumeClaim 的新 Pod。您應該會看到伺服器 ID 102 從迴圈輸出中消失一段時間，然後自行返回。

排空節點 (Drain a Node)

如果您的 Kubernetes 叢集有多個節點，您可以透過發出排空 (drain)來模擬節點停機時間（例如，當節點升級時）。

首先確定其中一個 MySQL Pod 位於哪個節點上

kubectl get pod mysql-2 -o wide

節點名稱應顯示在最後一欄中

NAME      READY     STATUS    RESTARTS   AGE       IP            NODE
mysql-2   2/2       Running   0          15m       10.244.5.27   kubernetes-node-9l2t

然後，執行以下命令來排空節點，這會隔離它，使其無法在那裡排程新的 Pod，然後驅逐任何現有的 Pod。將 <node-name> 替換為您在上一步中找到的節點名稱。

注意

排空節點可能會影響在同一節點上執行的其他工作負載和應用程式。僅在測試叢集中執行以下步驟。

# See above advice about impact on other workloads
kubectl drain <node-name> --force --delete-emptydir-data --ignore-daemonsets

現在您可以監看 Pod 在不同節點上重新排程

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

它應該看起來像這樣

NAME      READY   STATUS          RESTARTS   AGE       IP            NODE
mysql-2   2/2     Terminating     0          15m       10.244.1.56   kubernetes-node-9l2t
[...]
mysql-2   0/2     Pending         0          0s        <none>        kubernetes-node-fjlm
mysql-2   0/2     Init:0/2        0          0s        <none>        kubernetes-node-fjlm
mysql-2   0/2     Init:1/2        0          20s       10.244.5.32   kubernetes-node-fjlm
mysql-2   0/2     PodInitializing 0          21s       10.244.5.32   kubernetes-node-fjlm
mysql-2   1/2     Running         0          22s       10.244.5.32   kubernetes-node-fjlm
mysql-2   2/2     Running         0          30s       10.244.5.32   kubernetes-node-fjlm

同樣地，您應該會看到伺服器 ID 102 從 SELECT @@server_id 迴圈輸出中消失一段時間，然後返回。

現在取消隔離節點以使其恢復正常狀態

kubectl uncordon <node-name>

擴展副本數量

當您使用 MySQL 複寫時，您可以透過新增副本來擴展讀取查詢容量。對於 StatefulSet，您可以使用單一命令來實現此目的

kubectl scale statefulset mysql  --replicas=5

執行以下指令來監看新 Pod 的啟動

kubectl get pods -l app=mysql --watch

一旦它們啟動，您應該會看到伺服器 ID 103 和 104 開始出現在 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"

Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
+---------+
| message |
+---------+
| hello   |
+---------+
pod "mysql-client" deleted

縮減規模也很順暢

kubectl scale statefulset mysql --replicas=3

注意

雖然擴展會自動建立新的 PersistentVolumeClaim，但縮減不會自動刪除這些 PVC。

這讓您可以選擇保留那些已初始化的 PVC，以加快縮減規模的速度，或在刪除它們之前提取資料。

您可以透過執行以下指令來查看這一點

kubectl get pvc -l app=mysql

這顯示所有 5 個 PVC 仍然存在，儘管已將 StatefulSet 縮減到 3 個

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

清除

在迴圈的終端機中按下 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
```
當以上指令傳回時，您將知道 Pod 已終止
```
No resources found.
```
刪除 ConfigMap、服務 (Services) 和 PersistentVolumeClaims。
```
kubectl delete configmap,service,pvc -l app=mysql
```
如果您手動佈建 PersistentVolumes，您還需要手動刪除它們，並釋放底層資源。如果您使用動態佈建器，它會在看到您刪除 PersistentVolumeClaims 時自動刪除 PersistentVolumes。一些動態佈建器（例如 EBS 和 PD 的佈建器）也會在刪除 PersistentVolumes 時釋放底層資源。

下一步

深入瞭解擴展 StatefulSet。
深入瞭解偵錯 StatefulSet。
深入瞭解刪除 StatefulSet。
深入瞭解強制刪除 StatefulSet Pod。
在 Helm Charts 儲存庫中尋找其他具狀態應用程式範例。

上次修改時間：2024 年 10 月 08 日晚上 10:10 PST：Update content/en/docs/tasks/run-application/run-replicated-stateful-application.md (7b8fd10630)