越來越多的企業選擇Kubernetes作爲基礎架構，它能夠幫助我們縮短軟件項目上市時間、降低基礎架構成本、並提高軟件質量。由於Kubernetes比較新，因此IT團隊都在學習如何在生產環境中，在Kubernetes上對應用程序進行運行和維護。本文將探討，當在需要額外的計算能力時，將Kubernetes應用程序遷移至另一個新的集羣。
Portworx演示 - 多集羣中K8S應用數據遷移
需要對當前的Kubernetes集羣進行擴充的一些原因
1.某個集羣的資源即將被全部佔用，你需要將工作負載遷移到新的具有更多的計算資源的地方。
2.你希望使用的服務在另一個區域或雲中，但想要使用這些服務，你需要轉移應用程序和數據。
3.硬件到期，需要升級硬件到下一代，而新硬件的計算的規格、要求以及內存容量都已經發生了變化，這就導致了遷移的必要性。
4.集羣資源受限並且進行擴展instance的成本越來越高，因此你需要採用新的集羣架構，這樣的集羣需要使用網絡附加的塊存儲而非本地磁盤，這樣才能夠將存儲獨立於計算進行擴展。
5.開發人員希望將工作負載轉移到一個具有不同的硬件、網絡、操作系統或其他配置的集羣進行測試或分級。
上述所列原因並不詳盡，但也說明在許多條件下擴充Kubernetes環境和將工作負載從一個集羣遷移到另一個集羣是有必要的。這個問題在涉及無狀態應用時較爲簡單，但對於有狀態的服務，如數據庫、隊列、關鍵存儲、大數據以及機器學習應用時等時，你就必須將數據轉移到新的、擴容的環境中去，然後應用程序設計才能加速運行。
解決數據移動性問題：PX-Enterprise™新功能
PX-Motion不僅具有對數據進行跨環境轉移的能力，它還能夠對應用程序配置以及相關的有狀態的資源，如PV（永久卷）等進行轉移，使得操作團隊能夠非常方便地將一個卷、一個Kubernetes名字空間、或整個Kubernetes集羣在環境之間進行轉移，即便其中存在永久數據。
本文將對PX-Motion的功能與能力進行探討。同時，我們將演示如何將一個Kubernetes命名空間以及其中運行的所有應用程序轉移到一個具有資源拓展能力的新的Kubernetes集羣上。在這個演示中，集羣1表示資源已經過度利用的、不靈活的，已經無法滿足我們不斷增長的應用程序需求的集羣。集羣2表示一個更加靈活且可擴展的集羣，我們將把工作負載轉移到這個集羣2上。
除了在集羣之間進行整個Kubernetes命名空間的轉移之外，我們還將展示如何將配置在集羣1中使用本地存儲的應用程序，遷移到使用網絡附加的塊存儲的集羣2中。
通過這種方式，你將看到我們需要轉移真正的數據，而不是通過管理塊設備映射這種小伎倆來實現的。
總的來說，在將一個有狀態的Kubernetes應用程序轉移到另一個集羣時，你需要：
- 將這兩個集羣進行配對，從而指定一個目標集羣和一個目的集羣；
- 使用PX-Motion開始遷移，其中包括移動數據卷和配置；
- 數據和配置遷移完成後，Kubernetes會自動將應用程序部署到新的環境中。
我們開始吧！
配置與設置
在展示中，我們使用google Kubernetes Engine (GKE)作爲Kubernetes集羣，但你也可以在任意的Kubernetes集羣中進行如下的操作。使用Portworx installer online spec generator獲得的DaemonSet Spec, 將Portworx安裝到各個集羣上。逐步完成安裝，Portworx安裝過程在此不作贅述，可以查看portworx.com上的文檔瞭解如何在Kubernetes上安裝Portworx 。
環境架構示意圖如下。注意集羣1和集羣2的如下方面：
| Cluster Name | Machine Type | Storage Type |
|---|---|---|
| Cluster 1 (Source) | n1-standard-2 | local-ssd |
| Cluster 2 (Destination) | n1-standard-8 | provisioned PDs |
在這種情況下，第一個集羣（集羣1）資源面臨限制，操作團隊希望從本地SSD轉移到更大instance的自動配置的永久磁盤（PD）中。
爲什麼？本地SSD在處理特定工作負載時較爲有效，但其自身也存在着侷限性，這也是我們在這裏討論將應用程序從一個命名空間轉移到另一個命名空間的原因所在。依照谷歌的描述，本地SSD的限制包括：
- “由於本地SSD是以物理方式附加到節點的虛擬機instance上的，其中存儲的所有數據都只存在於這個節點上。而由於數據是本地存儲的，因此你的應用必須要能夠面對數據不可用的情況。”
- “存儲在SSD的數據是短期性的。向本地SSD寫入內容的Pod會在被調度離開這一節點時失去對磁盤中存儲的數據進行訪問的能力。”
- 此外，如果節點被撤銷、升級或維修，則數據就會被擦除。 “我們並不能向現有的節點池添加本地SSD。”
Portworx能夠克服對上述部分限制，因爲它能夠將數據複製到集羣中的其他提供高可用的主機上。但如果我們希望在不對計算按比例進行擴展的情況下，不斷向我們的集羣添加額外的存儲，那麼使用本地存儲仍舊會存在一定的限制。上文所述的GKE上的第二個集羣使用Portworx Disk Template，從而自動允許Portworx從Google雲對磁盤進行管理，這比本地磁盤更加靈活一些。
第二個集羣提前運行，現在使用的是自動配置的PD，可以進行工作負載的遷移。
大量應用程序的運行需要更多的計算能力
源集羣如下。它是由單個命名空間(NameSpace)內運行的大量應用構成的：Cassandra, Postgres,WordPress和MySQL。所有的這些應用程序都會在集羣中產生非常高的負載。如下是demo命名空間內運行的應用。注意，在單個Kubernetes集羣上運行多個命名空間是可行且常見的。在演示中，我們只移動一個命名空間，讓剩餘的其他命名空間繼續運行，不做變動。
$ kubectlconfig use-context <source-cluster>
$ kubectlget po -n demo
NAME READY STATUS RESTARTS AGE
cassandra-1-0 1/1 Running 0 17m
cassandra-1-1 1/1 Running 0 16m
cassandra-1-2 1/1 Running 0 14m
cassandra-2-0 1/1 Running 0 17m
cassandra-2-1 1/1 Running 0 16m
cassandra-2-2 1/1 Running 0 14m
mysql-1-7f58cf8c7c-srnth 1/1 Running 0 2m
mysql-2-8498757465-gqs5h 1/1 Running 0 2m
postgres-2-68c5d6b845-c4gbw 1/1 Running 0 26m
postgres-77bf94ccb5-hs7dh 1/1 Running 0 26m
wordpress-mysql-2-5fdffbdbb4-dpqm9 1/1 Running 0 17m
在某一個時間點上，當添加了更多的應用程序，如MySQL數據庫時，這個集羣就會遭遇其內存限制並出現“OutOfmemory”等錯誤，見如下。爲解決這個問題，我們將demo這個命名空間遷移到一個新的集羣上，從而爲demo這個命名空間增添新的可用資源。
$ kubectlget po -n demo
NAME READY STATUS RESTARTS AGE
cassandra-1-0 1/1 Running 0 16m
cassandra-1-1 1/1 Running 0 14m
cassandra-1-2 1/1 Running 0 13m
cassandra-2-0 1/1 Running 0 16m
cassandra-2-1 1/1 Running 0 14m
cassandra-2-2 1/1 Running 0 13m
mysql-1-7f58cf8c7c-srnth 1/1 Running 0 1m
mysql-2-8498757465-gqs5h 1/1 Running 0 25s
mysql-3-859c5dc68f-2gcdj 0/1 OutOfmemory 0 10s
mysql-3-859c5dc68f-4wzmd 0/1 OutOfmemory 0 9s
mysql-3-859c5dc68f-57npr 0/1 OutOfmemory 0 11s
mysql-3-859c5dc68f-6t8fn 0/1 Terminating 0 16s
mysql-3-859c5dc68f-7hcf6 0/1 OutOfmemory 0 6s
mysql-3-859c5dc68f-7zbkh 0/1 OutOfmemory 0 5s
mysql-3-859c5dc68f-8s5k6 0/1 OutOfmemory 0 9s
mysql-3-859c5dc68f-d49nv 0/1 OutOfmemory 0 10s
mysql-3-859c5dc68f-dbtd7 0/1 OutOfmemory 0 15s
mysql-3-859c5dc68f-hwhxw 0/1 OutOfmemory 0 19s
mysql-3-859c5dc68f-rc8tg 0/1 OutOfmemory 0 12s
mysql-3-859c5dc68f-vnp9x 0/1 OutOfmemory 0 18s
mysql-3-859c5dc68f-xhgbx 0/1 OutOfmemory 0 12s
mysql-3-859c5dc68f-zj945 0/1 OutOfmemory 0 14s
postgres-2-68c5d6b845-c4gbw 1/1 Running 0 24m
postgres-77bf94ccb5-hs7dh 1/1 Running 0 24m
wordpress-mysql-2-5fdffbdbb4-dpqm9 1/1 Running 0 16m
除PX-Motion之外，最新發布的PX-Enterprise也包含了PX-Central™，這是一個用於監視、數據分析和管理的界面，能夠對Grafana、Prometheus和Alertmanager進行配置。這些儀表板會對卷、集羣、etcd以及其他內容進行監控。在本文所討論的情況下，查看集羣級儀表盤,就能夠了解資源方面的問題。
如下所示的PX-Central截屏展示了該集羣正在使用的內存和CPU的情況。該集羣的高CPU和內存佔用率爲擴展帶來了問題，並且由於集羣存在過載問題，很有可能導致上文所述的“OutOfMemory（內存不足）”的問題。
使用PX-Motion遷移一個Kubernetes命名空間，包括其數據。
既然已經找到了問題，現在我們來使用PX-Motion將數據遷移到新的集羣上。首先，我們將兩個GKE集羣配對起來，實現源集羣和目標集羣之間的遷移連接。集羣的配對和藍牙播放器與手機的配對類似。配對過程是爲了將兩個不同的設備連接起來。
前提條件
如果你正在嘗試PX-Migration，請確認已經滿足所有的前提條件。
爲了將工作負載從集羣1遷移到集羣2，我們需要對PX-Motion進行配置。首先要做的是配置目標集羣。爲實現這一點，首先建立對於pxctl (“pixie-cuttle”)的訪問，即Portworx CLI。如下是pxctl在具有kubectl訪問的情況下在工作站的運作情況。
$ kubectl config use-context <destination-cluster>
$PX_POD_DEST_CLUSTER=$(kubectl get pods –context
<DESTINATION_CLUSTER_CONTEXT> -lname=portworx -n kube-system
-o jsonpath='{.items[0].metadata.name}’)
$ aliaspxctl_dst=”kubectl exec $PX_POD_DEST_CLUSTER
–context <DESTINATION_CLUSTER_CONTEXT>\
-n kube-system /opt/pwx/bin/pxctl”
下一步，對目標集羣進行設置使其準備好與來源集羣進行配對。目標集羣應當首先運行Portworx objectstore。我們需要在目標集羣上設置一個對象存儲端點，爲數據在遷移過程中進行分級的位置。然後，爲來源集羣創建一個token在配對過程中使用。
$pxctl_dst — volume create –size 100 objectstore
$ pxctl_dst– objectstore create -v objectstore
$pxctl_dst — cluster token show
Token is<UUID>
現在可以創建一個集羣配對YAML配置文檔，從而應用到來源Kubernetes集羣中去。這個clusterpair.yaml文檔將包含如何與目標集羣調度程序和Portworx存儲進行驗證的信息。運行如下命令並編輯YAML文檔即可建立集羣配對：
$ storkctlgenerate clusterpair –context <destination-cluster> > clusterpair.yaml
-
說明：你可以用你自己的名稱替換“metadata.name”。
-
說明：在如下示例中，options.token可以使用通過上述“cluster token show”命令生成的令牌。
-
說明：在如下示例中，對於options.ip，將需要一個可訪問的負載均衡或Portworx節點的IP或DNS，來訪問9001和9010端口。
在使用GKE時，在應用到集羣之前，我們需要向Stork添加許可。Strok是由PX-Enterprise使用的Kubernetes的OSS智能調度程序擴展和遷移工具，同時我們還需要知道如何對新集羣進行驗證，從而對應用程序進行遷移。首先，使用谷歌雲指令生成服務賬戶。然後，對Stork部署和驗證進行編輯，從而確保其能夠訪問目標集羣。指令請見如下。
下一步，應用這個集羣並使用kubectl與來源集羣進行配對。
$ kubectl config use-context <source-cluster>
$ kubectlcreate -f clusterpair.yaml
應用完成後，使用已經設置的storkctl檢查集羣配對的狀態。
$ storkctlget clusterpair
kubectl和pxctl也可以對集羣配對進行查看。
$ kubectldescribe clusterpair new-cluster | grep paired
Normal Ready 2m stork Storage successfully paired
Normal Ready 2m stork Scheduler successfullypaired
$ pxctlcluster pair list
CLUSTER-ID NAME ENDPOINT CREDENTIAL-ID
c604c669 px-cluster-2 http://35.185.59.99:9001 a821b2e2-788f
開始遷移
下一步，有兩種方式開始遷移動作：通過storkctl生成遷移 CLI，或參考對遷移進行描述的spec文件。我們使用第二種方法，請見如下，對演示資源和捲進行遷移。
apiVersion:stork.libopenstorage.org/v1alpha1
kind: Migration
metadata:
name: demo-ns-migration
spec:
clusterPair: new-cluster
includeResources: true
startApplications: true
namespaces:
– demo
依照上述spec文檔使用kubectl創建遷移。
kubectlcreate -f migration.yaml
檢查遷移狀態。成功的遷移分爲如下步驟：卷→應用程序→完成
$ storkctlget migration
NAME CLUSTERPAIR STAGE STATUS VOLUMES RESOURCES CREATED
demo-ns-migration new-cluster Volumes InProgress 2/12 0/37 08 Nov 18 15:14 EST
$ storkctlget migration
NAME CLUSTERPAIR STAGE STATUS VOLUMES RESOURCES CREATED
demo-ns-migration new-cluster Application InProgress 12/12 30/37 08 Nov18 15:25 EST
$ storkctlget migration
NAME CLUSTERPAIR STAGE STATUS VOLUMES RESOURCES CREATED
demo-ns-migration new-cluster Final Successful 12/12 37/37 08 Nov 18 15:27 EST
爲了解哪些資源，如卷、PVC、狀態集、複製集處於“進行中”或“已完成”狀態，可以使用“kubectldescribe”命令。
$ kubectldescribe migration demo-ns-migration
遷移的狀態也可以使用來源Portworx集羣的pxctl進行查看。
$ pxctl –cloudmigrate status
CLUSTERUUID: c604c669-c935-4ca4-a0bc-550b236b2d7b
TASK-ID VOLUME-ID VOLUME-NAME STAGE STATUS
6cb407e0-e38e-demo-cassandra-data-1-cassandra-1-0 673298860130267347 pvc-2c2604f4-e381-11e8-a985-42010a8e0017 Done Complete
6cb407e0-e38e-demo-cassandra-data-1-cassandra-1-1 782119893844254444 pvc-7ef22f64-e382-11e8-a985-42010a8e0017 Done Complete
6cb407e0-e38e-demo-cassandra-data-1-cassandra-1-2 486611245472798631 pvc-b8af3c05-e382-11e8-a985-42010a8e0017 Done Complete
這樣根據集羣遷移資源的狀態顯示，遷移完成了，如下圖示展示的就是進行的過程。來自集羣1的命名空間、應用、配置以及數據等都遷移到集羣2。
隨後，查看目標集羣以確保應用確實已經完成遷移並且能夠良好運行，因爲我們使用的是“startApplications: true”屬性。
$ kubectl config use-context<destination cluster>
$ kubectl get po -n demo
NAME READY STATUS RESTARTS AGE
cassandra-1-0 1/1 Running 0 7m
cassandra-1-1 1/1 Running 0 5m
cassandra-1-2 1/1 Running 0 4m
cassandra-2-0 1/1 Running 0 7m
cassandra-2-1 1/1 Running 0 5m
cassandra-2-2 1/1 Running 0 4m
mysql-1-7f58cf8c7c-gs8p4 1/1 Running 0 7m
mysql-2-8498757465-4gkr2 1/1 Running 0 7m
postgres-2-68c5d6b845-cs9zb 1/1 Running 0 7m
postgres-77bf94ccb5-njhx4 1/1 Running 0 7m
wordpress-mysql-2-5fdffbdbb4-ppgsl 1/1 Running 0 7m
完美! 所有的程序都在運行中! 現在我們返回PX-CentralGrafana儀表板就可以看到集羣上使用的內存和CPU都變少了。該截屏顯示的是工作負載遷移後的工作節點的CPU和內存使用情況。
這正是我們希望達到的效果。如下是GKE儀表板上顯示的集羣1和集羣2之間可用CPU和內存的量，因此上述結果是有效的。
現在我們擁有了額外的計算力，我們就可以創建額外的MySQL數據庫了。這個數據庫將在新集羣上擁有足夠的資源進行運行。
$ kubectlcreate -f specs-common/mysql-3.yaml
storageclass.storage.k8s.io”mysql-tester-class-3″ created
persistentvolumeclaim”mysql-data-3″ created
deployment.extensions”mysql-3″ created
$ kubectlget po -n demo
NAME READY STATUS RESTARTS AGE
cassandra-1-0 1/1 Running 0 22m
cassandra-1-1 1/1 Running 0 20m
cassandra-1-2 1/1 Running 0 18m
cassandra-2-0 1/1 Running 0 22m
cassandra-2-1 1/1 Running 0 20m
cassandra-2-2 1/1 Running 0 18m
mysql-1-7f58cf8c7c-gs8p4 1/1 Running 0 22
mysql-2-8498757465-4gkr2 1/1 Running 0 22m
mysql-3-859c5dc68f-6mcc5 1/1 Running 0 12s
postgres-2-68c5d6b845-cs9zb 1/1 Running 0 22m
postgres-77bf94ccb5-njhx4 1/1 Running 0 22m
wordpress-mysql-2-5fdffbdbb4-ppgsl 1/1 Running 0 22m
成功!
集羣擴增的益處是顯而易見的。用戶和操作員可以將舊的命名空間或應用從來源集羣上刪除，也可以直接將整個集羣刪除掉，從而回收這些資源。新的集羣使用的是自動配置PD而非本地SSD，因此其存儲與計算能力都能夠依照IT團隊的需求進行擴展。
結論
PX-Motion具有着將Portworx卷和Kubernetes資源在集羣之間進行遷移的能力。上述案例就利用了PX-Motion這一功能，使得團隊能夠對Kubernetes環境實現無縫擴增。在Kubernetes上的環境之間對命名空間、卷或整個應用程序進行遷移就變得輕而易舉了。擴增並不是PX-Motion唯一的功能，請查看我們其他的PX-Motion系列文章瞭解更多信息。