越来越多的企业选择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应用程序转移到另一个集群时，你需要：
- 将这两个集群进行配对，从而指定一个目标集群和一个目的集群；
- 使用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这个命名空间增添新的可用资源。
$ 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
$ 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: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
$ 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系列文章了解更多信息。
