Kubernetes Master节点灾备恢复操作指南---升级版

本文档简述了Kubernetes主节点灾备恢复的相关步骤,供在发生k8s master崩溃时操作。

就算是在k8s里部署了etcd群集, 主节点控制组件的高可用节点,灾备恢复也是必须要实现的操作,才能形成完备的企业级服务方案。

K8s集群在master节点发生故障时,并不会影响已有的pod运行和服务开放,所以对服务是没有影响的。故而我们可以在发生故障之后,挑选合适的时间窗口进行维护和恢复,可以对外部客户造成最低的影响。

严格来讲,通过kubeadm安装的k8s主节点包括两大类的灾备恢复,etcd数据存储恢复和主节点控制组件恢复(包括但不限于kube-apiserver,kube-controller-manager,kube-scheduler,flannel,coreDns,dashboard)。

所以本文档也会相应的分成两个章节来进行描述。

之前的文档是全手工操作,而此次升级版,参考了国外比较正规的作法,形成了每天自动备份的机制。主要参考URL:

https://labs.consol.de/kubernetes/2018/05/25/kubeadm-backup.html

一,Etcd数据备份及恢复

etcd的数据默认会存放在我们的命令工作目录中,我们发现数据所在的目录,会被分为两个文件夹中:

  • snap: 存放快照数据,etcd防止WAL文件过多而设置的快照,存储etcd数据状态。
  • wal: 存放预写式日志,最大的作用是记录了整个数据变化的全部历程。在etcd中,所有数据的修改在提交前,都要先写入到WAL中。

A,单节点etcd数据备份

此方案备份etcd的数据时,为了部署方便和兼容,使用了k8s安装时本身的images作为运行容器(k8s.gcr.io/etcd-amd64:3.1.12)。使用以下yaml文件,运行在k8s的master上,即每天备份etcd的数据了。

etcd-backup.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: backup
  namespace: kube-system
spec:
  # activeDeadlineSeconds: 100
  schedule: "0 0 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            # Same image as in /etc/kubernetes/manifests/etcd.yaml
            image: k8s.gcr.io/etcd-amd64:3.1.12
            env:
            - name: ETCDCTL_API
              value: "3"
            command: ["/bin/sh"]
            args: ["-c", "etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.key snapshot save /backup/etcd-snapshot-$(date +%Y-%m-%d_%H:%M:%S_%Z).db"]
            volumeMounts:
            - mountPath: /etc/kubernetes/pki/etcd
              name: etcd-certs
              readOnly: true
            - mountPath: /backup
              name: backup
          restartPolicy: OnFailure
          nodeSelector:
            node-role.kubernetes.io/master: ""
          tolerations:
          - key: "node-role.kubernetes.io/master"
            effect: "NoSchedule"
          hostNetwork: true
          volumes:
          - name: etcd-certs
            hostPath:
              path: /etc/kubernetes/pki/etcd
              type: DirectoryOrCreate
          - name: backup
            hostPath:
              path: /tmp/etcd_backup/
              type: DirectoryOrCreate

从上面的yaml文件中,我们可以看到其实现思路:

1, 定义为CronJob,这个pod每天凌晨会自动运行(schedule: "0 0 * * *")。

2, 此pod是运行在master上的(nodeSelector + tolerations 实现)。

3, 挂载了master机器上的/tmp/etcd_backup/作为备份目录,这个目录生产环境最好挂载或及时cp到其它机器,防止机器本身的意外情况。

4, 传进的参数为ETCDCTL_API版本3的命令进行备份。

Args参数中的"etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.key snapshot save /backup/etcd-snapshot-$(date +%Y-%m-%d_%H:%M:%S_%Z).db"即为备份命令。它按照时间的格式命名etcd的备份数据。

B,单节点etcd数据恢复

如果已有备份数据,在只有etcd数据损坏的下,可根据以下步骤进行恢复。

1, 将/etc/kubernetes/manifests/ kube-apiserver.yaml文件里的镜像版本更改,停止kube-api server服务。

2, 将/etc/kubernetes/manifests/ etcd.yaml文件里的镜像版本更改,停止etcd server服务。

