通常安装模式下(如使用kubeadm)的Kubernetes集群,主节点(Master)只有一个,而且集群数据存储服务etcd也只运行了一个实例。如果遇到极端情况(如整机故障、主硬盘损坏、数据误删除等)导致master节点无法访问,则整个集群都将无法访问或出现异常现象。所以master节点机器性能要求不一定很高,但是稳定性是越高越好。
为了有备无患,对主节点需要做好备份。
Kubernetes master节点控制组件的备份及恢复包括:容器镜像,etcd数据库,主节点证书、配置参数、插件等主要部分。
一、etcd数据库备份
一般来说,如果master节点需要备份恢复,除了误操作和删除,很可能就是整个机器已出现了故障,故而可能需要同时进行etcd数据的恢复。
在恢复时,在待恢复机器上的机器名称和ip地址需要与崩溃前的主节点配置完全一样,因为这个配置写在etcd数据存储当中的。
etcd数据库备份的具体操作方法参见:
二、主节点数据备份
除了etcd数据库,主节点数据备份还包括下面三个部分:
- /etc/kubernetes/目录下的所有文件(证书,manifest文件)
- 用户主目录下 .kube/config文件(kubectl连接认证)
- /var/lib/kubelet/目录下所有文件(plugins容器连接认证)
三、主节点组件恢复
主节点组件的恢复可按以下步骤进行:
- 按之前的安装脚本进行全新安装。
- kubeadm reset,iptables –X…
- 停止系统服务。
- systemctl stop kubelet.service
- 删除相关插件容器
- coredns, flannel, dashboard...
- 恢复etcd数据
- 将之前备份的三个目录依次还原。
- 重启系统服务。
- systemctl start kubelet.service。
- 稍等片刻,待所有组件启动成功后进行验证。
- kubectl cluster-info
对于小规模的开发、测试、数据处理等Kubernetes集群,可以使用备份机制来恢复。
当然,可恢复的前提是:必须有备份数据!!!
四、更多的参考
对于有一定规模的生产用集群,尤其是用于服务处理的集群,通过备份机制恢复将会影响业务的持续,应该做到主节点的双活、多活以及异地互备。不过,可用性要求越高,对硬件和运维人员都有更高的要求,费用也会大幅度上升,可用性的级别应该根据业务需求来进行选择,后面我们再继续探讨。