在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的負載均衡器和服務網絡

該體系架構以下所示：

在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實例。 咱們先定義咱們的狀態集：

• 建立三個pods並將它們註冊到MySQL服務上。
• 按照下列模版定義每一個pod：
  • 爲主機MySQL服務器建立初始化容器，命名爲init-mysql.
  • 給這個容器使用mysql:5.7鏡像
  • 運行一個bash腳原本啓動xtrabackup
  • 爲配置文件和configmap掛載兩個新卷
• 爲主機MySQL服務器建立初始化容器，命名爲clone-mysql.
  • 爲該容器使用Google Cloud Registry的xtrabackup:1.0鏡像
  • 運行bash腳原本克隆上一個同級的現有xtrabackups
  • 爲數據和配置文件掛在兩個新卷
  • 該容器有效地託管克隆的數據，便於新的附屬容器能夠獲取它
• 爲附屬MySQL服務器建立基本容器
  • 建立一個MySQL附屬容器，配置它鏈接到MySQL主機
  • 建立附屬xtrabackup容器，配置它鏈接到xtrabackup主機
• 建立一個卷聲明模板來描述每一個卷，每一個卷是一個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時得到一些驚喜的體驗，固然，但願你的運行一切正常。