如何跨不同版本K8S，为有状态工作负载做蓝绿部署

容器的生态正在爆发！不仅仅应用层在快速变化，还有用于管理应用程序的平台：Kubernetes，也在快速变化。这就为Ops团队带来了一个必须要解决的难题。IT团队如何才能保证一款应用程序能够在各种不同版本的Kubernetes上都能良好运行呢？


PX-Motion演示视频：如何跨不同版本Kubernetes，为有状态的工作负载做蓝绿部署

蓝-绿部署是一种专门用于解决这一问题的技术，并能够降低生产环境部署的过程中的停机或错误风险。在蓝绿部署场景下，用户需要构建两个完全相同的生产环境（分别称为蓝与绿），这两个环境之间仅在需要部署的新的变更方面存在差异。每一次仅激活一个环境，两个环境之间的数据传输也是部署过程的一部分。该技术对于不含任何数据的无状态应用非常有效，但对于数据库这类有状态应用则存在一定的困难，因为用户不得不保留两份生产数据副本。这种情况下可能会需要使用Postgres、MySQL以及其他数据库备份和恢复脚本，或定制化操作手册或自动脚本等将数据从一个数据源人工移动到另一个数据源，这个过程将会非常复杂并且会耗费大量的时间。

Portworx采用PX-Motion解决了有状态应用程序的蓝绿部署过程中的数据管理问题。PX-Motion使IT团队能够很方便地在各种环境之间进行数据和应用配置的迁移，极大地简化了有状态应用的蓝绿部署。

本篇博文将对PX-Motion的功能与能力进行探讨。具体地说，笔者将展示如何对两个不同版本的Kubernetes上运行的有状态LAMP堆栈进行蓝绿部署。

总结来说，我们会：

  1. 将两个Kubernetes集群（分别称为来源集群和目标集群）配对，从而使数据、配置和Pods能够这两个集群之间进行转移，这是蓝绿部署的一部分。
  2. 使用Kubernetes将一个LAMP堆栈部署到来源集群上，并验证应用程序能够运行。
  3. 使用PX-Motion可以将Kubernetes的部署、加密文件、副本集、服务、持久卷、持久卷连接以及数据等，从来源集群迁移到目标集群上进行测试和验证。在迁移完成之后，所有的Pods都能够在来源集群上继续运行。现在我们已经有了两个集群在运行，分别是蓝色和绿色。
  4. 使用Kubernetes验证我们的应用以及自身数据是否正在目标集群上正常运行。
  5. 在新集群上的部署验证完成之后，我们就可以更新我们的负载平衡设置，从而使所有的流量指向新集群。此时蓝绿部署就完成了。

我们开始吧！

安装PX-Motion

前提条件

