容器云平台的备份与恢复技术.docxVIP

????

???

容器云平台的备份与恢复技术

???

?

?

?

?

???

???

?

???

?

?

容器云平台本身是一个非常复杂的底层基础设施平台，它主要用于实现业务的持续集成与发布、自动部署、滚动升级、自动扩缩容、租户管理、安全认证等功能模块。这些都是为了实现业务的易用、易发布、强安全等。如何能保证自身的高可用性，这将是衡量用户体验的关键指标，比如在其所依赖的存储、网络等物理设备出现故障时，如何保证其上运行的业务的高可用，无中断或者用户无感知，就需要通过有效的备份与容灾等技术手段来实现。

大家都知道，容器云平台包括容器底层的容器编排系统及自身的平台软件系统。底层可以使用多种容器编排系统，开源的主要有Mesos、Swarm及Kubernetes。这里主要讲解Kubernetes(K8S)容器编排集群的备份与恢复，软件平台本身则通过K8S来实现。

我们接下来，会从K8S平台架构开始，通过介绍平台架构，让我们了解平台在故障时，哪些组件才是影响服务的高可用性及恢复性的关键，并分享相关的备份恢复与容灾技术。

1K8S平台架构

Kubernetes(K8S)是用来进行对业务容器实现有效的高可用性的容器编排系统，并可以用来管理集群节点，来按需分配CPU、内存等资源给相关的业务容器。既然是管理集群，那么就存在被管理节点，针对每个Kubernetes集群都由3~5个Master做为高可用来负责管理和控制集群节点。我们通过Master对每个节点Node发送命令来实现业务容器的运行。简单来说，Master就是管理者，Node就是被管理者。Node可以是一台物理机器或者一台虚拟机。在Node上面可以运行多个Pod，Pod是Kubernetes管理的最小单位，同时每个Pod可以包含多个容器。

通过下面的Kubernetes架构简图可以看到Master和Node之间的关系及底层etcd节点的关系。

从K8S架构来看，底层是以etcd为键值数据库，它是K8S的大脑，集群中所有的数据都存储在其中。上层是各系统组件，本身是一个分布式系统构件，各自通过代码实现了高可用，可以暂时不用考虑数据的备份。所有K8S数据都在etcd中，所以etcd是一个我们需要重点关注的备份点。

上图是K8S主要的工作负载(workloads），都是以Pod为基础进行封装与扩展的资源对象，比如：用于在每台主机上最多只部署一个副本的DaemonSet，可以多副本控制的ReplicaSet，及其上的可以用于控制滚动升降级的Deployment用于部署有状态应用的StatefulSet，用于完成一次性作业就退出的Job及基于其扩展的控制定时作业的CronJob，还有用于控制副本数量的ReplicationController；用于暴露内部服务，负责内部流量负载均衡的Service，用于水平和横向扩展Pod副本及CPU/Mem资源的控制器HPA/VPA，用于限制在同一时间自愿中断的复制应用程序中宕机的Pod的数量的PodDisruptionBudget(Pod中断预算）；用于控制有状态服务或提供数据挂卷服务的Volume，及基于Volume扩展的用于提供业务应用配置信息的ConfigMap，用于传递及保存密钥的Secret，用于提供持久卷申请的PVC，用于将Host或者Pod信息引用给容器的DownwardAPI，用于Host中本地临时目录做数据卷的HostPath/EmptyDir等等。这些workloads也就是一些提供给用户使用的资源类型或对像实体，它是业务（比如Tomcat服务）的承载体，用户通过kubectl或者client-go等RestfulAPI接口给Master中的APIServer下发部署命令。这些workloads通常以“.yaml”结尾的配置文件，主要包含副本的类型、副本个数、名称、端口、模版等信息。APIServer接受到请求以后，会分别进行以下操作：

◎权限验证（包括特殊控制），取出需要创建的资源，保存副本信息到etcd。

◎APIServer和ControllerManager，Scheduler以及kubelete之间通过List-Watch方式通信（事件发送与监听）。

◎ControllerManager通过etcd获取需要创建资源的副本数，交由Scheduler进行调度策略分析。

◎kubelet负责最终的Pod创建和容器加载。部署好容器（比如：Deployment，StatefulSet）以后，通过Service进行访问，通过cAdvisor监控资源使用情况。

◎最后以L4或L7负载均衡的方式暴露于集群外供用户访问。

所以，当业务以不同的workloads运行在K8S上时，这些业务的稳定性及数据安全性，