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:primaryipList:-ip:nodeName:abcremoteList:-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只会标识出主位置不符合预期，不会做强制性回切。-全文完-