如果你正在尝试PX-Migration，请确认已经满足所有的前提条件(https://docs.portworx.com/cloud-references/migration/migration-stork/#overview)。

配对Kubernetes集群为数据迁移做准备
从来源集群(Kubernetes 1.10.3)向目标集群(Kubernetes 1.12.0)进行工作载荷迁移之前，我们需要将这两个集群配对起来。配对的概念相当于将手机和蓝牙播放器进行配对，使两种不同的设备结合起来工作。
集群配对首先要做的是对目标集群进行配置。首先，建立对于pxctl (“pixie-cuttle”)的访问，即Portworx CLI。下面将介绍如何在可被kubectl访问的工作站上使用pxctl。

$ kubectl config  use-context <destination-cluster>`
$ PX_POD_DEST_CLUSTER=$(kubectl get pods --context
   <DESTINATION_CLUSTER_CONTEXT> -l name=portworx -n kube-system
   -o jsonpath=‘{.items[0].metadata.name}‘)
$ alias pxctl_dst="kubectl exec $PX_POD_DEST_CLUSTER    --context <DESTINATION_CLUSTER_CONTEXT>
   -n kube-system /opt/pwx/bin/pxctl"

下一步，对目标集群对象存储进行设置，使其准备好与来源集群进行配对。我们需要在目标集群上设置一个对象存储端点，作为数据在迁移过程中进行分级的位置。

$ 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(https://docs.portworx.com/cloud-references/migration/migration-stork/#overview)文档将包含如何与目标集群调度程序和Portworx存储进行验证的信息。运行如下命令并编辑YAML文档即可建立配对：

$ storkctl generate clusterpair --context <destination-cluster> > clusterpair.yaml`
  1. 说明：你可以用你自己的名称替换“metadata.name”。
  2. 说明：在如下示例中，options.token可以使用通过上述“cluster tokenshow”命令生成的令牌。
  3. 说明：在如下示例中，对于options.ip，将需要负载均衡器或Portworx节点的IP或者DNS，这样我们才能够访问9001和9010端口。

下一步，使用kubectl，将这个集群配对应用到来源集群上。

$ kubectl config use-context <source-cluster>
$ kubectl create -f clusterpair.yaml

在这种架构下，集群配对通过互联网（VPC至VPC）进行连接。这就需要确保我们的目标存储能够良好地与来源集群连接。 请参照如下说明。（https://docs.portworx.com/cloud-references/migration/）

  1. 说明:这些步骤均是暂用措施，后续新版本的发布后将由自动化过程取代。
  2. 说明: 云到云、本地环境到云、云到本地环境，都需要类似的步骤。

如果所有步骤均操作成功，则请使用storkctl列出集群配对，程序将显示存储和调度程序的Ready状态。如果显示Error，则请使用kubectl describe clusterpair，以获取更多信息。

$ storkctl get clusterpair
NAME      STORAGE-STATUS   SCHEDULER-STATUS   CREATED
green     Ready            Ready              19 Nov 18 11:43 EST
$ kubectl describe clusterpair new-cluster | grep paired
  Normal  Ready   2m    stork  Storage successfully paired
  Normal  Ready   2m    stork  Scheduler successfully paired

pxctl也可以用于列出集群配对。

$ pxctl_src cluster pair list
CLUSTER-ID  NAME               ENDPOINT                      CREDENTIAL-ID
c604c669    px-cluster-testing http://portworx-api.com:9001  a821b2e2-788f

我们的集群现在已经配对成功了。

在Kubernetes 1.12.0上测试工作负载

目前Kubernetes 1.10.3来源集群已经和1.12.0目标集群完成了配对，我们可以将运行的工作负载、配置以及数据从一个集群迁移到另一个集群上，来测试目标集群1.12.0Kubernetes上的应用程序是否能够正常运行。在迁移过程中及完成后，所有的Pods都将继续在来源集群上运行。我们现在有了两个集群，即蓝色和绿色，只在其运行的Kubernetes版本上存在差异。

$ kubectl config  use-context <1.10.3 source cluster context>

如果想要检查当前使用的Kubernetes版本，请运行kubectl version命令。这个命令能够输出当前的客户端和服务器版本。如下所示，服务器版本为1.10.3。

$ kubectl version --short | awk -Fv ‘/Server Version: / {print "Kubernetes Version: " $3}‘
Kubernetes Version: 1.10.3-eks

在1.10.3上部署应用程序

在迁移工作负载时，我们需要一个来源集群上已经存在的工作负载。在演示中，我们将使用Heptio的示例LAMP堆栈在来源集群上创建一个LAMP堆栈(http://docs.heptio.com/content/tutorials/lamp.html)，从而在MySQL卷上使用Portworx。这个堆栈包含了一个存储分类，包括Portworx、加密文件、HPH网页前端，以及一个具备Porworx卷副本的mySQL数据库。

$ kubectl create ns lamp   

$ kubectl create -f . -n lamp
job.batch "mysql-data-loader-with-timeout" created
storageclass.storage.k8s.io "portworx-sc-repl3" created
persistentvolumeclaim "database" created
deployment.extensions "mysql" created
service "mysql" created
deployment.extensions "php-dbconnect" created
service "web" created
secret "mysql-credentials" created

使用kubectl对Pods进行检索，确保其处于Running状态下。

$ kubectl get po -n lamp
NAME                                   READY     STATUS    RESTARTS   AGE
mysql-6f95f464b8-2sq4v                 1/1       Running   0          1m
mysql-data-loader-with-timeout-f2nwg   1/1       Running   0          1m
php-dbconnect-6599c648-8wnvf           1/1       Running   0          1m
php-dbconnect-6599c648-ckjqb           1/1       Running   0          1m
php-dbconnect-6599c648-qv2dj           1/1       Running   0          1m

提取Web服务。记录服务的CLUSTER-IP和EXTERNAL-IP。迁移完成后，这两个数据将会因为处于新的集群上而发生变化。

$ kubectl get svc web -n lamp -o wide
NAME      TYPE           CLUSTER-IP       EXTERNAL-IP             PORT(S)      AGE   SELECTOR
web       LoadBalancer   172.20.219.134   abe7c37c.amazonaws.com  80:31958/TCP 15m   app=php-dbconnect

访问端点或使用curl确认WordPress已安装、运行正常且已连接至MySQL。


MySQL连接

$ curl -s abe7c37c.amazonaws.com/mysql-connect.php | jq
{
  "outcome": true
}

验证是否也为MySQL容器创建了PVC。如下我们将看到PVC、数据库，各有三个副本用于部署。这个卷是MySQL的ReadWriteOnce卷块。

$ kubectl get pvc -n lamp
NAME       STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
database   Bound     pvc-c572277d-ec15-11e8-9f4d-12563b3068d4   2Gi        RWO            portworx-sc-repl3   28m

卷信息也可以使用pxctl进行展示。Volume list命令的输出如下。

$ pxctl_src -- volume list
ID                 NAME                                      SIZE  HA STATUS
618216855805459265 pvc-c572277d-ec15-11e8-9f4d-12563b3068d4  2 GiB 3  attached on 10.0.3.145

将应用程序迁移至Kubernetes 1.12.0

对本地kubectl客户端进行配置，使其使用正在运行1.12.0的目标集群。

$ kubectl config use-context <1.12.0 destination cluster context>

运行kubectl Version命令，这个命令将输出当前的客户端和服务器版本，如下看到运行的1.12.0。

$ kubectl version --short | awk -Fv ‘/Server Version: / {print "Kubernetes Version: " $3}‘
Kubernetes Version: 1.12.0

验证LAMP堆栈Pods是否正在运行中。如下所示，该集群的Namespace没有资源，即表示迁移还未发生。

$ kubectl get po
No resources found.

下一步，使用Stork客户端storkctl，创建一次迁移，将LAMP堆栈资源和卷从1.10.3集群迁移到1.12.0集群上。向storkctl create migration的命令的输入包括clusterPair、namespaces以及可选的includeResources和startApplications，从而将相关资源纳入并在迁移完成后启动应用程序。该命令的更多信息请点击这里(https://docs.portworx.com/cloud-references/migration/migration-stork/)。

$ storkctl --context <source-cluster-context>    create migration test-app-on-1-12    --clusterPair green    --namespaces lamp    --includeResources    --startApplications
Migration test-app-on-1-12 created successfully

迁移创建后，使用storkctl获取迁移状态。

$  storkctl --context <source-cluster-context> get migration
NAME               CLUSTERPAIR   STAGE     STATUS       VOLUMES   RESOURCES   CREATED
test-app-on-1-12   green         Volumes   InProgress   0/1       0/7         19 Nov 18 13:47 EST

pxctl也可以用于查看迁移状态。卷将显示出与迁移有关的STAGE和STATUS。

$ pxctl_src cloudmigrate status

CLUSTER UUID: 33293033-063c-4512-8394-d85d834b3716
TASK-ID            VOLUME-ID               VOLUME-NAME                               STAGE     STATUS
85d3-lamp-database 618216855805459265      pvc-c572277d-ec15-11e8-9f4d-12563b3068d4  Done      Initialized

完成后，迁移将显示STAGE → Final和 STATUS → Successful。

$ storkctl --context  <source-cluster-context> get migration

NAME               CLUSTERPAIR   STAGE     STATUS       VOLUMES   RESOURCES   CREATED
test-app-on-1-12   green         Final     Successful   1/1       7/7         19 Nov 18 13:47 EST

现在从目标集群中获得Pods。如下所示，PHP与MySQL现在都在目的集群上运行。

$ kubectl get po -n lamp
NAME                            READY     STATUS    RESTARTS   AGE
mysql-66d895ff69-z49jl          1/1       Running   0          11m
php-dbconnect-f756c7854-2fc2l   1/1       Running   0          11m
php-dbconnect-f756c7854-c48x8   1/1       Running   0          11m
php-dbconnect-f756c7854-h8tgh   1/1       Running   0          11m

注意CLUSTER-IP和EXTERNAL-IP现在已经发生了变化。这表示服务现在在新的Kubernetes 1.12集群上运行，并且因此包含了与此前不同的子网。

$  kubectl get svc web -n lamp -o wide
NAME      TYPE           CLUSTER-IP     EXTERNAL-IP            PORT(S)       AGE  SELECTOR
web       LoadBalancer   10.100.0.195   aacdee.amazonaws.com   80:31958/TCP  12m  app=php-dbconnect

如果网站能够在1.12.0集群上被访问、运行正常并且数据已经正确迁移到了1.12.0集群，则将会返回相同的输出内容。

Web网页前端

MySQL连接

$ curl -s http://aacdee.amazonaws.com//mysql-connect.php | jq
{
  "outcome": true
}

如下我们可以看到来源（下）和目标（上）集群上，kubectl get po -n lamp的输出。注意Pods的AGE，目的集群（上）中有最近迁移进来的LAMP堆栈。

两个集群在迁移后运行的是相同的程序和数据。

回顾整个过程：

  1. 第一步，1.10.3 EKS集群与1.12.0集群配对。
  2. LAMP堆栈（Linux, Apache, MySQL, PHP）部署到1.10.3集群上。
  3. 使用PX-Motion将Kubernetes部署、加密文件、副本集、服务、持久卷、持久卷连接，以及LAMP堆栈数据迁移到1.12.0集群上。
  4. 应用程序在1.12.0集群上被访问，并验证其是否正确运行。

持久卷和连接都使用PX-Motion（https://docs.portworx.com/cloud-references/migration）在各个集群之间进行迁移，Kubernetes资源和副本都使用Portworx Stork在目标集群上进行启动。

现在我们拥有了两个完全可运行的Kubernetes集群和两个环境，即蓝色和绿色部署环境。在实际操作中，你需要在绿色集群上进行所有测试，从而确保应用程序不会在新的集群上发生预期之外的问题。确认测试完成之后，将负载均衡从蓝色集群切换至新的绿色集群，此时部署就完成了！

**结论

PX-Motion具有将Portworx卷和Kubernetes资源在集群之间进行迁移的能力。上述样例就是使用PX-Motion帮助团队实现蓝绿部署的过程：对其工作负载和数据在新版本的Kubernetes上进行测试，并帮助团队在新的绿色集群上运行应用程序。在不同版本的Kubernetes上进行真实负载和数据测试，使得运营团队能够在发布新版本的Kubernetes之前获得充足的信心。蓝绿部署并不是PX-Motion唯一的功能，请查看我们其他的PX-Motion博文了解更多。**

原文地址：https://blog.51cto.com/14572152/2455301

时间： 2024-11-07 20:17:36

如何跨不同版本K8S，为有状态工作负载做蓝绿部署的相关文章

k8s 蓝绿部署之 Service Label

什么是蓝绿部署 蓝绿(blue/green):新版本与旧版本一起存在,然后切换流量 蓝绿部署流程图 K8S中如何实现蓝绿部署 通过k8s service label标签来实现蓝绿发布 通过Ingress 控制器来实现蓝绿发布 通过Istio来实现蓝绿发布,或者像Istio类似的服务 这次先讲通过k8s service label标签来实现蓝绿发布,Istio实现蓝绿发布下期再分享. k8s 蓝绿 yaml 配置 service.yaml 文件 apiVersion: v1 kind: Servi

k8s的Pod状态和生命周期管理

Pod状态和生命周期管理 一.什么是Pod? 二.Pod中如何管理多个容器? 三.使用Pod 四.Pod的持久性和终止 五.Pause容器 六.init容器 七.Pod的生命周期 (1)Pod phase(Pod的相位) (2)Pod的创建过程 (3)Pod的状态 (4)Pod存活性探测 (5)livenessProbe和readinessProbe使用场景 (6)Pod的重启策略 (7)Pod的生命 (8)livenessProbe解析 一.什么是Pod? Pod是kubernetes中你可以

MS SQL 事物日志传送能否跨数据库版本吗？

SQL SERVER的事物日志传送(log shipping)功能,相信很多人都使用过或正在应用,这是MS SQL提供的一个非常强大的功能,一般需要一个主数据库服务器(primary/production database server)和辅助数据库服务器(standby server)来完成这个配置,默认情况下,主数据库和辅助数据库的版本应该是一致的,那么如果这两个数据库版本不一致,会不会有什么问题?还能做log shipping配置吗? 那么数据库版本不一致分两种情况: 1: 类似于MS S

nginx版本隐藏以及访问状态

1:nginx版本隐藏之前访问 [email protected] conf]# curl -I http://www.zxl.com HTTP/1.1 200 OK Server: nginx/1.8.0 Date: Sat, 19 Dec 2015 14:07:29 GMT Content-Type: text/html Content-Length: 44 Last-Modified: Fri, 18 Dec 2015 05:23:18 GMT Connection: keep-alive

Lync server 2013高可用环境快速查看客户端的版本信息及连接状态

我们在进行Lync server 2013高可用部署的项目中,有一些用户会提出一些要求,比如:我是否能查看哪些客户端连接在哪台Lync Server 2013前端.前端是否达到了高可用的效果.客户端连接的版本信息等- - 针对以上客户提出的要求我们可以通过以下方法来实现: 准备工作: 1. 下载脚本文件:get-csconnections.ps1 2. 打开Lync server 2013前端到SQL之间的端口:1434 操作过程: 1. 将脚本文件拷贝到Lync server 2013 前端服

高版本jQuery设置checkbox状态注意事项

jQuery 1.9 以后, 使用 .attr(“checked”, true) 或  attr(“checked”, “checked”) 将无法正确设置 checkbox的状态, 同样的, 使用 .attr(“checked”) 也无法正确获取checkbox的状态 请从看到这篇文章开始, 使用 .prop(“checked”, true) 和 .prop(“checkbox”) 来设置和获取checkbox的勾选状态, 处于历史的考虑, 您可能更习惯使用 .is(“:checked”) 来

Windows下跨VC版本编译.pyd扩展(extension)模块

Windows下官方建议用与编译Python自身相同的Visual Studio版本来编译扩展模块,目前比较常用的Python版本对应的Visual Studio分别为: Python 2.7 - Visual Studio 2008(9) Python 3.3 & 3.4 - Visual Studio 2010(10) Python 3.5 - Visual Studio 2015(14) 最近安装了一个Python 3.5,需要编译Fast R-CNN的Python扩展模块,电脑上安装的V

纯手工搭建kubernetes(k8s)1.9集群 - (二)核心模块部署

1. 部署ETCD(主节点) 1.1 简介 ??kubernetes需要存储很多东西,像它本身的节点信息,组件信息,还有通过kubernetes运行的pod,deployment,service等等.都需要持久化.etcd就是它的数据中心.生产环境中为了保证数据中心的高可用和数据的一致性,一般会部署最少三个节点.我们这里以学习为主就只在主节点部署一个实例. 如果你的环境已经有了etcd服务(不管是单点还是集群),可以忽略这一步.前提是你在生成配置的时候填写了自己的etcd endpoint哦~

k8s实践17:监控利器prometheus helm方式部署配置测试

监控利器prometheus helm方式部署配置测试 1.部署helm 部署helm参考方法 后面使用helm部署grafana和prometheus,因此首先需要部署helm,保证helm能正常使用. 部署helm客户端过程见下: [[email protected] helm]# curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh % Total % Receive