今天给大家带来“你好，我是EverDB！”系列文章的第二篇—容器化之旅。
容器天生的部署快速、轻量、便于调度特性非常适合故障场景的模拟，因此EverDB容器化是我们的第一步工作。本篇文章将介绍基于k8s的EverDB容器化实现方案。
为什么选择k8s
k8s全称Kubernetes，是一个开源的、基于容器技术的分布式架构解决方案，提供了容器自动化部署、管理、编排，伸缩等能力，使应用容器化更加简单高效。同时，k8s平台在故障转移，资源调度、隔离，负载均衡方面的特性，也更契合EverDB自身架构特点和测试、管理需求，因此EverDB容器化方案选定基于k8s来实现。
部署到k8s的技术路线
Helm工具
Helm是k8s的包管理器，类似我们在Ubuntu中使用的apt、Centos中使用的yum一样，能快速查找、下载和安装软件包。在Helm里面，最重要的应用包叫Charts，这是一个应用的定义描述，里面包括了这个应用的一些元数据，以及该应用的k8s资源定义模板及其配置。在拥有足够完善的Charts情况下，只需要简单的install就可以快速部署服务。
Operator思路
Operator是用k8s原生方式去管理应用的一种实现思路，通过k8s扩展API，使用CRD自定义资源对象，并实现对应的控制器来实现对应用的部署及管理。
Helm和Operator两种方案在k8s应用管理上各有优势，前者的优势在于将资源模板化，方便共享，并在不同的配置中复用；后者则更加针对复杂应用的自动化管理。此次部署到k8s平台，考虑到实现成本和当前需求，决定基于Helm来实现EverDB容器化方案。
整体方案
在k8s平台上，应用可分为有状态和无状态两种。EverDB的数据节点MySQL、调度节点Grid、配置节点ZooKeeper均需要保持运行状态参数并对外提供稳定服务，数据节点和配置节点还需要将数据和配置信息持久化到存储器，因此部署到k8s上均属于StatefulSet类型的有状态应用。
EverDB架构图
EverDB的三个组件设计需要配置的k8s资源如下表所示：
Pod控制器类型 | ConfigMap | NodePort | 无头服务 | 持久化存储 | 辅助容器 | |
Mysql | StatefulSet | ● | ● | ● | ● | ● |
Zookeeper | StatefulSet | ● | ○ | ● | ● | ○ |
dbscale | StatefulSet | ● | ● | ● | ○ | ○ |
MySQL作为EverDB的底层数据存储引擎，在部署至k8s时，除需具备数据实例配置、实例初始化、数据持久化存储，对外访问服务等功能外，还要有监控、备份等辅助容器；
ZooKeeper作为EverDB的配置管理节点，其所管理的配置信息同样需要持久化存储，对外提供访问服务；
Grid作为调度节点，其元数据保存在底层数据节点上，而配置参数通过初始化ConfigMap完成参数加载后，保存到远端配置节点ZooKeeper上，即使发生Pod故障，Grid可以从ZooKeeper拉取配置信息，因此其不需要持久化的PV存储数据。
服务访问
EverDB对外需要提供数据库服务，对内组件间也需要能够互联互通，那么各个Pod独立运行，他们之间的联系由谁来建立呢？
这就要介绍k8s的核心资源对象中Service，Service是一个抽象概念，它定义了一组Pod的逻辑集合和一个访问它们的负载均衡策略。k8s的Service可以定义一个集群内部的服务访问入口地址（ClusterIP），Service与Pod间通过LabelSelector来建立关联，应用通过这样一个入口地址访问其背后的一组Pod实例。这样，在Pod发生销毁或重建导致PodIP发生变化时，Service可以自动感知且提供的ClusterIP不会发生改变，我们仍可以通过Service访问后端的Pod。
而对于EverDB集群内部节点之间的通信，需要实现一对一通信且不受PodIP 变化的影响。比如EverDB集群中的Mysql主从实例，在进行主从同步时，从实例（Slave）需要能直接访问主实例（Master）这一确切Pod，并不需要负载均衡，且在任何PodIP 发生变化时主从同步均不受影响，显然上述Service的定位并不适合这样的场景。
别急，k8s还设计了HeadlessService（无头服务）这一特殊类型的Service。HeadlessService不分配ClusterIP，访问者可以通过解析该Service的DNS来获取Pod的地址，就像访问域名一样。HeadlessServie 的域名一般是“{podname}.{headlessservice}.{namespace}”的形式。与Deployment类型Pod的随机化podname相比，StatefulSet类型的Pod，其podname格式为{StatefulSetname}-{固定编号}，这也使得即使对Pod进行重启、节点迁移等操作，域名本身并不会发生变动。
EverDB数据节点部署至k8s示例图
因此对于EverDB集群，我们使用基于ClusterIP 类型的Service对外提供EverDB数据库服务统一入口，对内提供多个Grid调度节点的负载均衡能力；使用HeadlessService 实现EverDB集群内部节点间的通信能力，且不受PodIP 变化影响。
持久化存储
EverDB作为有状态的应用，部署在k8s平台需要解决存储问题，即当应用Pod被删除或重新创建时，内部数据不会丢失。PV（PersistentVolume）可以看作k8s集群可用的存储资源，PVC（PersistentVolumeClaim）则是对存储资源的需求。对于存储资源，k8s平台支持两种供应模式：静态模式（Static）和动态模式（Dynamic），在EverDB集群中，已支持这两种供应模式。
在静态模式中，需要集群管理员通过手动方式创建PV，EverDB采用的是基于LocalPV方法的持久化存储，该方法主要应用于生产环境中，LocalPV对应的存储介质通常是一块额外挂载在宿主机的磁盘，实现“一个PV一块盘”，不仅能够有效减少宿主机宕机导致的数据丢失，而且增强了集群存储扩展的能力。
静态模式下LocalPV和PVC原理图
在动态模式中，EverDB采用了基于HostPath的方法，该方法主要应用于开发测试环境中，使用宿主机本地目录，有效避免IO开销并拥有更高的读写性能。同时为了避免单机测试的问题，结合了Github开源项目LocalPath Provisioner，可以有效利用集群节点中的本地存储，通过SrorgeClass（存储类）的设置，只需PVC对存储类型进行声明，系统将自动完成PV的创建和绑定。
动态模式下StorageClass、PV和PVC原理图
配置管理
容器的启动总是需要些参数的，给容器内应用传递参数通常有以下几种方式：
1、直接将配置文件打包到镜像中；
2、在定义Pod时，添加自定义命令行参数，设定args：[“命令参数”]；
3、使用环境变量来给Pod中的应用传参修改配置。
ConfigMap的设计就是为了让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性，一个ConfigMap其实就是一系列配置信息的集合。
ConfigMap存在两种方式将配置参数注入到容器中：
1、将环境变量直接定义在ConfigMap中，当Pod启动时，通过env来引用ConfigMap中定义的环境变量；
2、将一个完整的配置文件封装，通过共享卷的方式挂载进Pod中实现给应用传参。
EverDB的三个组件的Pod在容器拉起时，需要配置性能参数，主从信息等。EverDB配置容器运行参数时，对于复杂的配置文件信息，采用ConfigMap创建配置文件的形式实现，在Pod启动时，将其挂载到容器中，而对于一些简单的运行参数，则是通过环境变量的形式注入到容器中。
依据上述EverDB各组件对ConfigMap、StatefulSet、持久化存储、服务访问等需求，创建对应的Helm模板，将EverDB的各组件封装为Chart包，在启动子组件时，只需要对一些必要的参数进行更改设置，即可完成定制化的EverDB集群安装。即避免了手动部署易于出错的问题，又能方便集群在k8s上的的定制化与快速部署，稳定且高效，灵活而优雅。
结束语
EverDB容器化实现不仅便于我们在混沌实验中实现故障注入，也使我们在数据库云化道路上迈出了里程碑式的一步！
