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,把存儲卷和應用資源,從研發測試環境,遷移到生產環境中。mysql
Portworx存儲集羣支撐了附加在這些Pod上的持久卷。sql
下面的卷附加到了MySQL pod上。數據庫
對於WordPress CMS, 有個共享的Portworx卷附加到了Pod上。json
配置好的應用,能夠經過WordPress相關的服務來訪問。api
爲了完成這一步,你須要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,放在一個安全的地方。架構
咱們在生產環境內,來建立生產環境集羣的身份驗證信息。app
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’。負載均衡
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
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: Migrationmetadata: 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=cmsName: cmsmigrationNamespace: cmsLabels: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/v1alpha1Kind: MigrationMetadata: 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-02fec625b80aSpec: Admin Cluster Pair: Cluster Pair: prodcluster Include Resources: true Include Volumes: true Namespaces: cms Post Exec Rule: Pre Exec Rule: Selectors: Start Applications: trueStatus: 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-02fec625b80aEvents: 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爲有狀態應用增長了遷移功能。它能夠在本地環境和雲環境之間,以及多雲環境之間,無縫的遷移卷。