Kosmos 实战系列：MySQL Operator 有状态服务的跨 AZ 集群平滑迁移

作者：于磊春，中国移动云能力中心软件研发工程师，专注于云原生、微服务、算力网络等

Kosmos 是移动云今年在云原生领域重点打造的一款超级集群管理项目，旨在实现多云多集群的统一管理编排、网络连通、多级调度等能力。本文旨在介绍基于 Kosmos 的有状态服务管理、Multi-Cluster Service(MCS)等能力实现 MySQL 集群跨 AZ 平滑迁移。

注：所有实现以具体实操进行展示并进行相关说明，可参照实现。

一、环境背景

三套集群 cluster1(X.X.8.171)、cluster2(X.X.8.174)、cluster3(X.X.7.8)，一套集群对应一个 AZ，cluster1 为主集群，其他 cluster2、cluster3 两个为子集群。

二、前提条件

1. 集群已安装 Kosmos 服务；

2. 集群间物理网络及容器网络已拉通。

上述前提条件可参照此链接（https://mp.weixin.qq.com/s/6zZXPP9FKbgWV1JUYv-iVw）完成，MySQL Operator 的链接地址为：https://github.com/kosmos-io/mysql-operator。

三、详细操作

Step1:

基于前提条件做检查，关注主集群 cluster1(X.X.8.171)中 Kosmos 的两个重要管理服务（clustertree-cluster-manager、kosmos-scheduler），确保服务已安装及状态正常。

注：整体实现不局限于上述两个服务，可使用 Kosmos 中 clusterlink 实现多集群容器网络的拉通，kosmos-scheduler 与默认调度器可共存，亦可替代，有状态实例（含 PV/PVC）需通过 kosmos-scheduler 完成调度。

Step2:

在主集群 cluster1(X.X.8.171)中安装 MySQL Operator。

Step1 和 Step2 完成了基础工作，下面分四种场景进行展示（主备两副本）：

【场景一】

场景描述：未加入子集群时，主备实例均在主集群中创建并运行。

Step3:

在主集群 cluster1(X.X.8.171)中针对【场景一】修改 MySQL Cluster 的安装文件即 secret、mysql-cluster 的 CR 文件（文档演示的是通过执行 yaml 文件的方式，亦可通过 Helm 进行）。

apiVersion: v1kind: Secretmetadata:  namespace: test  name: my-secrettype: Opaquedata:  ROOT_PASSWORD: XXXXXX

上述为 secret.yaml 文件

apiVersion: mysql.presslabs.org/v1alpha1kind: MysqlClustermetadata:  name: mysql-cluster  namespace: testspec:  replicas: 2  secretName: my-secret  image: docker.io/percona:5.7  mysqlVersion: "5.7"  podSpec:      podAntiAffinity:        requiredDuringSchedulingIgnoredDuringExecution:        - labelSelector:            matchLabels:              mysql.presslabs.org/cluster: mysql-cluster          topologyKey: kubernetes.io/hostname  volumeSpec:    persistentVolumeClaim:      storageClassName: openebs-hostpath      accessModes:        - ReadWriteOnce      resources:        requests:          storage: 1Gi

上述为 mysql-cluster.yaml 文件

Step4:

在主集群 cluster1(X.X.8.171)中执行 Step3 中修改后的 CR 文件。

Step5:

在主集群 cluster1(X.X.8.171)中查看 Step4 执行后的实例情况。

Step6:

验证主集群 cluster1(X.X.8.171)中部署 MySQL 集群的可用性，修改其中 service 为 NodePort 暴露访问。

以上完成【场景一】的整体演示。

【场景二】

image-10

场景描述：加入子集群 cluster2 后，主备实例分别在主集群 cluster1 和子集群 cluster2 中创建并运行。

Step7:

