愈來愈多的企業選擇Kubernetes做爲基礎架構,它可以幫助咱們縮短軟件項目上市時間、下降基礎架構成本、並提升軟件質量。因爲Kubernetes比較新,所以IT團隊都在學習如何在生產環境中,在Kubernetes上對應用程序進行運行和維護。本文將探討,當在須要額外的計算能力時,將Kubernetes應用程序遷移至另外一個新的集羣。html
Portworx演示視頻連接 mysql
須要對當前的Kubernetes集羣進行擴充的一些緣由sql
1.某個集羣的資源即將被所有佔用,你須要將工做負載遷移到新的具備更多的計算資源的地方。
2.你但願使用的服務在另外一個區域或雲中,但想要使用這些服務,你須要轉移應用程序和數據。
3.硬件到期,須要升級硬件到下一代,而新硬件的計算的規格、要求以及內存容量都已經發生了變化,這就致使了遷移的必要性。
4.集羣資源受限而且進行擴展instance的成本愈來愈高,所以你須要採用新的集羣架構,這樣的集羣須要使用網絡附加的塊存儲而非本地磁盤,這樣纔可以將存儲獨立於計算進行擴展。
5.開發人員但願將工做負載轉移到一個具備不一樣的硬件、網絡、操做系統或其餘配置的集羣進行測試或分級。數據庫
上述所列緣由並不詳盡,但也說明在許多條件下擴充Kubernetes環境和將工做負載從一個集羣遷移到另外一個集羣是有必要的。這個問題在涉及無狀態應用時較爲簡單,但對於有狀態的服務,如數據庫、隊列、關鍵存儲、大數據以及機器學習應用時等時,你就必須將數據轉移到新的、擴容的環境中去,而後應用程序設計才能加速運行。json
解決數據移動性問題:PX-Enterprise™新功能api
PX-Motion不只具備對數據進行跨環境轉移的能力,它還可以對應用程序配置以及相關的有狀態的資源,如PV(永久卷)等進行轉移,使得操做團隊可以很是方便地將一個卷、一個Kubernetes名字空間、或整個Kubernetes集羣在環境之間進行轉移,即使其中存在永久數據。網絡
本文將對PX-Motion的功能與能力進行探討。同時,咱們將演示如何將一個Kubernetes命名空間以及其中運行的全部應用程序轉移到一個具備資源拓展能力的新的Kubernetes集羣上。在這個演示中,集羣1表示資源已通過度利用的、不靈活的,已經沒法知足咱們不斷增加的應用程序需求的集羣。集羣2表示一個更加靈活且可擴展的集羣,咱們將把工做負載轉移到這個集羣2上。架構
除了在集羣之間進行整個Kubernetes命名空間的轉移以外,咱們還將展現如何將配置在集羣1中使用本地存儲的應用程序,遷移到使用網絡附加的塊存儲的集羣2中。負載均衡
經過這種方式,你將看到咱們須要轉移真正的數據,而不是經過管理塊設備映射這種小伎倆來實現的。機器學習
總的來講,在將一個有狀態的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的限制包括:
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」命令生成的令牌。
在使用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系列文章瞭解更多信息。