如何跨不同版本K8S，為有狀態(tài)工作負載做藍綠部署

容器的生態(tài)正在爆發(fā)！不僅僅應用層在快速變化，還有用于管理應用程序的平臺：Kubernetes，也在快速變化。這就為Ops團隊帶來了一個必須要解決的難題。IT團隊如何才能保證一款應用程序能夠在各種不同版本的Kubernetes上都能良好運行呢？


PX-Motion演示視頻：如何跨不同版本Kubernetes，為有狀態(tài)的工作負載做藍綠部署

藍-綠部署是一種專門用于解決這一問題的技術，并能夠降低生產環(huán)境部署的過程中的停機或錯誤風險。在藍綠部署場景下，用戶需要構建兩個完全相同的生產環(huán)境（分別稱為藍與綠），這兩個環(huán)境之間僅在需要部署的新的變更方面存在差異。每一次僅激活一個環(huán)境，兩個環(huán)境之間的數(shù)據傳輸也是部署過程的一部分。該技術對于不含任何數(shù)據的無狀態(tài)應用非常有效，但對于數(shù)據庫這類有狀態(tài)應用則存在一定的困難，因為用戶不得不保留兩份生產數(shù)據副本。這種情況下可能會需要使用Postgres、MySQL以及其他數(shù)據庫備份和恢復腳本，或定制化操作手冊或自動腳本等將數(shù)據從一個數(shù)據源人工移動到另一個數(shù)據源，這個過程將會非常復雜并且會耗費大量的時間。

Portworx采用PX-Motion解決了有狀態(tài)應用程序的藍綠部署過程中的數(shù)據管理問題。PX-Motion使IT團隊能夠很方便地在各種環(huán)境之間進行數(shù)據和應用配置的遷移，極大地簡化了有狀態(tài)應用的藍綠部署。

本篇博文將對PX-Motion的功能與能力進行探討。具體地說，筆者將展示如何對兩個不同版本的Kubernetes上運行的有狀態(tài)LAMP堆棧進行藍綠部署。

總結來說，我們會：

1. 將兩個Kubernetes集群（分別稱為來源集群和目標集群）配對，從而使數(shù)據、配置和Pods能夠這兩個集群之間進行轉移，這是藍綠部署的一部分。

2. 使用Kubernetes將一個LAMP堆棧部署到來源集群上，并驗證應用程序能夠運行。

3. 使用PX-Motion可以將Kubernetes的部署、加密文件、副本集、服務、持久卷、持久卷連接以及數(shù)據等，從來源集群遷移到目標集群上進行測試和驗證。在遷移完成之后，所有的Pods都能夠在來源集群上繼續(xù)運行?，F(xiàn)在我們已經有了兩個集群在運行，分別是藍色和綠色。

4. 使用Kubernetes驗證我們的應用以及自身數(shù)據是否正在目標集群上正常運行。

5. 在新集群上的部署驗證完成之后，我們就可以更新我們的負載平衡設置，從而使所有的流量指向新集群。此時藍綠部署就完成了。

我們開始吧！

安裝PX-Motion

前提條件