针对【场景二】，加入子集群 clutser2(X.X.8.174)，具体加入操作可以参照此链接(https://mp.weixin.qq.com/s/6zZXPP9FKbgWV1JUYv-iVw)。

Step8:

针对【场景二】，在主集群 cluster1(X.X.8.171)中修改 MySQL Cluster 的安装文件即 secret、mysql-cluster 的 CR 文件（文档演示的是通过执行 yaml 文件的方式，亦可通过 Helm 进行）。

apiVersion: mysql.presslabs.org/v1alpha1kind: MysqlClustermetadata:  name: mysql-cluster  namespace: test-1209spec:  replicas: 2  secretName: my-secret  image: docker.io/percona:5.7  mysqlVersion: "5.7"  podSpec:    tolerations:    - key: "kosmos.io/node"      operator: "Equal"      value: "true"      effect: "NoSchedule"    affinity:      nodeAffinity:        requiredDuringSchedulingIgnoredDuringExecution:          nodeSelectorTerms:          - matchExpressions:            - key: kubernetes.io/hostname              operator: NotIn              values:              - kosmoscluster1-1      podAntiAffinity:        requiredDuringSchedulingIgnoredDuringExecution:        - labelSelector:            matchLabels:              mysql.presslabs.org/cluster: mysql-cluster          topologyKey: kubernetes.io/hostname  volumeSpec:    persistentVolumeClaim:      storageClassName: openebs-hostpath      accessModes:        - ReadWriteOnce      resources:        requests:          storage: 1Gi

上述为 mysql-cluster.yaml 文件，【节点亲和性】需要修改 values 的值为主集群中两个节点中任意一个，【Pod 互斥性】将 MySQL Cluster 的主备实例分发至主集群 cluster1(X.X.8.171)和子集群 cluster2(X.X.8.174)，标记处修改为 MySQL Cluster 对应的 name。

Step9:

在主集群 cluster1(X.X.8.171)中执行 Step8 中修改后的 CR 文件。

Step10:

在主集群 cluster1(X.X.8.171)和子集群 cluster2(X.X.8.174)中查看 Step9 执行后的实例情况。

上述图中主集群 cluster1(X.X.8.171)中 MySQL 集群主备实例均为 Running。

上述图中子集群 cluster2(X.X.8.174)中 MySQL 集群主实例为 Running。

Step11:

验证【场景二】主集群 cluster1(X.X.8.171)和子集群 cluster2(X.X.8.174)中主备各一实例的 MySQL 集群的可用性，修改主集群中 service 为 NodePort 暴露访问。

主集群 cluster1(X.X.8.171)存在对应 Service 可以对外访问，子集群 cluster2(X.X.8.174)下发的是 Pod，对应的 Service 可通过 Kosmos 的 Multi-Cluster Service(MCS)能力【自动】或【手动】进行下发，此处演示【手动】，下发后可通过其 NodePort 对外进行访问。

Step12:

先在主集群 cluster1(X.X.8.171)中开启 Multi-Cluster Service(MCS)能力，再在子集群 cluster2(X.X.8.174)创建 ServiceImport 的 CR 并执行。

apiVersion: multicluster.x-k8s.io/v1alpha1kind: ServiceExportmetadata:  name: mysql-cluster-mysql-master   #需要下发的Service的name  namespace: test-1209

上述 CR 文件为主集群 cluster1 中 serviceExport.yaml。

apiVersion: multicluster.x-k8s.io/v1alpha1kind: ServiceImportmetadata:  name: mysql-cluster-mysql-master    #与主集群中下发的Service保持一致  namespace: test-1209spec:  type: ClusterSetIP # ClusterSetIP 对应 ClusterIP 类型的service，Headless 对应 Headless 类型的service  ports:  - port: 31752    protocol: TCP  - port: 31238    protocol: TCP

上述 CR 文件为子集群 cluster2 中 serviceImport.yaml。

注：Multi-Cluster Service(MCS)【自动】下发能力可通过在 clustertree 服务中启动参数进行配置，具体参数为：auto-mcs-prefix(配置统一的 Namespace 前缀)。

Step13:

验证【场景二】中 MySQL 集群主实例在子集群 cluster2 (X.X.8.174)中可用性及 Kosmos 的 Multi-Cluster Service(MCS)去中心化能力。

以上完成平滑迁移过程中【场景二】的整体演示。

【场景三】

场景描述：加入子集群 cluster2 后，主备实例均平滑迁移至子集群 cluster2 中创建并运行。

Step14:

针对【场景三】，在主集群 cluster1(X.X.8.171)中修改 MySQL Cluster 的安装文件即 secret、mysql-cluster 的 CR 文件（文档演示的是通过执行 yaml 文件的方式，亦可通过 Helm 进行）。

apiVersion: mysql.presslabs.org/v1alpha1kind: MysqlClustermetadata:  name: mysql-cluster  namespace: test-1209-1spec:  replicas: 2  secretName: my-secret  image: docker.io/percona:5.7  mysqlVersion: "5.7"  podSpec:    tolerations:    - key: "kosmos.io/node"      operator: "Equal"      value: "true"      effect: "NoSchedule"    affinity:      nodeAffinity:        requiredDuringSchedulingIgnoredDuringExecution:          nodeSelectorTerms:          - matchExpressions:            - key: kubernetes.io/hostname              operator: NotIn              values:              - kosmoscluster1-1              - kosmoscluster1-2  volumeSpec:    persistentVolumeClaim:      storageClassName: openebs-hostpath      accessModes:        - ReadWriteOnce      resources:        requests:          storage: 1Gi

上述为 mysql-cluster.yaml 文件，【节点亲和性】需要修改 values 的值为主集群中所有节点名，此时 MySQL 集群的主备实例均下发至子集群 cluster2(X.X.8.174)中。

Step15:

在主集群 cluster1(X.X.8.171)中执行 Step14 中修改后的 CR 文件。

Step16:

在主集群 cluster1(X.X.8.171)和子集群 cluster2(X.X.8.174)中查看 Step15 执行后的实例情况。

在主集群 cluster1(X.X.8.171)中观察到 MySQL 集群的备实例未能正常启动，需到子集群 cluster2(X.X.8.174)中进行问题查看。

在子集群 cluster2(X.X.8.174)中观察到 MySQL 集群的备实例中 init 容器报错，请求 Service 失败，此时可以考虑使用 Kosmos 中 Multi-Cluster Service(MCS)能力（可参考 Step12 实现）。

Step17:

参照 Step12 将主集群 cluster1(X.X.8.171)的 Service 下发至子集群 cluster2(X.X.8.174)中,观察主集群 cluster1(X.X.8.171)和子集群 cluster2(X.X.8.174)中实际情况。

Step18:

验证【场景三】主集群 cluster1(X.X.8.171)和子集群 cluster2(X.X.8.174)中 MySQL 集群的可用性，修改主集群 cluster1(X.X.8.171)中 service 为 NodePort 暴露访问。

以上完成平滑迁移过程中【场景三】的整体演示。

【场景四】

场景描述：加入子集群 cluster2 和子集群 cluster3 后，主备实例分别平滑迁移至子集群 cluster2 和子集群 cluster3 中创建并运行。

Step19:

针对【场景四】，注入子集群 cluster3(X.X.7.8)，具体注入操作可以参照此链接(https://mp.weixin.qq.com/s/6zZXPP9FKbgWV1JUYv-iVw)。

Step20:

针对【场景四】，在主集群 cluster1(X.X.8.171)中修改 MySQL Cluster 的安装文件即 secret、mysql-cluster 的 CR 文件（文档演示的是通过执行 yaml 文件的方式，亦可通过 Helm 进行）。

apiVersion: mysql.presslabs.org/v1alpha1kind: MysqlClustermetadata:  name: mysql-cluster  namespace: test-1209-2spec:  replicas: 2  secretName: my-secret  image: docker.io/percona:5.7  mysqlVersion: "5.7"  podSpec:    tolerations:    - key: "kosmos.io/node"      operator: "Equal"      value: "true"      effect: "NoSchedule"    affinity:      nodeAffinity:        requiredDuringSchedulingIgnoredDuringExecution:          nodeSelectorTerms:          - matchExpressions:            - key: kubernetes.io/hostname              operator: NotIn              values:              - kosmoscluster1-1              - kosmoscluster1-2      podAntiAffinity:        requiredDuringSchedulingIgnoredDuringExecution:        - labelSelector:            matchLabels:              mysql.presslabs.org/cluster: mysql-cluster          topologyKey: kubernetes.io/hostname  volumeSpec:    persistentVolumeClaim:      storageClassName: openebs-hostpath      accessModes:        - ReadWriteOnce      resources:        requests:          storage: 1Gi

上述为 mysql-cluster.yaml 文件，【节点亲和性】需要修改 values 的值为主集群中所有节点（当前集群由两节点组成），【Pod 互斥性】将 MySQL Cluster 的主备实例分发至子集群 cluster2(X.X.8.174)和子集群 cluster3(X.X.7.8)，标记处修改为 MySQL Cluster 对应的 name。

Step21:

在主集群 cluster1(X.X.8.171)中执行 Step20 中修改后的 CR 文件。

Step22:

在主集群 cluster1(X.X.8.171)、子集群 cluster2(X.X.8.174)和子集群 cluster3(X.X.7.8)中分别查看 Step21 执行后的实例情况。

以上实际情况可以观察到 MySQL 集群的主备实例平滑迁移至两个子集群中创建并运行。

Step23:

验证【场景四】主集群 cluster1(X.X.8.171)、子集群 cluster2(X.X.8.174)和子集群 cluster3(X.X.7.8)中 MySQL 集群的可用性，修改主集群 cluster1(X.X.8.171)中 service 为 NodePort 暴露访问。

此时再次验证 Kosmos 中 Multi-Cluster Service(MCS)的去中心化能力，分别在本地客户端连接另外两个子集群 cluster2（X.X.8.174）和子集群 cluster3（X.X.7.8）进行测试。

以上完成平滑迁移过程中【场景四】的整体演示。

四、总结

本文中四个场景展示了 Kosmos 对有状态服务及其 Operator 控制器的支持，MySQL Operator 创建的 MySQL 实例可跨 AZ 集群平滑迁移，在【场景二】和【场景三】中展示了 Kosmos 中 Multi-Cluster Service(MCS)的【手动】下发 Service 和【自动】下发 Service 的全部过程并进行验证，最终结合【场景四】完整展示了 Kosmos 中 Multi-Cluster Service(MCS)对 Service 的去中心化能力并进行验证，Kosmos 的有状态服务管理、Multi-Cluster Service(MCS)能力已通过开源 MySQL Operator 得到充分验证，Kosmos 的使用简单、高效且稳定，欢迎大家深度使用 Kosmos！！！

五、欢迎交流