MYSQL OPERATOR 容器化方案介绍

admin 2022年6月30日23:30:32安全开发MYSQL OPERATOR 容器化方案介绍已关闭评论4 views2252字阅读7分30秒阅读模式

以前文章分享过Redis Operator容器化方案,本次介绍MySQL Operator容器化方案。与内存库的Redis数据库比起来,容器化MySQL有着更多的需求,主要有以下三个方面:

  • MySQL对存储的要求很高
  • MySQL Pod的IP需要固定
  • MySQL需要支持同城灾备

MySQL容器化拓扑结构

固定MySQL Pod IP可以在K8S上使用Calico网络插件实现。存储方面使用高性能分布式存储或者直接挂载本地盘都可达到要求,这些不在本文做重点介绍。

MySQL容器化有同城灾备需求。对于MySQL部分,我们使用MySQL MGR单主模式,将MGR节点分散在本地/同城运行,正常情况下主节点运行在本地,灾备切换时将主节点切换至同城。对于K8S集群部分,我行K8S集群没有进行跨本地/同城部署,所以MySQL MGR节点会分布在两个K8S集群运行。对于MySQL服务暴露部分,在每个K8S集群上为每个MGR集群各建立Read、Write Service,通过K8S Service机制对外暴露MySQL 服务。整体拓扑结构如下所示:

图片

MySQL Operator功能逻辑

MySQL Operator的功能包括MGR集群创建、集群维护、CPU内存资源升级、MGR节点扩缩容、节点迁移等。由于MGR集群跨K8S部署,所以在Operator的逻辑上不能只管控本地资源,还需关注在同城运行的那一部分MGR节点的情况。

MGR集群创建

在MySQL MGR集群CR资源定义中包含以下三个字段:

  • flag字段为primary标识MGR的主应该在本地
  • ipList定义部署在本地K8S集群的MGR Pod列表,以及具体的Pod IP和所在K8S节点
  • remoteList定义部署在同城K8S集群的MGR Pod列表;本地Operator会通过该字段中的IP地址尝试连接同城MGR节点,以判断同城MGR节点是否连通以及角色是否正常
spec:
  flag: "primary"
  ipList:
  - ip: ""
    nodeName: "abc"
  remoteList:
  - ip: ""
    nodeName: "abc"

在MGR集群创建流程中,两边Operator均需确定ipList和remoteList中的Pod IP地址均可连通,确定MGR集群所属的Pod均已启动后才能执行MGR集群的创建工作。创建的时候,flag为primary侧的Operator会在本K8S集群中选出一个MGR Pod进行主节点的引导启动,其余本地Pod和flag为standby侧集群的Pod均启动为从节点。

MGR集群维护

集群维护功能是为了保证MGR集群按照预期运行,集成了各种异常场景下处理逻辑,主要包括以下几个部分:

  • 保证Service、PVC、Configmap等需要的K8S资源按照预期创建
  • 保证MySQL Pod数量和运行状态正常
  • 保证MySQL Pod的角色标签和实际的MGR角色一致
  • 维持Pod内的MySQL MGR进程启动
  • 判断MGR主节点是否切换,并进行切主后操作等

除了Operator的集群维护功能,另一个保证服务持续可用的是MySQL自身的MGR机制。在整体设计中,我们对Operator和MGR两种机制管控范围的做了清晰的边界划分:即Operator只保证MGR运行所需的环境正常,如节点数、进程启动状态、配置等正常,但涉及到主节点切换等MGR机制内部的事情,Operator只做观察并把最新状态反映到CR的Status字段中而不去做干预。在Operator的设计中,只有三种情况会进行主节点干预:一是集群新建的情况;二是在确认所有集群节点都为从节点的情况,选出gtid最大的节点启动为主;三是收到灾备切换的请求,会将主切到flag=primary的一侧。

MGR集群运维操作

Operator支持对MGR集群进行一些常规的运维操作,包括本地/同城节点的上线、下线,Pod 内存、CPU资源的扩缩容、Pod使用镜像的更换以及MySQL的配置文件更新等。Operator最重要的任务是维持集群正常运行,对于这些运维操作在设计时采用了一个稳妥的方案:

  1. 所有的运维操作必须基于维护流程判断集群状态正常(有且仅有一个主节点,其余节点均运行正常且为从节点)的情况下才可进行
  2. 在状态转换流程中设置操作的优先级,先进行优先级高的操作,如新加节点的优先级高于删除节点的优先级
  3. 如果涉及到类似于多个节点添加的批量操作,Operator会将批量操作拆分为单个操作的顺序执行,每步操作完成后确认集群状态正常才能继续下一步操作

整体流程如下图所示:

图片

MGR集群灾备切换

灾备切换包含两部分:第一部分是MGR集群的主节点切换到同城集群;第二部分是客户端网络流量打到同城集群。对于第二部分的实现有手动改客户端访问地址、更改DNS指向、使用代理转发等多种方法,本文不做讨论。对于第一部分,Operator做了一个便捷化的实现,在检测到flag字段由standy变为primary的时候会主动发起一次切主操作,试图将主切换到现在的primary这边。要注意的是,虽然flag字段标识主节点应该在哪一边,但是Operator不对该预期做强制性保证,MGR内部机制或者手工将主切换到flag=standby一边也是允许的,Operator只会标识出主位置不符合预期,不会做强制性回切。

作者简介

孟玉立,中国民生银行信息科技部开源软件支持组工程师,目前主要负责Kubernetes、Redis的源码研究和工具开发等相关工作。

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年6月30日23:30:32
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  MYSQL OPERATOR 容器化方案介绍 http://cn-sec.com/archives/1149156.html