作者:于磊春,中国移动云能力中心软件研发工程师,专注于云原生、微服务、算力网络等
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 两个为子集群。
二、前提条件
- 集群已安装 Kosmos 服务;
- 集群间物理网络及容器网络已拉通。
上述前提条件可参照此链接(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: v1
kind: Secret
metadata:
namespace: test
name: my-secret
type: Opaque
data:
ROOT_PASSWORD: XXXXXX
上述为secret.yaml文件
apiVersion: mysql.presslabs.org/v1alpha1
kind: MysqlCluster
metadata:
name: mysql-cluster
namespace: test
spec:
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 暴露访问。
以上完成【场景一】的整体演示。
场景描述:加入子集群 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/v1alpha1
kind: MysqlCluster
metadata:
name: mysql-cluster
namespace: test-1209
spec:
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/v1alpha1
kind: ServiceExport
metadata:
name: mysql-cluster-mysql-master #需要下发的Service的name
namespace: test-1209
上述 CR 文件为主集群 cluster1 中 serviceExport.yaml。
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceImport
metadata:
name: mysql-cluster-mysql-master #与主集群中下发的Service保持一致
namespace: test-1209
spec:
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/v1alpha1
kind: MysqlCluster
metadata:
name: mysql-cluster
namespace: test-1209-1
spec:
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/v1alpha1
kind: MysqlCluster
metadata:
name: mysql-cluster
namespace: test-1209-2
spec:
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!!!
本文由mdnice多平台发布