Portworx Kubemotion：在OpenShift集羣間遷移有狀態應用
Portworx是一個支撐K8S有狀態應用的持久存儲和數據管理平臺。通過Portworx，它爲有狀態應用提供了一個單一的數據管理層，從而用戶可以在任何底層架構上運行類似數據庫這樣的有狀態應用。
Kubemotion是Portworx的核心功能之一，發佈在Portworx企業版2.0中。它賦能K8S用戶在集羣間遷移應用和數據、備份和恢復、以及做藍綠部署。（https://docs.portworx.com/portworx-install-with-kubernetes/migration/kubemotion/）
下面我們介紹如何在紅帽OpenShift集羣之間，遷移有狀態應用的持久卷和相關K8S資源。
背景
在企業客戶中，一個常見的場景是：在一個雲區域中運行研發測試環境，而在另一個雲區域中運行生產環境。研發測試環境通常會選擇距離開發團隊比較近，以降低網絡延遲，而生產環境則會選擇離用戶比較近。
K8S的無狀態應用遷移相對比較容易，但遷移有狀態應用是一個挑戰。
在演示中，我們會在AWS位於美國東部（俄亥俄），和美國西部（俄勒岡）的兩個數據中心的Openshift集羣間，遷移K8S資源。美國東部區域（俄亥俄）部署的是研發測試環境，美國西部區域（俄勒岡）部署的是生產環境。
在系統的測試環節完成後，開發團隊將使用Portworx和Kubemotion，把存儲卷和應用資源，從研發測試環境，遷移到生產環境中。
研發測試環境和生產環境
我們有兩個紅帽OpenShift集羣，分別是研發測試環境、以及生產環境，位於AWS的兩個不同區域上，兩個環境都安裝了最新版本的Portworx集羣，並且正在運行。
上面的OpenShift集羣代表了運行在AWS東部區域（俄亥俄）的研發測試環境。
上面的OpenShift集羣代表了運行在AWS西部區域（俄勒岡）的生產環境。
現在有一個基於LAMP的內容管理系統（CMS）運行在研發測試環境上，我們需要把它遷移到生產環境裏。
研發測試環境裏部署了MySQL和WordPress，它們都位於CMS命名空間裏。
關於如何在OpenShift上配置高可用的WordPress，可以參考這裏的文檔。（https://www.portworx.com/run-multi-tenant-ha-wordpress-platform-red-hat-openshift/）
Portworx存儲集羣支撐了附加在這些Pod上的持久卷。
下面的卷附加到了MySQL pod上。
對於WordPress CMS, 有個共享的Portworx卷附加到了Pod上。
配置好的應用，可以通過WordPress相關的服務來訪問。
準備源環境和目標環境
在我們遷移之前，我們需要配置源集羣和目標集羣。按照下面的步驟來準備相關的環境。
創建對象存儲的訪問身份驗證我們需要在源集羣和目標集羣上都創建對象存儲的訪問身份驗證信息。我們需要獲得目標集羣的UUID，它會被附加在訪問身份的名稱上。
爲了完成這一步，你需要AWS賬戶的訪問密鑰和Secret密鑰。如果你已經配置好了AWS CLI，可以在這裏發現這些密鑰。~/.aws/credentials
回到生產環境集羣，運行下面的命令來複制UUID。
PX_POD=$(oc get pods -l name=portworx -n kube-system -o jsonpath='{.items[0].metadata.name}')
oc -n=kube-system exec $PX_POD -- /opt/pwx/bin/pxctl status
記下集羣的UUID，放在一個安全的地方。
我們在生產環境內，來創建生產環境集羣的身份驗證信息。
oc -n=kube-system exec $PX_POD -- /opt/pwx/bin/pxctl credentials create \ --provider s3 \ --s3-access-key \ --s3-secret-key \ --s3-region ap-southeast-1 \ --s3-endpoint s3.ap-southeast-1.amazonaws.com clusterPair_c02528e3-30b1-43e7-91c0-c26c111d57b3
確保身份驗證信息的名稱按照這樣的格式：‘clusterPair_UUID’。
回到研發測試集羣，重複操作來創建身份驗證信息。
獲取目標集羣的Token
下一步是獲取生產環境集羣的Token，它會被用來創建集羣配對的YAML文件。
到生產環境集羣，運行下面的命令來訪問Token。
PX_POD=$(oc get pods -l name=portworx -n kube-system -o jsonpath='{.items[0].metadata.name}')
oc -n=kube-system exec $PX_POD -- /opt/pwx/bin/pxctl cluster token show
記下集羣Token，放置在一個安全的地方。
爲Portworx服務獲取負載均衡的端點
我們還需要生產環境集羣上的，與Portworx服務關聯的負載均衡的DNS名稱。我們可以通過下面的命令得到。
oc describe svc portworx-service -n kube-system
到這裏，你已經準備好下面的數據了：
1. 目標集羣的Token
2. 指向Portworx服務的負載均衡的CNAME
創建集羣配對參數
我們從生產環境（目標集羣）來創建YAML文件。並且把它應用到研發測試環境（源集羣）。
確保你在在生產環境中，運行下面的命令。
storkctl generate clusterpair -n cms prodcluster > clusterpair.yaml
打開clusterpair.yaml，在選項中增加下面的細節信息。它們反映了目標集羣裏的負載均衡的IP地址或者DNS名稱，以及與目標集羣關聯的Token。
爲Kubemotion進行集羣配對
通過爲源集羣配置配對參數，我們可以把集羣進行配對。
我們回到源集羣（研發測試環境），來進行集羣配對。
oc apply -f clusterpair.yaml oc get clusterpair -n cms
<pre>oc getclusterpairs</pre> 的輸出確認了配對已經成功。
驗證配對狀態
我們可以通過storkctl CLI來驗證配對狀態。確保存儲的狀態，和調度器的狀態都是正常，沒有錯誤。
storkctl -n=cms get clusterpair
我們驗證了，源集羣和目標集羣已經配對成功。
現在我們開始遷移。
從源集羣向目標集羣遷移CMS應用
在研發測試環境下，通過下面的步驟開始CMS應用的遷移。
開始遷移
用下面的內容創建一個名爲migration.yaml的YAML文件。
apiVersion: stork.libopenstorage.org/v1alpha1 kind: Migration metadata: name: cmsmigration namespace: cms spec: # This should be the name of the cluster pair created above clusterPair: prodcluster # If set to false this will migrate only the Portworx volumes. No PVCs, apps, etc will be migrated includeResources: true # If set to false, the deployments and stateful set replicas will be set to 0 on the destination. # There will be an annotation with "stork.openstorage.org/migrationReplicas" on the destinationto store the replica count from the source. startApplications: true # List of namespaces to migrate namespaces: - cms
這裏包括一些很重要的信息，例如集羣配對的名稱、遷移中包括的命名空間，需要被遷移的資源類型。
把YAML文件提交到研發測試集羣，來開始遷移。
oc apply -f migration.yaml migration.stork.libopenstorage.org/cmsmigration created
監控遷移的過程
使用storkctl我們來監控遷移的過程。
storkctl get migration -n cms
一旦遷移完成，storkctl 會報告最後遷移到目標集羣的卷的數量以及資源。
通過下面的命令，可以得到遷移過程的詳細信息。
oc describe migration cmsmigration -n=cms
% oc describe migration cmsmigration -n=cms
Name: cmsmigration
Namespace: cms
Labels:
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"stork.libopenstorage.org/v1alpha1","kind":"Migration","metadata":{"annotations":{},"name":"cmsmigration","namespace":"cms"}...
API Version: stork.libopenstorage.org/v1alpha1
Kind: Migration
Metadata:
Creation Timestamp: 2019-11-08T02:33:44Z
Generation: 9
Resource Version: 346702
Self Link: /apis/stork.libopenstorage.org/v1alpha1/namespaces/cms/migrations/cmsmigration
UID: 2eeb5d56-01d0-11ea-a393-02fec625b80a
Spec:
Admin Cluster Pair:
Cluster Pair: prodcluster
Include Resources: true
Include Volumes: true
Namespaces:
cms
Post Exec Rule:
Pre Exec Rule:
Selectors:
Start Applications: true
Status:
Finish Timestamp: 2019-11-08T02:34:56Z
Resources:
Group: core
Kind: PersistentVolume
Name: pvc-ac60362f-0170-11ea-8418-06c5879a6a7a
Namespace:
Reason: Resource migrated successfully
Status: Successful
Version: v1
Group: core
Kind: PersistentVolume
Name: pvc-c5dd1955-0170-11ea-a393-02fec625b80a
Namespace:
Reason: Resource migrated successfully
Status: Successful
Version: v1
Group: core
Kind: Service
Name: mysql
Namespace: cms
Reason: Resource migrated successfully
Status: Successful
Version: v1
Group: core
Kind: Service
Name: wordpress
Namespace: cms
Reason: Resource migrated successfully
Status: Successful
Version: v1
Group: core
Kind: PersistentVolumeClaim
Name: px-mysql-pvc
Namespace: cms
Reason: Resource migrated successfully
Status: Successful
Version: v1
Group: core
Kind: PersistentVolumeClaim
Name: px-wp-pvc
Namespace: cms
Reason: Resource migrated successfully
Status: Successful
Version: v1
Group: apps
Kind: Deployment
Name: mysql
Namespace: cms
Reason: Resource migrated successfully
Status: Successful
Version: v1
Group: apps
Kind: Deployment
Name: wordpress
Namespace: cms
Reason: Resource migrated successfully
Status: Successful
Version: v1
Group: route.openshift.io
Kind: Route
Name: wp
Namespace: cms
Reason: Resource migrated successfully
Status: Successful
Version: v1
Stage: Final
Status: Successful
Volumes:
Namespace: cms
Persistent Volume Claim: px-mysql-pvc
Reason: Migration successful for volume
Status: Successful
Volume: pvc-ac60362f-0170-11ea-8418-06c5879a6a7a
Namespace: cms
Persistent Volume Claim: px-wp-pvc
Reason: Migration successful for volume
Status: Successful
Volume: pvc-c5dd1955-0170-11ea-a393-02fec625b80a
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Successful 82s stork Volume pvc-ac60362f-0170-11ea-8418-06c5879a6a7a migrated successfully
Normal Successful 82s stork Volume pvc-c5dd1955-0170-11ea-a393-02fec625b80a migrated successfully
Normal Successful 78s stork /v1, Kind=PersistentVolume /pvc-ac60362f-0170-11ea-8418-06c5879a6a7a: Resource migrated successfully
Normal Successful 78s stork /v1, Kind=PersistentVolume /pvc-c5dd1955-0170-11ea-a393-02fec625b80a: Resource migrated successfully
Normal Successful 78s stork /v1, Kind=Service cms/mysql: Resource migrated successfully
Normal Successful 78s stork /v1, Kind=Service cms/wordpress: Resource migrated successfully
Normal Successful 78s stork /v1, Kind=PersistentVolumeClaim cms/px-mysql-pvc: Resource migrated successfully
Normal Successful 78s stork /v1, Kind=PersistentVolumeClaim cms/px-wp-pvc: Resource migrated successfully
Normal Successful 78s stork apps/v1, Kind=Deployment cms/mysql: Resource migrated successfully
Normal Successful 77s (x2 over 78s) stork (combined from similar events): route.openshift.io/v1, Kind=Route cms/wp: Resource migrated successfully
在生產環境上驗證遷移
回到生產環境，我們來檢查CMS命名空間裏的所有資源。
oc get all -n cms
你可以通過爲WordPress Pod使用port-forwardding，來訪問應用。
小結
Kubemotion爲有狀態應用增加了遷移功能。它可以在本地環境和雲環境之間，以及多雲環境之間，無縫的遷移卷。