一、K8S 有状态与无状态服务

        随着Kubernetes平台在容器云计算领域的火热，云原生 一词也被提的越来越频繁。各类应用纷纷走上了容器化、云原生化的道路，无状态服务应用在Kubernetes平台上的运行，已经得到了大规模生产级别的实践认可。Kubernetes对基础设施关注更少、自动化程度更高，我们都知道 Kubernetes 在无状态应用部署管理，尤其是微服务领域，已经大放异彩。例如管理一个无状态的 Web 服务，我们可以使用 Kubernetes 的 Deployment 部署多副本并且进行弹性伸缩和滚动升级，然后使用 Sevice 进行负载均衡，依靠 Kubernetes 原生的资源对象基本上可以覆盖无状态服务的整个生命周期管理。
        传统的有状态应用部署方式，如果是以脚本和运维文档的方式沉淀，缺乏标准化的管理会使得运维的学习成本和使用门槛随着使用过程中的修改而急速升高；而使用管控服务，则需要引入更多的底层依赖去满足管控服务与主机侧的交互的虚拟化和管理设施；在开发应用中，对于 redis、mariadb这类“有状态”的应用，Kubernetes 似乎并没有准备好接纳它们，主要表现在：1.对外部存储或网络有依赖，比如 mariadb每个副本都需要稳定的存储卷。2.实例之间有拓扑关系，比如 mariadb Cluster 中存在主从关系分布。
        这就给 Kubernetes 带来了挑战，如果仍使用 Deployment 和 ReplicaSet 这些对象，Pod 在故障时，对于mariadb只是简单地重启无法使得Pod能恢复到健康的集群状态，同时也会自己所使用的存储卷。

二、Kubernetes Operator控制器

      在有状态服务支持方面，基于 Operator 的方案被证明是一种有效的方案，移动云电脑产品组也基于 Operator 完成了对 mariadb 等有状态服务的容器化。
       k8s中的Controller控制器主要维护 k8s 资源对象，分析当前状态与期望状态的差别。Operator 是由 CoreOS 开发的，用来扩展 Kubernetes API，特定的应用程序控制器，它用来创建、配置和管理复杂的有状态应用，如数据库和缓存。Operator 基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的领域知识。创建Operator 的关键是CRD（Custom Resource Definition）的设计。Kubernetes 1.7 版本以来就引入了自定义控制器的概念，该功能可以让开发人员扩展添加新功能，更新现有的功能，并且可以自动执行一些管理任务，这些自定义的控制器就像 Kubernetes 原生的组件一样，Operator 直接使用 Kubernetes API进行开发，也就是说他们可以根据这些控制器内部编写的自定义规则来监控集群、更改 Pods/Services、对正在运行的应用进行扩缩容。
        Operator遵循k8s声明式编程理念，由对象资源定义及控制器构成，封装特定应用领域的运维开发知识和经验，可以用来管理有状态应用。

三、云电脑的mariadb operator实践

        在云电脑项目中，产品的目标是快速部署mariadb的主从集群，同时支持mariadb集群高可用。下图为云电脑mariadb容器化系统架构：

                                                                                                                                                                                                                                                       在mariadb的主从集群管理上，数据库连接请求到达后，api server通过编写的CRD对请求进行转发，CRD中编写着mariadb数据库中的版本，端口，存储信息以及配置文件；同时，规约了集群中的副本数和高可用等信息。Master集群会随时查看CRD文件，在mariadb operator pod节点会对其他的node节点进行调度，node节点间通过operator控制器实现集群的自治和管理，ks8对容器进行编排，使得pod间更为稳定，pod启动有序，且pod扩容安全。进行下图中部分CRD信息:     

云电脑CRD

          其次，说下在云电脑中mariadb的高可用方案。MHA（Master High Availability）目前在mariadb高可用方面是一个相对成熟的解决方案, 在mariadb故障切换过程中，MHA能做到在0-30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

            移动云电脑项目中，mha-manager （管理节点）部署在 Operator 容器中，mha-node（数据节点）为边车容器，在docker的镜像中设置ssh免密认证。数据节点运行在每台mariadb服务器上，管理节点会定时观察集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

作者：牛强

链接： https://ecloud.10086.cn/api/query/developer/user/home.html#L2FwaS9xdWVyeS9kZXZlbG9wZXIvZm9ydW0vZmxvb3JsaXN0Lmh0bWw/aWQ9NzUyOTFiZWVmMjc4NGEyNTgyODAzMDQ3MTU1MGZjZGY=

 来源：移动云官网开发者社区