怎么在Kubernetes上運行高可用的WordPress和MySQL

小編給大家分享一下怎么在Kubernetes上運行高可用的WordPress和MySQL，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

WordPress是用于編輯和發布Web內容的主流平臺。在本教程中，我將逐步介紹如何使用Kubernetes來構建高可用性（HA）WordPress部署。

WordPress由兩個主要組件組成：WordPress PHP服務器和用于存儲用戶信息、帖子和網站數據的數據庫。我們需要讓整個應用程序中這兩個組件在高可用的同時都具備容錯能力。

在硬件和地址發生變化的時候，運行高可用服務可能會很困難：非常難維護。借助Kubernetes以及其強大的網絡組件，我們可以部署高可用的WordPress站點和MySQL數據庫，而無需（幾乎無需）輸入單個IP地址。

在本教程中，我將向你展示如何在Kubernetes中創建存儲類、服務、配置映射和集合，如何運行高可用MySQL，以及如何將高可用WordPress集群掛載到數據庫服務上。如果你還沒有Kubernetes集群，你可以在Amazon、Google或者Azure上輕松找到并且啟動它們，或者在任意的服務器上使用Rancher Kubernetes Engine (RKE)

架構概述

現在我來簡要介紹一下我們將要使用的技術及其功能：
WordPress應用程序文件的存儲：具有GCE持久性磁盤備份的NFS存儲
數據庫集群：帶有用于奇偶校驗的xtrabackup的MySQL
應用程序級別：掛載到NFS存儲的WordPress DockerHub映像
負載均衡和網絡：基于Kubernetes的負載均衡器和服務網絡

該體系架構如下所示：

在K8s中創建存儲類、服務和配置映射

在Kubernetes中，狀態集提供了一種定義pod初始化順序的方法。我們將使用一個有狀態的MySQL集合，因為它能確保我們的數據節點有足夠的時間在啟動時復制先前pods中的記錄。我們配置這個狀態集的方式可以讓MySQL主機在其他附屬機器之前先啟動，因此當我們擴展時，可以直接從主機將克隆發送到附屬機器上。

首先，我們需要創建一個持久卷存儲類和配置映射，以根據需要應用主從配置。我們使用持久卷，避免數據庫中的數據受限于集群中任何特定的pods。這種方式可以避免數據庫在MySQL主機pod丟失的情況下丟失數據，當主機pod丟失時，它可以重新連接到帶xtrabackup的附屬機器，并將數據從附屬機器拷貝到主機中。MySQL的復制負責主機-附屬的復制，而xtrabackup負責附屬-主機的復制。

要動態分配持久卷，我們使用GCE持久磁盤創建存儲類。不過，Kubernetes提供了各種持久性卷的存儲方案：

# storage-class.yamlkind: StorageClassapiVersion: storage.k8s.io/v1metadata:
 name: slowprovisioner: kubernetes.io/gce-pdparameters:
 type: pd-standard  zone: us-central1-a

創建類，并且使用指令：$ kubectl create -f storage-class.yaml部署它。

接下來，我們將創建configmap，它指定了一些在MySQL配置文件中設置的變量。這些不同的配置由pod本身選擇有關，但它們也為我們提供了一種便捷的方式來管理潛在的配置變量。

創建名為mysql-configmap.yaml的YAML文件來處理配置，如下：

# mysql-configmap.yamlapiVersion: v1kind: ConfigMapmetadata:
 name: mysql  labels:
   app: mysqldata:
 master.cnf: |    # Apply this config only on the master.
   [mysqld]
   log-bin
   skip-host-cache
   skip-name-resolve  slave.cnf: |    # Apply this config only on slaves.
   [mysqld]
   skip-host-cache
   skip-name-resolve

創建configmap并使用指令：$ kubectl create -f mysql-configmap.yaml
來部署它。

接下來我們要設置服務以便MySQL pods可以互相通信，并且我們的WordPress pod可以使用mysql-services.yaml與MySQL通信。這也為MySQL服務啟動了服務負載均衡器。

# mysql-services.yaml# Headless service for stable DNS entries of StatefulSet members.apiVersion: v1kind: Servicemetadata:
 name: mysql  labels:
   app: mysqlspec:
 ports:
 - name: mysql    port: 3306  clusterIP: None  selector:
   app: mysql

通過此服務聲明，我們就為實現一個多寫入、多讀取的MySQL實例集群奠定了基礎。這種配置是必要的，每個WordPress實例都可能寫入數據庫，所以每個節點都必須準備好讀寫。

執行命令 $ kubectl create -f mysql-services.yaml來創建上述的服務。

到這為止，我們創建了卷聲明存儲類，它將持久磁盤交給所有請求它們的容器，我們配置了configmap，在MySQL配置文件中設置了一些變量，并且我們配置了一個網絡層服務，負責對MySQL服務器請求的負載均衡。上面說的這些只是準備有狀態集的框架， MySQL服務器實際在哪里運行，我們接下來將繼續探討。

配置有狀態集的MySQL

