对于在生产环境使用的Kubernetes,我们可以利用kubeadm搭建高可用集群,一定程度实现容灾:
但是即便实现集群的高可用,我们依旧会需要备份还原功能,主要原因如下:
- 误删除:运维人员不小心删除了某个namespace,某个pv
- 服务器死机:因为物理原因服务器损坏,或者需要重装系统
- 集群迁移:需要将一个集群的数据迁移到另一个集群,用于测试或者其它目的
而对于Kubernetes的备份和还原,社区有一个16年创建的issue,从这个issue中我们可以看出Kubernetes官方并不打算提供Kubernetes备份还原方案以及工具,主要原因有两点:
- 官方认为Kubernetes只提供平台,管理和运行应用(类似于操作系统)。不负责应用层面的备份还原
- 基于Kubernetes集群的应用各不相同,无法(or 不太好)抽象统一备份方案
为了解决这个问题,社区中也有一些项目产生,例如:reshifter,kube-backup以及velero。
这其中最流行的备份还原工具是Velero,基于这个工具的研究可以参考这篇文章
虽然社区和Google上会有一些关于Kubernetes备份还原的工具和方案,但是都杂而不全,本文就针对Kubernetes备份还原这个专题进行一个全面而系统的方案介绍
备份什么?
对于Kubernetes搭建的集群,我们需要备份:
- 应用版本信息(Application Version)
- 应用对应的工作负载,例如:deploymenet,statefulset以及daemonset等等
- 应用需要使用的配置,例如:configmap,secret等等
- 应用状态信息(Application State)
- 应用可以分为有状态应用和无状态应用
- 有状态应用需要备份状态数据,例如:database
备份方案
针对上述备份数据,我们可以制定如下几种不同的备份还原方案(注意是逐项演进的)
etcd+应用状态
方案要点如下:
- 应用版本备份:Kubernetes集群的所有应用版本信息都存放于etcd中,我们可以直接备份etcd来达到备份版本的目的
- 应用状态备份:可以从应用层或者文件系统层备份应用状态,例如MariaDB采用
mysqldump
,MongoDB采用mongodump
等
备份流程大致如下:
-
step1:备份etcd
# backup kubernetes pki $ cp -r /etc/kubernetes/pki backup/ # backup kubeadm-config $ cp kubeadm-config.yaml backup/ # backup etcd snapshot $ cat <<EOF > etcd-backup-job.yaml apiVersion: batch/v1 kind: Job metadata: name: etcd-backup spec: template: spec: c