Portworx演示：在K8S集群間遷移有狀態的應用和數據

越來越多的企業選擇Kubernetes作為基礎架構，它能夠幫助我們縮短軟件項目上市時間、降低基礎架構成本、并提高軟件質量。由于Kubernetes比較新，因此IT團隊都在學習如何在生產環境中，在Kubernetes上對應用程序進行運行和維護。本文將探討，當在需要額外的計算能力時，將Kubernetes應用程序遷移至另一個新的集群。

Portworx演示視頻鏈接

需要對當前的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應用程序轉移到另一個集群時，你需要：

1. 將這兩個集群進行配對，從而指定一個目標集群和一個目的集群；
2. 使用PX-Motion開始遷移，其中包括移動數據卷和配置；
3. 數據和配置遷移完成后，Kubernetes會自動將應用程序部署到新的環境中。

我們開始吧！

配置與設置

在展示中，我們使用google Kubernetes Engine (GKE)作為Kubernetes集群，但你也可以在任意的Kubernetes集群中進行如下的操作。使用Portworx installer online spec generator獲得的DaemonSet Spec, 將Portworx安裝到各個集群上。逐步完成安裝，Portworx安裝過程在此不作贅述，可以查看portworx.com上的文檔了解如何在Kubernetes上安裝Portworx 。環境架構示意圖如下。注意集群1和集群2的如下方面：

在這種情況下，第一個集群（集群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

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

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

3. 說明：在如下示例中，對于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系列文章了解更多信息。