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

標籤：WordPress   MySQL   Kubernetes   

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的負載平衡器和服務網路

該體系架構如下所示：

在Kubernetes中建立儲存類、服務和配置映射

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

首先，我們需要建立一個持久卷儲存類和配置映射，以根據需要應用主從配置。

      我們使用持久卷，避免資料庫中的資料受限於叢集中任何特定的pods。這種方式可以避免資料庫在MySQL主機pod丟失的情況下遺失資料，當主機pod丟失時，它可以重新串連到帶xtrabackup的附屬機器，並將資料從附屬機器拷貝到主機中。MySQL的複製負責主機-附屬的複製，而xtrabackup負責附屬-主機的複製。

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

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

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

建立名為mysql-configmap.yaml的YAML檔案來處理配置，如下：

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

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

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

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

到這為止，我們建立了卷聲明儲存類，它將持久磁碟交給所有請求它們的容器，我們配置了configmap，在MySQL設定檔中設定了一些變數，並且我們配置了一個網路層服務，負責對MySQL伺服器請求的負載平衡。上面說的這些只是準備有狀態集的架構， MySQL伺服器實際在哪裡運行，我們接下來將繼續探討。

配置有狀態集的MySQL

本節中，我們將編寫一個YAML設定檔應用於使用了狀態集的MySQL執行個體。

我們先定義我們的狀態集：

l  建立三個pods並將它們註冊到MySQL服務上。

l  按照下列模版定義每個pod：

n  為主機MySQL伺服器建立初始化容器，命名為init-mysql.

n  給這個容器使用mysql:5.7鏡像

n  運行一個bash指令碼來啟動xtrabackup

n  為設定檔和configmap掛載兩個新卷

l  為主機MySQL伺服器建立初始化容器，命名為clone-mysql.

n  為該容器使用Google Cloud Registry的xtrabackup:1.0鏡像

n  運行bash指令碼來複製上一個同級的現有xtrabackups

n  為資料和設定檔掛在兩個新卷

n  該容器有效地託管複製的資料，便於新的附屬容器可以擷取它

l  為附屬MySQL伺服器建立基本容器

n  建立一個MySQL附屬容器，配置它串連到MySQL主機

n  建立附屬xtrabackup容器，配置它串連到xtrabackup主機

l  建立一個卷聲明模板來描述每個卷，每個卷是一個10GB的持久磁碟

下面的設定檔定義了MySQL叢集的主節點和附屬節點的行為，提供了運行附屬用戶端的bash配置，並確保在複製之前主節點能夠正常運行。附屬節點和主節點分別獲得他們自己的10GB卷，這是他們在我們之前定義的持久卷儲存類中請求的。

將該檔案存為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的部署。

您可以檢查單個容器的日誌來確認沒有錯誤訊息拋出。 查看日誌的命令為$ kubectl logs -f -c <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服務。

現在，我們需要運行$ kubectl describe services nfs-server獲得IP地址，這在後面會用到。

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

我們現在建立了一個持久卷聲明，和我們之前建立的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服務（原因總結在文末結論中）。你應該能夠測試其他任何的服務來瞭解應用程式是如何響應的。現在我已經啟動了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中所有的新特性。

我希望通過我的指南，你能在部署WordPress和MySQL時獲得一些驚喜的體驗，當然，希望你的運行一切正常。

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