3, 运行如下命令,将损坏的数据文件移至其它地方。

      mv /var/lib/etcd/* /tmp/

4, 运行以下命令,以临时docker运行的方式,将数据从备份里恢复到/var/lib/etcd/。

    docker run --rm \

    -v ‘/tmp:/backup‘ \

    -v ‘/var/lib/etcd:/var/lib/etcd‘ \

    --env ETCDCTL_API=3 \

    ‘k8s.gcr.io/etcd-amd64:3.1.12‘ \

    /bin/sh -c "etcdctl snapshot restore ‘/backup/etcd-snapshot-xxx_UTC.db‘ ; mv /default.etcd/member/ /var/lib/etcd/"

[上面的命令中,假定我们已将待还原数据放置于/tmp/目录下]

5, 改回/etc/kubernetes/manifests/kube-apiserver.yaml文件里的镜像版本,恢复etcd server服务。

6, 改回/etc/kubernetes/manifests/etcd.yaml文件里的镜像版本,恢复kube-api server服务。

二,Master节点控制组件的备份及恢复

一般来说,如果master节点需要备份恢复,那除了误操作和删除,很可能就是整个机器已出现了故障,故而可能需要同时进行etcd数据的恢复。

而在恢复时,有个前提条件,就是在待恢复的机器上,机器名称和ip地址需要与崩溃前的主节点配置完成一样,因为这个配置是写进了etcd数据存储当中的。

A,主节点数据备份

主节点数据的备份包括三个部分:

1,/etc/kubernetes/目录下的所有文件(证书,manifest文件)

2,用户主目录下.kube/config文件(kubectl连接认证)

3,/var/lib/kubelet/目录下所有文件(plugins容器连接认证)

[最好这一步,也作成cronjob的yaml,每天自动运行]

k8s-master-backup.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: k8s-master-backup
  namespace: kube-system
spec:
  # activeDeadlineSeconds: 100
  schedule: "5 0 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: k8s-master-backup
            image: 3rd_part/alpine:alpine-3.8_glibc-2.28
            command: ["/bin/sh"]
            args: ["-c", "tar -zcvf /backup/k8s-master-$(ifconfig eth0 | grep ‘inet addr:‘ | awk ‘{print $2}‘ | cut -c 6-)-$(date +%Y-%m-%d_%H:%M:%S_%Z).tar.gz /kubernetes /kubelet"]
            volumeMounts:
            - mountPath: /backup
              name: backup
            - mountPath: /kubernetes
              name: kubernetes
            - mountPath: /kubelet
              name: kubelet
          restartPolicy: OnFailure
          nodeSelector:
            node-role.kubernetes.io/master: ""
          tolerations:
          - key: "node-role.kubernetes.io/master"
            effect: "NoSchedule"
          hostNetwork: true
          volumes:
          - name: backup
            hostPath:
              path: /tmp/k8s_master_backup/
              type: DirectoryOrCreate
          - name: kubernetes
            hostPath:
              path: /etc/kubernetes/
              type: DirectoryOrCreate
          - name: kubelet
            hostPath:
              path: /var/lib/kubelet/
              type: DirectoryOrCreate

代码解释:

1, 通过hostPath方式挂载了/etc/kubernetes目录

2, 以hostPath方式挂载了/var/lib/kubelet目录

3, 以hostNetwork: true方式运行,能读取主机IP地址。

4, 以nodeSelector方式,运行于k8s master节点。

5, Backup目录默认挂载于宿主机/tmp/k8s_master_backup/,也需要及时保持到其它机器。

B,主节点组件恢复

主节点组件的恢复可按以下步骤进行:

1,按之前的安装脚本进行全新安装(kubeadm reset,iptables –X…)

2,恢复etcd数据(参见第一章节操作)。

3,将之前备份的两个目录依次还原(.kube/config文件不用还原,根据第4步的提示,还需要先删除/etc/kubernetes/manifest/目录下的文件,及/var/lib/kubelet/pki/目录下的文件)。

4,运行如下命令,重新安装k8s master节点,并使用以前认证和数据。

    kubeadm init  \

    --pod-network-cidr=10.244.0.0/16 \

    --kubernetes-version=${K8S_VERSION} \

    --feature-gates=CoreDNS=true \

    --ignore-preflight-errors=DirAvailable--var-lib-etcd

5,一杯咖啡,稍等片刻,待所有组件启动成功后,根据输出提示,运行如下两条命令,将新的config文件cp到指定位置,进行验证。

mkdir -p $HOME/.kube

             cp -f /etc/kubernetes/admin.conf $HOME/.kube/config

原文地址:https://www.cnblogs.com/aguncn/p/9983603.html

时间: 2024-11-06 03:43:57

Kubernetes Master节点灾备恢复操作指南---升级版的相关文章

Kubernetes master节点的高可用配置

了解Kubernetes架构都知道Master节点在整个集群中的位置,为了保证整个架构的高可用,Kubernetes提供了HA的架构,处于兴趣和对架构的进一步了解,我在自己的电脑实践以下. 环境: CentOS 7.3,Kubernetes版本 Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1", GitCommit:"82450d03cb057b

使用confd与nginx 实现kubernetes master节点高可用

下载confd 二进制文件 # 创建目录方便存放文件 mkdir confd # 进入新创建的目录 cd confd # 下载 confd wget https://github.com/kelseyhightower/confd/releases/download/v0.16.0/confd-0.16.0-linux-amd64 # 重命名 mv confd-0.16.0-linux-amd64 confd # 给confd 可执行权限 chmod +x confd 生成confd 配置 #

kubernetes高可用设计-master节点和kubectl

部署master 节点 上一遍是CA证书和etcd的部署,这一篇继续搭建k8s,废话不多说.开始部署. kubernetes master 节点包含的组件有: kube-apiserver kube-scheduler kube-controller-manager 目前这3个组件需要部署到同一台机器上:(后面再部署高可用的master) kube-scheduler.kube-controller-manager 和 kube-apiserver 三者的功能紧密相关: 同时只能有一个 kube

kubeadm部署kubernetes v1.17.4 单master节点

环境说明: #操作系统:centos7 #docker版本:19.03.8#kubernetes版本:v1.17.4#K8S master 节点IP:192.168.3.62#K8S worker节点IP:192.168.2.186#网络插件:flannel#kube-proxy网络转发: ipvs#kubernetes源:使用阿里云源#service-cidr:10.96.0.0/16 #pod-network-cidr:10.244.0.0/16 部署准备: 操作在所有节点进行 修改内核参数

kubeadm部署kubernetes v1.17.4 高可用master节点

环境说明: #操作系统:centos7 #docker版本:19.03.8 #kubernetes版本:v1.17.4 #K8S master 节点IP:192.168.2.175,192.168.2.176,192.168.2.177 #K8S worker节点IP:192.168.2.185,192.168.2.185 #网络插件:flannel #kube-proxy网络转发: ipvs #kubernetes源:使用阿里云源 #service-cidr:10.96.0.0/16 #pod

数据库备份/恢复-企业级云灾备

使用UCACHE灾备云进行Oracle实时复制数据.搬迁数据功能来设计Oracle数据库备份/恢复解决方案,支持定时备份.实时备份,增量备份,同时可开展异地灾备,是Oracle数据库灾备/恢复的完美解决方案. Oracle数据库系统是美国 Oracle 公司(甲骨文)提供的以分布式数据库为核心的一组软件产品,目前最流行的客户 服务器 (CLIENT/ 或 B/S 体系结构的数据库之一 ,Oracle 数据库本身提供了对数据库物理文件进行冷备份和在线备份两种方式.在线备份类型包括:完全备份.差异

UCACHE企业级灾备云VMware虚拟化灾难备份与/恢复

现在很多局域网内都是通过vmware虚拟化计算.存储和网络,然后通过创建虚拟主机来划分资源,达到资源最大化的利用,这些虚拟主机内一般都存储有重要文件,那么如何保证这些文件的安全就变的十分重要.逻辑错误数据丢失和故障能否得到有效的保护?出现故障时,能否在分钟级别内恢复业务的正常运行?能否低成本.快速.有效的进行灾难恢复演练? UCACHE企业级灾备云服务是面向企业和组织机构团体的,利用云的特性来解决信息化异地备份/恢复.灾备.灾难恢复的云端服务,可提供面向云端.虚拟和物理环境下的数据.平台.应用备

kubeadm部署k8s1.9高可用集群--4部署master节点

部署master节点 kubernetes master 节点包含的组件: kube-apiserver kube-scheduler kube-controller-manager 本文档介绍部署一个三节点高可用 master 集群的步骤,分别命名为k8s-host1.k8s-host2.k8s-host3: k8s-host1:172.16.120.154 k8s-host2:172.16.120.155 k8s-host3:172.16.120.156 安装docker 在每台主机安装do

混合云存储跨云灾备方案之跨云复制

摘要: 混合云容灾实现了跨云/多云场景中的应用和整机的灾备和恢复.支持整机和主流的企业应用,如各版本的Oracle(Oracle RAC近期即将支持)和SQL Server等.先进的压缩重删服务节约了备份时的网络带宽和空间占用,云灾备库的按需分配和弹性无限扩展,灾备ECS可关机不付费等多个特性,从多个维度将用户成本降到最低. 前面两篇文章介绍了基于阿里云备份的跨云备份和云存储网关的跨云复制,两者主要是解决文件粒度的备份与恢复问题.如果用户需要保护一个云上的数据库应用,而不仅仅是数据库的数据文件: