麒麟v10 上部署 TiDB v5.1.2 生产环境优化实践
1612
2023-04-22
温故知新-EverDB容器化之旅
今天给大家带来“你好,我是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原理图
动态模式下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容器化实现不仅便于我们在混沌实验中实现故障注入,也使我们在数据库云化道路上迈出了里程碑式的一步!
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。