如果你正在嘗試PX-Migration，請確認已經滿足所有的前提條件(https://docs.portworx.com/cloud-references/migration/migration-stork/#overview)。

配對Kubernetes集群為數(shù)據遷移做準備
從來源集群(Kubernetes 1.10.3)向目標集群(Kubernetes 1.12.0)進行工作載荷遷移之前，我們需要將這兩個集群配對起來。配對的概念相當于將手機和藍牙播放器進行配對，使兩種不同的設備結合起來工作。
集群配對首先要做的是對目標集群進行配置。首先，建立對于pxctl (“pixie-cuttle”)的訪問，即Portworx CLI。下面將介紹如何在可被kubectl訪問的工作站上使用pxctl。

$ kubectl config  use-context <destination-cluster>`

$ PX_POD_DEST_CLUSTER=$(kubectl get pods --context
   <DESTINATION_CLUSTER_CONTEXT> -l name=portworx -n kube-system 
   -o jsonpath='{.items[0].metadata.name}')

$ alias pxctl_dst="kubectl exec $PX_POD_DEST_CLUSTER \
   --context <DESTINATION_CLUSTER_CONTEXT>
   -n kube-system /opt/pwx/bin/pxctl"

下一步，對目標集群對象存儲進行設置，使其準備好與來源集群進行配對。我們需要在目標集群上設置一個對象存儲端點，作為數(shù)據在遷移過程中進行分級的位置。

$ pxctl_dst -- volume create --size 100 objectstore
$ pxctl_dst -- objectstore create -v objectstore
$ pxctl_dst -- cluster token show
Token is <UUID>

下一步，創(chuàng)建一個集群配對YAML配置文檔，從而對應到來源Kubernetes集群上。這個clusterpair.yaml(https://docs.portworx.com/cloud-references/migration/migration-stork/#overview)文檔將包含如何與目標集群調度程序和Portworx存儲進行驗證的信息。運行如下命令并編輯YAML文檔即可建立配對：

$ storkctl generate clusterpair --context <destination-cluster> > clusterpair.yaml`

1. 說明：你可以用你自己的名稱替換“metadata.name”。

2. 說明：在如下示例中，options.token可以使用通過上述“cluster tokenshow”命令生成的令牌。

3. 說明：在如下示例中，對于options.ip，將需要負載均衡器或Portworx節(jié)點的IP或者DNS，這樣我們才能夠訪問9001和9010端口。

下一步，使用kubectl，將這個集群配對應用到來源集群上。

$ kubectl config use-context <source-cluster>

$ kubectl create -f clusterpair.yaml

在這種架構下，集群配對通過互聯(lián)網（VPC至VPC）進行連接。這就需要確保我們的目標存儲能夠良好地與來源集群連接。 請參照如下說明。（https://docs.portworx.com/cloud-references/migration/）

1. 說明:這些步驟均是暫用措施，后續(xù)新版本的發(fā)布后將由自動化過程取代。

2. 說明: 云到云、本地環(huán)境到云、云到本地環(huán)境，都需要類似的步驟。

如果所有步驟均操作成功，則請使用storkctl列出集群配對，程序將顯示存儲和調度程序的Ready狀態(tài)。如果顯示Error，則請使用kubectl describe clusterpair，以獲取更多信息。

$ storkctl get clusterpair
NAME      STORAGE-STATUS   SCHEDULER-STATUS   CREATED
green     Ready            Ready              19 Nov 18 11:43 EST

$ kubectl describe clusterpair new-cluster | grep paired
  Normal  Ready   2m    stork  Storage successfully paired
  Normal  Ready   2m    stork  Scheduler successfully paired

pxctl也可以用于列出集群配對。

$ pxctl_src cluster pair list
CLUSTER-ID  NAME               ENDPOINT                      CREDENTIAL-ID
c604c669    px-cluster-testing http://portworx-api.com:9001  a821b2e2-788f

我們的集群現(xiàn)在已經配對成功了。

在Kubernetes 1.12.0上測試工作負載

目前Kubernetes 1.10.3來源集群已經和1.12.0目標集群完成了配對，我們可以將運行的工作負載、配置以及數(shù)據從一個集群遷移到另一個集群上，來測試目標集群1.12.0Kubernetes上的應用程序是否能夠正常運行。在遷移過程中及完成后，所有的Pods都將繼續(xù)在來源集群上運行。我們現(xiàn)在有了兩個集群，即藍色和綠色，只在其運行的Kubernetes版本上存在差異。

$ kubectl config  use-context <1.10.3 source cluster context>

如果想要檢查當前使用的Kubernetes版本，請運行kubectl version命令。這個命令能夠輸出當前的客戶端和服務器版本。如下所示，服務器版本為1.10.3。

$ kubectl version --short | awk -Fv '/Server Version: / {print "Kubernetes Version: " $3}'
Kubernetes Version: 1.10.3-eks

在1.10.3上部署應用程序

在遷移工作負載時，我們需要一個來源集群上已經存在的工作負載。在演示中，我們將使用Heptio的示例LAMP堆棧在來源集群上創(chuàng)建一個LAMP堆棧(http://docs.heptio.com/content/tutorials/lamp.html)，從而在MySQL卷上使用Portworx。這個堆棧包含了一個存儲分類，包括Portworx、加密文件、HPH網頁前端，以及一個具備Porworx卷副本的mySQL數(shù)據庫。

$ kubectl create ns lamp   

$ kubectl create -f . -n lamp
job.batch "mysql-data-loader-with-timeout" created
storageclass.storage.k8s.io "portworx-sc-repl3" created
persistentvolumeclaim "database" created
deployment.extensions "mysql" created
service "mysql" created
deployment.extensions "php-dbconnect" created
service "web" created
secret "mysql-credentials" created

使用kubectl對Pods進行檢索，確保其處于Running狀態(tài)下。

$ kubectl get po -n lamp
NAME                                   READY     STATUS    RESTARTS   AGE
mysql-6f95f464b8-2sq4v                 1/1       Running   0          1m
mysql-data-loader-with-timeout-f2nwg   1/1       Running   0          1m
php-dbconnect-6599c648-8wnvf           1/1       Running   0          1m
php-dbconnect-6599c648-ckjqb           1/1       Running   0          1m
php-dbconnect-6599c648-qv2dj           1/1       Running   0          1m

提取Web服務。記錄服務的CLUSTER-IP和EXTERNAL-IP。遷移完成后，這兩個數(shù)據將會因為處于新的集群上而發(fā)生變化。

$ kubectl get svc web -n lamp -o wide
NAME      TYPE           CLUSTER-IP       EXTERNAL-IP             PORT(S)      AGE   SELECTOR
web       LoadBalancer   172.20.219.134   abe7c37c.amazonaws.com  80:31958/TCP 15m   app=php-dbconnect

訪問端點或使用curl確認WordPress已安裝、運行正常且已連接至MySQL。

MySQL連接

$ curl -s abe7c37c.amazonaws.com/mysql-connect.php | jq
{
  "outcome": true
}

驗證是否也為MySQL容器創(chuàng)建了PVC。如下我們將看到PVC、數(shù)據庫，各有三個副本用于部署。這個卷是MySQL的ReadWriteOnce卷塊。

$ kubectl get pvc -n lamp
NAME       STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
database   Bound     pvc-c572277d-ec15-11e8-9f4d-12563b3068d4   2Gi        RWO            portworx-sc-repl3   28m

卷信息也可以使用pxctl進行展示。Volume list命令的輸出如下。

$ pxctl_src -- volume list
ID                 NAME                                      SIZE  HA STATUS                       
618216855805459265 pvc-c572277d-ec15-11e8-9f4d-12563b3068d4  2 GiB 3  attached on 10.0.3.145

將應用程序遷移至Kubernetes 1.12.0

對本地kubectl客戶端進行配置，使其使用正在運行1.12.0的目標集群。

$ kubectl config use-context <1.12.0 destination cluster context>

運行kubectl Version命令，這個命令將輸出當前的客戶端和服務器版本，如下看到運行的1.12.0。

$ kubectl version --short | awk -Fv '/Server Version: / {print "Kubernetes Version: " $3}'
Kubernetes Version: 1.12.0

驗證LAMP堆棧Pods是否正在運行中。如下所示，該集群的Namespace沒有資源，即表示遷移還未發(fā)生。

$ kubectl get po
No resources found.

下一步，使用Stork客戶端storkctl，創(chuàng)建一次遷移，將LAMP堆棧資源和卷從1.10.3集群遷移到1.12.0集群上。向storkctl create migration的命令的輸入包括clusterPair、namespaces以及可選的includeResources和startApplications，從而將相關資源納入并在遷移完成后啟動應用程序。該命令的更多信息請點擊這里(https://docs.portworx.com/cloud-references/migration/migration-stork/)。

$ storkctl --context <source-cluster-context> \
   create migration test-app-on-1-12 \
   --clusterPair green \
   --namespaces lamp \
   --includeResources \
   --startApplications
Migration test-app-on-1-12 created successfully

遷移創(chuàng)建后，使用storkctl獲取遷移狀態(tài)。

$  storkctl --context <source-cluster-context> get migration
NAME               CLUSTERPAIR   STAGE     STATUS       VOLUMES   RESOURCES   CREATED
test-app-on-1-12   green         Volumes   InProgress   0/1       0/7         19 Nov 18 13:47 EST

pxctl也可以用于查看遷移狀態(tài)。卷將顯示出與遷移有關的STAGE和STATUS。

$ pxctl_src cloudmigrate status

CLUSTER UUID: 33293033-063c-4512-8394-d85d834b3716
TASK-ID            VOLUME-ID               VOLUME-NAME                               STAGE     STATUS     
85d3-lamp-database 618216855805459265      pvc-c572277d-ec15-11e8-9f4d-12563b3068d4  Done      Initialized

完成后，遷移將顯示STAGE → Final和 STATUS → Successful。

$ storkctl --context  <source-cluster-context> get migration

NAME               CLUSTERPAIR   STAGE     STATUS       VOLUMES   RESOURCES   CREATED
test-app-on-1-12   green         Final     Successful   1/1       7/7         19 Nov 18 13:47 EST

現(xiàn)在從目標集群中獲得Pods。如下所示，PHP與MySQL現(xiàn)在都在目的集群上運行。

$ kubectl get po -n lamp
NAME                            READY     STATUS    RESTARTS   AGE
mysql-66d895ff69-z49jl          1/1       Running   0          11m
php-dbconnect-f756c7854-2fc2l   1/1       Running   0          11m
php-dbconnect-f756c7854-c48x8   1/1       Running   0          11m
php-dbconnect-f756c7854-h8tgh   1/1       Running   0          11m

注意CLUSTER-IP和EXTERNAL-IP現(xiàn)在已經發(fā)生了變化。這表示服務現(xiàn)在在新的Kubernetes 1.12集群上運行，并且因此包含了與此前不同的子網。

$  kubectl get svc web -n lamp -o wide
NAME      TYPE           CLUSTER-IP     EXTERNAL-IP            PORT(S)       AGE  SELECTOR
web       LoadBalancer   10.100.0.195   aacdee.amazonaws.com   80:31958/TCP  12m  app=php-dbconnect

如果網站能夠在1.12.0集群上被訪問、運行正常并且數(shù)據已經正確遷移到了1.12.0集群，則將會返回相同的輸出內容。

Web網頁前端

MySQL連接

$ curl -s http://aacdee.amazonaws.com//mysql-connect.php | jq
{
  "outcome": true
}

如下我們可以看到來源（下）和目標（上）集群上，kubectl get po -n lamp的輸出。注意Pods的AGE，目的集群（上）中有最近遷移進來的LAMP堆棧。

兩個集群在遷移后運行的是相同的程序和數(shù)據。

回顧整個過程：

1. 第一步，1.10.3 EKS集群與1.12.0集群配對。

2. LAMP堆棧（Linux, Apache, MySQL, PHP）部署到1.10.3集群上。

3. 使用PX-Motion將Kubernetes部署、加密文件、副本集、服務、持久卷、持久卷連接，以及LAMP堆棧數(shù)據遷移到1.12.0集群上。

4. 應用程序在1.12.0集群上被訪問，并驗證其是否正確運行。

持久卷和連接都使用PX-Motion（https://docs.portworx.com/cloud-references/migration）在各個集群之間進行遷移，Kubernetes資源和副本都使用Portworx Stork在目標集群上進行啟動。

現(xiàn)在我們擁有了兩個完全可運行的Kubernetes集群和兩個環(huán)境，即藍色和綠色部署環(huán)境。在實際操作中，你需要在綠色集群上進行所有測試，從而確保應用程序不會在新的集群上發(fā)生預期之外的問題。確認測試完成之后，將負載均衡從藍色集群切換至新的綠色集群，此時部署就完成了！

**結論

PX-Motion具有將Portworx卷和Kubernetes資源在集群之間進行遷移的能力。上述樣例就是使用PX-Motion幫助團隊實現(xiàn)藍綠部署的過程：對其工作負載和數(shù)據在新版本的Kubernetes上進行測試，并幫助團隊在新的綠色集群上運行應用程序。在不同版本的Kubernetes上進行真實負載和數(shù)據測試，使得運營團隊能夠在發(fā)布新版本的Kubernetes之前獲得充足的信心。藍綠部署并不是PX-Motion唯一的功能，請查看我們其他的PX-Motion博文了解更多。**