本節中，我們將編寫一個YAML配置文件應用于使用了狀態集的MySQL實例。
我們先定義我們的狀態集：
1, 創建三個pods并將它們注冊到MySQL服務上。
2, 按照下列模版定義每個pod：
? 為主機MySQL服務器創建初始化容器，命名為init-mysql.
?  給這個容器使用mysql:5.7鏡像
?  運行一個bash腳本來啟動xtrabackup
?  為配置文件和configmap掛載兩個新卷

3, 為主機MySQL服務器創建初始化容器，命名為clone-mysql.
?  為該容器使用Google Cloud Registry的xtrabackup:1.0鏡像
? 運行bash腳本來克隆上一個同級的現有xtrabackups
?  為數據和配置文件掛在兩個新卷
?  該容器有效地托管克隆的數據，便于新的附屬容器可以獲取它

4, 為附屬MySQL服務器創建基本容器
?  創建一個MySQL附屬容器，配置它連接到MySQL主機
?  創建附屬xtrabackup容器，配置它連接到xtrabackup主機

5, 創建一個卷聲明模板來描述每個卷，每個卷是一個10GB的持久磁盤
下面的配置文件定義了MySQL集群的主節點和附屬節點的行為，提供了運行附屬客戶端的bash配置，并確保在克隆之前主節點能夠正常運行。附屬節點和主節點分別獲得他們自己的10GB卷，這是他們在我們之前定義的持久卷存儲類中請求的。

apiVersion: apps/v1beta1kind: StatefulSetmetadata:
 name: mysqlspec:
 selector:
   matchLabels:
     app: mysql  serviceName: mysql  replicas: 3  template:
   metadata:
     labels:
       app: 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/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: 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 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        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 ]]; then            # XtraBackup already generated a partial "CHANGE MASTER TO" query
           # because we're cloning from an existing slave.
           mv xtrabackup_slave_info change_master_to.sql.in            # Ignore xtrabackup_binlog_info in this case (it's useless).
           rm -f 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 xtrabackup_binlog_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"
           # In case of container restart, attempt this at-most-once.
           mv change_master_to.sql.in change_master_to.sql.orig
           mysql -h 127.0.0.1 <<EOF
         $(<change_master_to.sql.orig),
           MASTER_HOST='mysql-0.mysql',
           MASTER_USER='root',
           MASTER_PASSWORD='',
           MASTER_CONNECT_RETRY=10;
         START SLAVE;
         EOF
         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-statefulset.yaml，輸入kubectl="" create="" -f="" mysql-statefulset.yaml并讓kubernetes部署你的數據庫。
現在當你調用$="" kubectl="" get="" pods，你應該看到3個pods啟動或者準備好，其中每個pod上都有兩個容器。主節點pod表示為mysql-0，而附屬的pods為mysql-1和mysql-2.讓pods執行幾分鐘來確保xtrabackup服務在pod之間正確同步，然后進行wordpress的部署。
您可以檢查單個容器的日志來確認沒有錯誤消息拋出。 查看日志的命令為$="" logs="" <container_name="">

主節點xtrabackup容器應顯示來自附屬的兩個連接，并且日志中不應該出現任何錯誤。

部署高可用的WordPress

整個過程的最后一步是將我們的WordPress pods部署到集群上。為此我們希望為WordPress的服務和部署進行定義。

為了讓WordPress實現高可用，我們希望每個容器運行時都是完全可替換的，這意味著我們可以終止一個，啟動另一個而不需要對數據或服務可用性進行修改。我們也希望能夠容忍至少一個容器的失誤，有一個冗余的容器負責處理slack。

WordPress將重要的站點相關數據存儲在應用程序目錄/var/www/html中。對于要為同一站點提供服務的兩個WordPress實例，該文件夾必須包含相同的數據。

當運行高可用WordPress時，我們需要在實例之間共享/var/www/html文件夾，因此我們定義一個NGS服務作為這些卷的掛載點。
下面是設置NFS服務的配置，我提供了純英文的版本：

使用指令$ kubectl create -f nfs.yaml部署NFS服務?，F在，我們需要運行$ kubectl describe services nfs-server獲得IP地址，這在后面會用到。

注意：將來，我們可以使用服務名稱講這些綁定在一起，但現在你需要對IP地址進行硬編碼。

