越來越多的企業選擇Kubernetes作為基礎架構，它能夠幫助我們縮短軟體項目上市時間、降低基礎架構成本、并提高軟體品質。由于Kubernetes比較新，是以IT團隊都在學習如何在生産環境中，在Kubernetes上對應用程式進行運作和維護。本文将探讨，當在需要額外的計算能力時，将Kubernetes應用程式遷移至另一個新的叢集。
需要對目前的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
$ 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這個命名空間增添新的可用資源。
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
$ PX_POD_DEST_CLUSTER=$(kubectl get pods --context
-l name=portworx -n kube-system
-o jsonpath='{.items[0].metadata.name}')
$ alias pxctl_dst="kubectl exec $PX_POD_DEST_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
現在可以建立一個叢集配對YAML配置文檔，進而應用到來源Kubernetes叢集中去。這個clusterpair.yaml文檔将包含如何與目标叢集排程程式和Portworx存儲進行驗證的資訊。運作如下指令并編輯YAML文檔即可建立叢集配對：
$ storkctlgenerate clusterpair –context > 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
$ 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:9001a821b2e2-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
NAME CLUSTERPAIR STAGE STATUS VOLUMES RESOURCES CREATED
demo-ns-migration new-cluster Application InProgress 12/12 30/37 08 Nov18 15:25 EST
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
$ kubectl get po -n demo
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
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系列文章了解更多資訊。