MySQL-Operator容器化方案概述.docx

MySQL Operator容器化方案概述

【导读】与内存库的Redis数据库比起来，容器化MySQL有着更多的需求，本文介绍了MySQL Opreator 容器化方案及设计思路。

以前文章分享过Redis Operator容器化方案（点击标题可阅读：《Redis Sentinel Operator 容器化解读》，《Redis Cluster 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最重要的任务是维持集群正常运行，对于这些运维操作在设计时采用了一个稳妥的方案：
· 所有的运维操作必须基于维护流程判断集群状态正常（有且仅有一个主节点，其余节点均运行正常且为从节点）的情况下才可进行
· 在状态转换流程中设置操作的优先级，先进行优先级高的操作，如新加节点的优先级高于删除节点的优先级
· 如果涉及到类似于多个节点添加的批量操作，Operator会将批量操作拆分为单个操作的顺序执行，每步操作完成后确认集群状态正常才能继续下一步操作
整体流程如下图所示：

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