# wordpress.yamlapiVersion: v1kind: Servicemetadata:
 name: wordpress  labels:
   app: wordpressspec:
 ports:
   - port: 80  selector:
   app: wordpress    tier: frontend  type: LoadBalancer---apiVersion: v1kind: PersistentVolumemetadata:
 name: nfsspec:
 capacity:
   storage: 20G  accessModes:
   - ReadWriteMany  nfs:
   # FIXME: use the right IP
   server: <ip of="" the="" nfs="" service="">    path: "/"---apiVersion: v1kind: PersistentVolumeClaimmetadata:
 name: nfsspec:
 accessModes:
   - ReadWriteMany  storageClassName: ""
 resources:
   requests:
     storage: 20G---apiVersion: apps/v1beta1 # for versions before 1.8.0 use apps/v1beta1kind: Deploymentmetadata:
 name: wordpress  labels:
   app: wordpressspec:
 selector:
   matchLabels:
     app: wordpress      tier: frontend  strategy:
   type: Recreate  template:
   metadata:
     labels:
       app: wordpress        tier: frontend    spec:
     containers:
     - image: wordpress:4.9-apache        name: wordpress        env:
       - name: WORDPRESS_DB_HOST          value: mysql        - name: WORDPRESS_DB_PASSWORD          value: ""
       ports:
       - containerPort: 80          name: wordpress        volumeMounts:
       - name: wordpress-persistent-storage          mountPath: /var/www/html      volumes:
     - name: wordpress-persistent-storage        persistentVolumeClaim:
           claimName: nfs

我們現在創建了一個持久卷聲明，和我們之前創建的NFS服務建立映射，然后將卷附加到WordPress pod上，即/var/www/html根目錄，這也是WordPress安裝的地方。這里保留了集群中WordPress pods的所有安裝和環境。有了這些配置，我們就可以對任何WordPress節點進行啟動和拆除，而數據能夠留下來。因為NFS服務需要不斷使用物理卷，該卷將保留下來，并且不會被回收或錯誤分配。

使用指令$ kubectl create -f wordpress.yaml部署WordPress實例。默認部署只會運行一個WordPress實例，可以使用指令$ kubectl scale --replicas=<number of="" replicas="">
deployment/wordpress擴展WordPress實例數量。

要獲得WordPress服務負載均衡器的地址，你需要輸入$ kubectl get services wordpress
并從結果中獲取EXTERNAL-IP字段來導航到WordPress。

彈性測試

OK，現在我們已經部署好了服務，那我們來拆除一下它們，看看我們的高可用架構如何處理這些混亂。在這種部署方式中，唯一剩下的單點故障就是NFS服務（原因總結在文末結論中）。你應該能夠測試其他任何的服務來了解應用程序是如何響應的?，F在我已經啟動了WordPress服務的三個副本，以及MySQL服務中的一個主兩個附屬節點。

首先，我們先kill掉其他而只留下一個WordPress節點，來看看應用如何響應：$ kubectl scale --replicas=1 deployment/wordpress現在我們應該看到WordPress部署的pod數量有所下降。$ kubectl get pods應該能看到WordPress pods的運行變成了1/1。

點擊WordPress服務IP，我們將看到與之前一樣的站點和數據庫。如果要擴展復原，可以使用$ kubectl scale --replicas=3 deployment/wordpress再一次，我們可以看到數據包留在了三個實例中。

下面測試MySQL的狀態集，我們使用指令縮小備份的數量：$ kubectl scale statefulsets mysql --replicas=1我們會看到兩個附屬從該實例中丟失，如果主節點在此時丟失，它所保存的數據將保存在GCE持久磁盤上。不過就必須手動從磁盤恢復數據。

如果所有三個MySQL節點都關閉了，當新節點出現時就無法復制。但是，如果一個主節點發生故障，一個新的主節點就會自動啟動，并且通過xtrabackup重新配置來自附屬節點的數據。因此，在運行生產數據庫時，我不建議以小于3的復制系數來運行。在結論段中，我們會談談針對有狀態數據有什么更好的解決方案，因為Kubernetes并非真正是為狀態設計的。

結論和建議

到現在為止，你已經完成了在Kubernetes構建并部署高可用WordPress和MySQL的安裝！

不過盡管取得了這樣的效果，你的研究之旅可能還遠沒有結束?？赡苣氵€沒注意到，我們的安裝仍然存在著單點故障：NFS服務器在WordPress pods之間共享/var/www/html目錄。這項服務代表了單點故障，因為如果它沒有運行，在使用它的pods上html目錄就會丟失。教程中我們為服務器選擇了非常穩定的鏡像，可以在生產環境中使用，但對于真正的生產部署，你可以考慮使用GlusterFS對WordPress實例共享的目錄開啟多讀多寫。

這個過程涉及在Kubernetes上運行分布式存儲集群，實際上這不是Kubernetes構建的，因此盡管它運行良好，但不是長期部署的理想選擇。

對于數據庫，我個人建議使用托管的關系數據庫服務來托管MySQL實例，因為無論是Google的CloudSQL還是AWS的RDS，它們都以更合理的價格提供高可用和冗余處理，并且不需擔心數據的完整性。Kuberntes并不是圍繞有狀態的應用程序設計的，任何建立在其中的狀態更多都是事后考慮。目前有大量的解決方案可以在選擇數據庫服務時提供所需的保證。

也就是說，上面介紹的是一種理想的流程，由Kubernetes教程、web中找到的例子創建一個有關聯的現實的Kubernetes例子，并且包含了Kubernetes 1.8.x中所有的新特性。

以上是“怎么在Kubernetes上運行高可用的WordPress和MySQL”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！