Portworx演示：在K8S叢集間遷移有狀態的應用和資料

上述所列原因並不詳盡，但也說明在許多條件下擴充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會自動將應用程式部署到新的環境中。

   
   

我們開始吧！

配置與設定

在這種情況下，第一個叢集（叢集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  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和記憶體使用情況。