22-kubernetes集群中进行etcd数据快照的备份恢复

[TOC]

0x00 前言简述

描述:在 Kubernetes 集群中所有操作的资源数据都是存储在 etcd 数据库上, 所以防止集群节点瘫痪未正常工作或在集群迁移时,以及在出现异常的情况下能尽快的恢复集群数据,则我们需要定期针对etcd集群数据进行相应的容灾操作。

在K8S集群中或者Docker环境中,我们可以非常方便的针对 etcd 数据进行备份,通我们常在一个节点上对 etcd 做快照就能够实现etcd数据的备份,其快照文件包含所有 Kubernetes 状态和关键信息, 有了etcd集群数据备份后,例如在灾难场景(例如丢失所有控制平面节点)下也能快速恢复 Kubernetes 集群,Boss再也不同担心系统起不来呢。

0x01 环境准备

1.安装的二进制 etcdctl

描述: etcdctl 二进制文件可以在 github.com/coreos/etcd/releases 选择对应的版本下载,例如可以执行以下 install_etcdctl.sh 的脚本,修改其中的版本信息。

install_etcdctl.sh

#!/bin/bash
# Author: WeiyiGeek
# Description: etcd 与 etcdctl 下载安装
ETCD_VER=v3.5.5
ETCD_DIR=etcd-download
DOWNLOAD_URL=https://github.com/coreos/etcd/releases/download

# Download
mkdir ${ETCD_DIR}
cd ${ETCD_DIR}
wget ${DOWNLOAD_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz 
tar -xzvf etcd-${ETCD_VER}-linux-amd64.tar.gz

# Install
cd etcd-${ETCD_VER}-linux-amd64
cp etcdctl /usr/local/bin/

验证安装:

$ etcdctl version
etcdctl version: 3.5.5
API version: 3.5

2.拉取带有 etcdctl 的 Docker 镜像

操作流程:

# 镜像拉取与容器创建。
docker run --rm \
-v /data/backup:/backup      \
-v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
--env ETCDCTL_API=3          \
registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.5.1-0 \
/bin/sh -c "etcdctl version"

安装验证:

3.5.1-0: Pulling from google_containers/etcd
e8614d09b7be: Pull complete
45b6afb4a92f: Pull complete
.......
Digest: sha256:64b9ea357325d5db9f8a723dcf503b5a449177b17ac87d69481e126bb724c263
Status: Downloaded newer image for registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.5.1-0
etcdctl version: 3.5.1
API version: 3.5

3.Kubernetes 使用 etcdctl 镜像创建Pod

# 镜像拉取
crictl pull registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.5.5-0

# Pod 创建以及安装验证
$ kubectl run etcdctl --image=registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.5.5-0 --command -- /usr/local/bin/etcdctl version
$ kubectl logs -f etcdctl
etcdctl version: 3.5.5
API version: 3.5
$ kubectl delete pod etcdctl

0x02 备份实践

1.使用二进制安装 etcdctl 客户端工具

温馨提示: 如果是单节点 Kubernetes 我们只需要对其的 etcd 数据库进行快照备份, 如果是多主多从的集群,我们则需依次备份多个 master 节点中 etcd,防止在备份时etc数据被更改!

此处实践环境为多master高可用集群节点, 即三主节点、四从工作节点,若你对K8s集群不了解或者项搭建高可用集群的朋友,关注 WeiyiGeek 公众号回复【Kubernetes学习之路汇总】即可获得学习资料: https://www.weiyigeek.top/wechat.html?key=Kubernetes学习之路汇总

$ kubectl get node
NAME       STATUS   ROLES                  AGE    VERSION
cqzk-107   Ready    control-plane,master   279d   v1.23.1
cqzk-108   Ready    control-plane,master   278d   v1.23.1
cqzk-109   Ready    control-plane,master   278d   v1.23.1
cqzk-223   Ready    work                   278d   v1.23.1
cqzk-224   Ready    work                   278d   v1.23.1
cqzk-225   Ready    work                   279d   v1.23.1
cqzk-226   Ready    work                   118d   v1.23.1

操作流程:

# 1.创建etcd快照备份目录
$ mkdir -pv /backup

# 2.查看etcd证书
$ ls /etc/kubernetes/pki/etcd/
ca.crt  ca.key  healthcheck-client.crt  healthcheck-client.key  peer.crt  peer.key  server.crt  server.key

# 3.查看 etcd 地址以及服务
$ kubectl get pod -n kube-system  -o wide | grep "etcd"
etcd-cqzk-107     1/1     Running   1   279d   192.168.12.107   cqzk-107   <none><none>
etcd-cqzk-108     1/1     Running   0   278d   192.168.12.108   cqzk-108   <none><none>
etcd-cqzk-109     1/1     Running   0   278d   192.168.12.109   cqzk-109   <none><none>

# 4.此时在 107、 108 、109 主节点上查看你监听情况
$ netstat -ano | grep "107:2379"
tcp        0      0 192.168.12.107:2379     0.0.0.0:*               LISTEN      off (0.00/0/0)
$ netstat -ano | grep "108:2379"
tcp        0      0 192.168.12.108:2379     0.0.0.0:*               LISTEN      off (0.00/0/0)
$ netstat -ano | grep "109:2379"
tcp        0      0 192.168.12.109:2379     0.0.0.0:*               LISTEN      off (0.00/0/0)

# 5. 使用etcdctl客户端工具依次备份节点中的数据
$ etcdctl --endpoints=https://10.20.176.212: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.db
{"level":"info","ts":"2022-10-23T16:32:26.020+0800","caller":"snapshot/v3_snapshot.go:65","msg":"created temporary db file","path":"/backup/etcd-snapshot.db.part"}
{"level":"info","ts":"2022-10-23T16:32:26.034+0800","logger":"client","caller":"v3/maintenance.go:211","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":"2022-10-23T16:32:26.034+0800","caller":"snapshot/v3_snapshot.go:73","msg":"fetching snapshot","endpoint":"https://10.20.176.212:2379"}
{"level":"info","ts":"2022-10-23T16:32:26.871+0800","logger":"client","caller":"v3/maintenance.go:219","msg":"completed snapshot read; closing"}
{"level":"info","ts":"2022-10-23T16:32:26.946+0800","caller":"snapshot/v3_snapshot.go:88","msg":"fetched snapshot","endpoint":"https://10.20.176.212:2379","size":"112 MB","took":"now"}
{"level":"info","ts":"2022-10-23T16:32:26.946+0800","caller":"snapshot/v3_snapshot.go:97","msg":"saved","path":"/backup/etcd-snapshot.db"}
Snapshot saved at /backup/etcd-snapshot.db

通过etcdctl查询Kubernetes中etcd数据,由于Kubernetes使用etcd v3版本的API,而且etcd 集群中默认使用tls认证,所以先配置几个环境变量。

# 1.环境变量
export ETCDCTL_API=3
export ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crt
export ETCDCTL_CERT=/etc/kubernetes/pki/etcd/peer.crt
export ETCDCTL_KEY=/etc/kubernetes/pki/etcd/peer.key

# 2.查询集群中所有的key列表
# –-prefix:表示查找所有以/registry为前缀的key
# --keys-only=true:表示只给出key不给出value
etcdctl --endpoints=https://10.20.176.212:2379 get /registry --prefix --keys-only=true | head -n 1
/registry/apiextensions.k8s.io/customresourcedefinitions/bgpconfigurations.crd.projectcalico.org

# 3.查询某个key的值
# -–keys-only=false : 表示要给出value,该参数默认值即为false,
# -w=json :表示输出json格式
etcdctl --endpoints=https://10.20.176.212:2379 get /registry/namespaces/default --prefix --keys-only=false -w=json | python3 -m json.tool

etcdctl --endpoints=https://10.20.176.212:2379 get /registry/namespaces/default --prefix --keys-only=false -w=json | python3 -m json.tool
{
  "header": {
      "cluster_id": 11404821125176160774,
      "member_id": 7099450421952911102,
      "revision": 30240109,
      "raft_term": 3
  },
  "kvs": [
    {
        "key": "L3JlZ2lzdHJ5L25hbWVzcGFjZXMvZGVmYXVsdA==",
        "create_revision": 192,
        "mod_revision": 192,
        "version": 1,
        "value": "azhzAAoPCg.......XNwYWNlEGgAiAA=="
    }
  ],
  "count": 1
}

# 4.其 Key / Value 都是采用 base64 编码
echo -e "L3JlZ2lzdHJ5L25hbWVzcGFjZXMvZGVmYXVsdA==" | base64 -d
echo -e "azhzAAoPCgJ2MRIJTmFtZXNwYWNlEogCCu0BCgdkZWZhdWx0EgAaACIAKiQ5ZDQyYmYxMy03OGM0LTQ4NzQtOThiYy05NjNlMDg1MDYyZjYyADgAQggIo8yllQYQAFomChtrdWJlcm5ldGVzLmlvL21ldGFkYXRhLm5hbWUSB2RlZmF1bHR6AIoBfQoOa3ViZS1hcGlzZXJ2ZXISBlVwZGF0ZRoCdjEiCAijzKWVBhAAMghGaWVsZHNWMTpJCkd7ImY6bWV0YWRhdGEiOnsiZjpsYWJlbHMiOnsiLiI6e30sImY6a3ViZXJuZXRlcy5pby9tZXRhZGF0YS5uYW1lIjp7fX19fUIAEgwKCmt1YmVybmV0ZXMaCAoGQWN0aXZlGgAiAA==" | base64 -d

# 5.实际上述value编码解码后的的内容如下:
$ kubectl get ns default -o yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2022-06-15T04:54:59Z"
  labels:
    kubernetes.io/metadata.name: default
  name: default
  resourceVersion: "192"
  uid: 9d42bf13-78c4-4874-98bc-963e085062f6
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

# 5.Pod 资源信息查看 
etcdctl --endpoints=https://10.20.176.212:2379 get /registry/pods/default --prefix --keys-only=true
# /registry/pods/default/nfs-dev-nfs-subdir-external-provisioner-cf7684f8b-fzl9h
# /registry/pods/default/nfs-local-nfs-subdir-external-provisioner-6f97d44bb8-424tk

etcdctl --endpoints=https://10.20.176.212:2379 get /registry/pods/default --prefix --keys-only=true -w=json | python3 -m json.tool
{
  "header": {
      "cluster_id": 11404821125176160774,
      "member_id": 7099450421952911102,
      "revision": 30442415,
      "raft_term": 3
  },
  "kvs": [
      {   # 实际上该编码是 /registry/pods/default/nfs-dev-nfs-subdir-external-provisioner-cf7684f8b-fzl9h
          "key": "L3JlZ2lzdHJ5L3BvZHMvZGVmYXVsdC9uZnMtZGV2LW5mcy1zdWJkaXItZXh0ZXJuYWwtcHJvdmlzaW9uZXItY2Y3Njg0ZjhiLWZ6bDlo",  
          "create_revision": 5510865,
          "mod_revision": 5510883,
          "version": 5
      },
      {
          "key": "L3JlZ2lzdHJ5L3BvZHMvZGVmYXVsdC9uZnMtbG9jYWwtbmZzLXN1YmRpci1leHRlcm5hbC1wcm92aXNpb25lci02Zjk3ZDQ0YmI4LTQyNHRr",
          "create_revision": 5510967,
          "mod_revision": 5510987,
          "version": 5
      }
  ],
  "count": 2
}

2.使用Docker镜像安装 etcdctl 客户端工具

描述: 在装有Docker环境的机器,我们可以非常方便的备份K8s集群中的etcd数据库,此处我已经安装好了Docker,若有不了解Docker或者需要搭建Docker环境中童鞋。

# 1.Docker 实践环境
$ docker version
Client: Docker Engine - Community
 Version           20.10.3
.......
Server: Docker Engine - Community
 Engine:
  Version:          20.10.3

# 2.etcd 备份文件存储的目录
$ mkdir -vp /backup

# 3.执行docker创建容器,在备份数据库后便删除该容器。
$ docker run --rm \
-v /backup:/backup  \
-v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
--env ETCDCTL_API=3   \
registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.5.1-0 \
/bin/sh -c "etcdctl --endpoints=https://192.168.12.107:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt  \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
snapshot save /backup/etcd-snapshot.db"
# {"level":"info","ts":1666515535.63076,"caller":"snapshot/v3_snapshot.go:68","msg":"created temporary db file","path":"/backup/etcd-snapshot.db.part"}
# {"level":"info","ts":1666515535.6411893,"logger":"client","caller":"v3/maintenance.go:211","msg":"opened snapshot stream; downloading"}
# {"level":"info","ts":1666515535.6419039,"caller":"snapshot/v3_snapshot.go:76","msg":"fetching snapshot","endpoint":"https://192.168.12.107:2379"}
# {"level":"info","ts":1666515535.9170482,"logger":"client","caller":"v3/maintenance.go:219","msg":"completed snapshot read; closing"}
# {"level":"info","ts":1666515535.931862,"caller":"snapshot/v3_snapshot.go:91","msg":"fetched snapshot","endpoint":"https://192.168.12.107:2379","size":"9.0 MB","took":"now"}
# {"level":"info","ts":1666515535.9322069,"caller":"snapshot/v3_snapshot.go:100","msg":"saved","path":"/backup/etcd-snapshot.db"}
Snapshot saved at /backup/etcd-snapshot.db

# 4.查看备份的etcd快照文件
ls -alh /backup/etcd-snapshot.db
-rw------- 1 root root 8.6M Oct 23 16:58 /backup/etcd-snapshot.db

使用 Docker 容器查看 k8s 集群中的etcd数据库中的数据。

$ docker run --rm \
-v /backup:/backup  \
-v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
--env ETCDCTL_API=3   \
--env ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crt \
--env ETCDCTL_CERT=/etc/kubernetes/pki/etcd/peer.crt \
--env ETCDCTL_KEY=/etc/kubernetes/pki/etcd/peer.key \
registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.5.1-0 \
/bin/sh -c "etcdctl --endpoints=https://192.168.12.107:2379 get /registry/namespaces/default -w=json"

执行结果:

3.在kubernetes集群中快速创建pod进行手动备份

准备一个Pod资源清单并部署

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: etcd-backup
  labels:
    tool: backup
spec:
  containers:
  - name: redis
    image: registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.5.5-0
    imagePullPolicy: IfNotPresent
    command:
    - sh
    - -c
    - "etcd"
    env:
    - name: ETCDCTL_API
      value: "3"
    - name: ETCDCTL_CACERT
      value: "/etc/kubernetes/pki/etcd/ca.crt"
    - name: ETCDCTL_CERT
      value: "/etc/kubernetes/pki/etcd/healthcheck-client.crt"
    - name: ETCDCTL_KEY
      value: "/etc/kubernetes/pki/etcd/healthcheck-client.key"
    volumeMounts: 
    - name: "pki"
      mountPath: "/etc/kubernetes"
    - name: "backup"
      mountPath: "/backup"
  volumes:
  - name: pki
    hostPath: 
      path: "/etc/kubernetes"          # 证书目录
      type: "DirectoryOrCreate"
  - name: "backup"
    hostPath:     
      path: "/storage/dev/backup"      # 数据备份目录
      type: "DirectoryOrCreate"
  restartPolicy: Never
  nodeSelector: 
    node-role.kubernetes.io/master: "" # 绑定在主节点中
EOF
pod/etcd-backup created

进入到该Pod终端之中执行相应的备份命令

~$ kubectl exec -it etcd-backup sh
# 快照备份
sh-5.1# export RAND=$RANDOM
sh-5.1# etcdctl --endpoints=https://192.168.12.107:2379 snapshot save /backup/etcd-107-${RAND}-snapshot.db
sh-5.1# etcdctl --endpoints=https://192.168.12.108:2379 snapshot save /backup/etcd-108-${RAND}-snapshot.db
Snapshot saved at /backup/etcd-108-32616-snapshot.db
sh-5.1# etcdctl --endpoints=https://192.168.12.109:2379 snapshot save /backup/etcd-109-${RAND}-snapshot.db

# etcd 节点成员
sh-5.1# etcdctl member list --endpoints=https://192.168.12.107:2379 --endpoints=https://192.168.12.108:2379 --endpoints=https://192.168.12.109:2379

2db31a5d67ec1034, started, cqzk-108, https://192.168.12.108:2380, https://192.168.12.108:2379, false
42efe7cca897d765, started, cqzk-109, https://192.168.12.109:2380, https://192.168.12.109:2379, false
471323846709334f, started, cqzk-107, https://192.168.12.107:2380, https://192.168.12.107:2379, false


# etcd 节点健康信息
sh-5.1# etcdctl endpoint health --endpoints=https://192.168.12.107:2379 --endpoints=https://192.168.12.108:2379 --endpoints=https://192.168.12.109:2379

https://192.168.12.107:2379 is healthy: successfully committed proposal: took = 11.930331ms
https://192.168.12.109:2379 is healthy: successfully committed proposal: took = 11.930993ms
https://192.168.12.108:2379 is healthy: successfully committed proposal: took = 109.515933ms


# etcd 节点状态及空间占用信息
sh-5.1# etcdctl endpoint status --endpoints=https://192.168.12.107:2379  --endpoints=https://192.168.12.108:2379  --endpoints=https://192.168.12.109:2379

https://192.168.12.107:2379, 471323846709334f, 3.5.1, 9.2 MB, false, false, 4, 71464830, 71464830,
https://192.168.12.108:2379, 2db31a5d67ec1034, 3.5.1, 9.2 MB, false, false, 4, 71464830, 71464830,
https://192.168.12.109:2379, 42efe7cca897d765, 3.5.1, 9.2 MB, true, false, 4, 71464830, 71464830, # 此处为主

至此,手动备份etcd集群数据快照完毕!

4.在kubernetes集群中使用CronJob资源控制器进行定时备份

首先准备一个cronJob资源清单:

cat > etcd-database-backup.yaml <<'EOF'
apiVersion: batch/v1
kind: CronJob 
metadata:
  name: etcd-database-backup
  annotations:
    descript: "etcd数据库定时备份"
spec:
  schedule: "*/5 * * * *"   # 表示每5分钟运行一次
  jobTemplate:
    spec:
      template:
        spec:           
          containers:    
          - name: etcdctl
            image: registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.5.5-0
            env:
            - name: ETCDCTL_API
              value: "3"
            - name: ETCDCTL_CACERT
              value: "/etc/kubernetes/pki/etcd/ca.crt"
            - name: ETCDCTL_CERT
              value: "/etc/kubernetes/pki/etcd/healthcheck-client.crt"
            - name: ETCDCTL_KEY
              value: "/etc/kubernetes/pki/etcd/healthcheck-client.key"
            command:
            - /bin/sh 
            - -c
            - |
              export RAND=$RANDOM
              etcdctl --endpoints=https://192.168.12.107:2379 snapshot save /backup/etcd-107-${RAND}-snapshot.db
              etcdctl --endpoints=https://192.168.12.108:2379 snapshot save /backup/etcd-108-${RAND}-snapshot.db
              etcdctl --endpoints=https://192.168.12.109:2379 snapshot save /backup/etcd-109-${RAND}-snapshot.db
            volumeMounts: 
            - name: "pki"
              mountPath: "/etc/kubernetes"
            - name: "backup"
              mountPath: "/backup"
            imagePullPolicy: IfNotPresent
          volumes:
          - name: "pki"
            hostPath: 
              path: "/etc/kubernetes"
              type: "DirectoryOrCreate"
          - name: "backup"
            hostPath: 
              path: "/storage/dev/backup"  # 数据备份目录
              type: "DirectoryOrCreate"
          nodeSelector:  # 将Pod绑定在主节点之中,否则只能将相关证书放在各个节点能访问的nfs共享存储中
            node-role.kubernetes.io/master: ""
          restartPolicy: Never
EOF

创建cronjob资源清单:

kubectl apply -f etcd-database-backup.yaml
# cronjob.batch/etcd-database-backup created

查看创建的cronjob资源及其集群etcd备份:

NAME                                 SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob.batch/etcd-database-backup   */5 * * * *   False     0        21s             14m

NAME                                      READY   STATUS      RESTARTS   AGE
pod/etcd-database-backup-27776740-rhzkk   0/1     Completed   0          21s

查看定时Pod日志以及备份文件:

kubectl logs -f pod/etcd-database-backup-27776740-rhzkk
Snapshot saved at /backup/etcd-107-25615-snapshot.db
Snapshot saved at /backup/etcd-108-25615-snapshot.db
Snapshot saved at /backup/etcd-109-25615-snapshot.db


$ ls -lt # 显示最新备份的文件按照时间排序
total 25M
-rw------- 1 root root 8.6M Oct 24 21:12 etcd-107-25615-snapshot.db
-rw------- 1 root root 7.1M Oct 24 21:12 etcd-108-25615-snapshot.db
-rw------- 1 root root 8.8M Oct 24 21:12 etcd-109-25615-snapshot.db

至此集群中的etcd快照数据备份完毕!

0x02 恢复实践

1.单master节点恢复

描述: 当单master集群节点资源清单数据丢失时,我们可采用如下方式进行快速恢复数据。

操作流程:

温馨提示: 如果是单节点的k8S集群则使用如下命令恢复

 mv /etc/kubernetes/manifests/ /etc/kubernetes/manifests-backup/
 mv /var/lib/etcd /var/lib/etcd.bak

ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-212-32616-snapshot.db  --data-dir=/var/lib/etcd/ --endpoints=https://10.20.176.212:2379  --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key

2.多master节点恢复

1.温馨提示,此处的集群etcd数据库是安装在Kubernetes集群之中的,并非外部独立安装部署的。

$ kubectl get pod -n kube-system  etcd-devtest-master-212 etcd-devtest-master-213 etcd-devtest-master-214
NAME                      READY   STATUS    RESTARTS   AGE
etcd-devtest-master-212   1/1     Running   3          134d
etcd-devtest-master-213   1/1     Running   0          134d
etcd-devtest-master-214   1/1     Running   0          134d

2.前面我们提到过,在进行恢复前需要查看 etcd 集群当前成员以及监控状态。

# etcd 集群成员列表
ETCDCTL_API=3 etcdctl member list --endpoints=https://10.20.176.212:2379  --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key
6286508b550016fe, started, devtest-master-212, https://10.20.176.212:2380, https://10.20.176.212:2379, false
9dd15f852caf8e05, started, devtest-master-214, https://10.20.176.214:2380, https://10.20.176.214:2379, false
e0f23bd90b7c7c0d, started, devtest-master-213, https://10.20.176.213:2380, https://10.20.176.213:2379, false

# etcd 集群节点状态查看主从节点
ETCDCTL_API=3 etcdctl endpoint status --endpoints=https://10.20.176.212:2379 --endpoints=https://10.20.176.213:2379 --endpoints=https://10.20.176.214:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key   --write-out table

# etcd 集群节点健康信息筛选出不健康的节点
ETCDCTL_API=3 etcdctl endpoint health --endpoints=https://10.20.176.212:2379   --endpoints=https://10.20.176.213:2379  --endpoints=https://10.20.176.214:2379  --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key
https://10.20.176.212:2379 is healthy: successfully committed proposal: took = 14.686875ms
https://10.20.176.214:2379 is healthy: successfully committed proposal: took = 16.201187ms
https://10.20.176.213:2379 is healthy: successfully committed proposal: took = 18.962462ms

3.停掉所有Master机器的kube-apiserver和etcd ,然后在利用备份进行恢复该节点的etcd数据。


mv /etc/kubernetes/manifests/ /etc/kubernetes/manifests-backup/

# 在该节点上删除 /var/lib/etcd
mv /var/lib/etcd /var/lib/etcd.bak

# 利用快照进行恢复,注意etcd集群中可以用同一份snapshot恢复。
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-212-32616-snapshot.db --data-dir=/var/lib/etcd --name=devtest-master-212 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key  --initial-cluster-token=etcd-cluster-0 --initial-cluster=devtest-master-212=https://10.20.176.212:2380,devtest-master-213=https://10.20.176.213:2380,devtest-master-214=https://10.20.176.214:2380  --initial-advertise-peer-urls=https://10.20.176.212:2380

温馨提示: 当节点加入控制平面 control-plane 后为 API Server、Controller Manager 和 Scheduler 生成静态Pod配置清单,主机上的kubelet服务会监视 /etc/kubernetes/manifests目录中的配置清单的创建、变动和删除等状态变动,并根据变动完成Pod创建、更新或删除操作。因此,这两个阶段创建生成的各配置清单将会启动Master组件的相关Pod

4.然后启动 etcd 和 apiserver 并查看 pods是否恢复正常。

# 查看 etcd pod
$ kubectl get pod -n kube-system -l component=etcd

# 查看组件健康状态
$ kubectl get componentstatuses
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME                 STATUS    MESSAGE                         ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health":"true","reason":""}

3.K8S集群中etcd数据库节点数据不一致问题解决实践

发现etcd数据不一致,执行kubectl get pod -n xxx获取的信息资源不一样, etcdctl 直接查询了 etcd 集群状态和集群数据,返回结果显示 3 个节点状态都正常,且 RaftIndex 一致,观察 etcd 的日志也并未发现报错信息,唯一可疑的地方是 3 个节点的 dbsize 差别较大

etcd 数据不一致 ?

由于从 kube-apiserver 的日志中同样无法提取出能够帮助解决问题的有用信息,起初我们只能猜测可能是 kube-apiserver 的缓存更新异常导致的。正当我们要从这个切入点去解决问题时,该同事反馈了一个更诡异的问题——自己新创建的 Pod,通过 kubectl查询 Pod 列表,突然消失了!纳尼?这是什么骚操作?经过我们多次测试查询发现,通过 kubectl 来 list pod 列表,该 pod 有时候能查到,有时候查不到。那么问题来了,K8s api 的 list 操作是没有缓存的,数据是 kube-apiserver 直接从 etcd 拉取返回给客户端的,难道是 etcd 本身出了问题?

众所周知,etcd 本身是一个强一致性的 KV 存储,在写操作成功的情况下,两次读请求不应该读取到不一样的数据。怀着不信邪的态度,我们通过 etcdctl 直接查询了 etcd 集群状态和集群数据,返回结果显示 3 个节点状态都正常,且 RaftIndex 一致,观察 etcd 的日志也并未发现报错信息,唯一可疑的地方是 3 个节点的 dbsize 差别较大。接着,我们又将 client 访问的 endpoint 指定为不同节点地址来查询每个节点的 key 的数量,结果发现 3 个节点返回的 key 的数量不一致,甚至两个不同节点上 Key 的数量差最大可达到几千!而直接通过 etcdctl 查询刚才创建的 Pod,发现访问某些 endpoint 能够查询到该 pod,而访问其他 endpoint 则查不到。至此,基本可以确定 etcd 集群的节点之间确实存在数据不一致现象。

ETCDCTL_API=3 etcdctl endpoint status –endpoints=https://192.168.12.108:2379 –endpoints=https://192.168.12.107:2379 –endpoints=https://192.168.12.109:2379 –cacert=/etc/kubernetes/pki/etcd/ca.crt –cert=/etc/kubernetes/pki/etcd/peer.crt –key=/etc/kubernetes/pki/etcd/peer.key

https://192.168.12.108:2379, 2db31a5d67ec1034, 3.5.1, 7.4 MB, false, false, 4, 72288139, 72288139,
https://192.168.12.107:2379, 471323846709334f, 3.5.1, 9.0 MB, false, false, 4, 72288139, 72288139,
https://192.168.12.109:2379, 42efe7cca897d765, 3.5.1, 9.2 MB, true, false, 4, 72288139, 72288139,

root@cqzk-107:~# ETCDCTL_API=3 etcdctl get / –prefix –keys-only –endpoints=https://192.168.12.107:2379 –cacert=/etc/kubernetes/pki/etcd/ca.crt –cert=/etc/kubernetes/pki/etcd/peer.crt –key=/etc/kubernetes/pki/etcd/peer.key | wc -l 1620

root@cqzk-107:~# ETCDCTL_API=3 etcdctl get / –prefix –keys-only –endpoints=https://192.168.12.108:2379 –cacert=/etc/kubernetes/pki/etcd/ca.crt –cert=/etc/kubernetes/pki/etcd/peer.crt –key=/etc/kubernetes/pki/etcd/peer.key | wc -l 1620

root@cqzk-107:~# ETCDCTL_API=3 etcdctl get / –prefix –keys-only –endpoints=https://192.168.12.109:2379 –cacert=/etc/kubernetes/pki/etcd/ca.crt –cert=/etc/kubernetes/pki/etcd/peer.crt –key=/etc/kubernetes/pki/etcd/peer.key | wc -l 1620

l +—————————–+——————+———+———+———–+———–+————+ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX | +—————————–+——————+———+———+———–+———–+————+ | https://192.168.12.108:2379 | 2db31a5d67ec1034 | 3.5.1 | 7.4 MB | false | 4 | 72291872 | | https://192.168.12.107:2379 | 471323846709334f | 3.5.1 | 9.0 MB | false | 4 | 72291872 | | https://192.168.12.109:2379 | 42efe7cca897d765 | 3.5.1 | 9.2 MB | true | 4 | 72291872 | +—————————–+——————+———+———+———–+———–+————+

ETCDCTL_API=3 etcdctl endpoint status –endpoints=https://192.168.12.107:2379 –endpoints=https://192.168.12.108:2379 –endpoints=https://192.168.12.109:2379 –write-out table +—————————–+——————+———+———+———–+————+———–+————+——————–+——–+ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS | +—————————–+——————+———+———+———–+————+———–+————+——————–+——–+ | https://192.168.12.107:2379 | 471323846709334f | 3.5.1 | 9.0 MB | false | false | 4 | 72292452 | 72292452 | | | https://192.168.12.108:2379 | 2db31a5d67ec1034 | 3.5.1 | 7.4 MB | false | false | 4 | 72292452 | 72292452 | | | https://192.168.12.109:2379 | 42efe7cca897d765 | 3.5.1 | 9.2 MB | true | false | 4 | 72292452 | 72292452 | | +—————————–+——————+———+———+———–+————+———–+————+——————–+——–+

原文地址:https://cloud.tencent.com/developer/article/2168334

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


文章浏览阅读942次。kube-controller-manager 和 kubelet 是异步工作的,这意味着延迟可能包括任何的网络延迟、apiserver 的延迟、etcd 延迟,一个节点上的负载引起的延迟等等。当 Kubernetes 中 Node 节点出现状态异常的情况下,节点上的 Pod 会被重新调度到其他节点上去,但是有的时候我们会发现节点 Down 掉以后,Pod 并不会立即触发重新调度,这实际上就是和 Kubelet 的状态更新机制密切相关的,Kubernetes 提供了一些参数配置来触发重新调度的时间。_node-monitor-period
文章浏览阅读3.8k次。上篇文章详细介绍了弹性云混部的落地历程,弹性云是滴滴内部提供给网约车等核心服务的容器平台,其基于 k8s 实现了对海量 node 的管理和 pod 的调度。本文重点介绍弹性云的调度能力,分为以下部分:调度链路图:介绍当前弹性云调度体系链路,对架构体系有一个初步的认知k8s 调度能力的运用:整体介绍弹性云现在用到的 k8s 调度能力和对其的增强k8s 版本的升级:介绍到从 k8s 1.12 到 1...._滴滴机房 腾讯
文章浏览阅读897次。对于cpu来说,这种分配方式并不会有太大问题,因为cpu可以灵活调度,numa调度时我们只计算绑定了numa cpu的pod是可以接受的,但是对于内存来说,numa node上申请了的内存无法做到随时迁移,这就会导致调度器视角numa node的mem资源足够,但是等到pod真正使用时,由于没有绑定numa node的pod申请的内存,导致numa node的mem资源不足,造成swap中断或者远端内存申请,这会对绑定mem的pod来带来性能损耗。忽略了没有绑定numa node的pod资源。_kubectl numa
文章浏览阅读796次,点赞17次,收藏15次。只要在Service定义中设置了ClusterIp:None,就定义了一个HeadLess Service, 它与普通的Service关键区别在于它没有ClusterIp地址,如果解析HeadLess Service的DNS域名,则会返回该Service对应的全部Pod的EndPoint列表,这就意味着客户端是直接与后端的pod建立了TCP/IP链接进行通信的。一个Label是一个键值对。注解:属于资源对象的元数据,可以被理解为一种特殊的标签,不过更多的是与程序挂钩,通常用于实现资源对象属性的自定义扩展。
文章浏览阅读763次。但是此时如果配置成 NONE, 租户创建成功了,但是无法创建资源文件,也就是无法上传文件,可能 dolphinscheduler 团队就想着将文件上传到 hdfs,暂不支持本地。需要将 resource.storage.type 置为 NONE, 因为我之前用的 1.3.6 版本的时候,即使资源文件存在本地文件也需要配置成 hdfs。_[error] 2023-10-24 18:10:43.762 +0800 org.apache.dolphinscheduler.api.servic
文章浏览阅读2.7k次,点赞2次,收藏13次。公司使用的是交老的k8s版本(1.16),由于老版本的K8s对于现在很多新特性不支持,所以需要升级到新版本。目前2023年7月11日最新版本的k8s是v1.27.3。通过参考官方文档进行k8s部署工作。其中涉及到操作系统配置、防火墙配置、私有镜像仓库等。_k8s最新版本
文章浏览阅读1.8w次,点赞14次,收藏27次。能节省你在kubeadm init 时遇到问题的排错时间⌚️。整合了网上大佬
文章浏览阅读1.1k次,点赞2次,收藏7次。具体操作步骤可以参考之前的教程,建议是先安装一台,然后克隆虚拟机,这样速度快。注意:在克隆时记得修改Mac地址、IP地址、UUID和主机名。(最后别忘了保存下快照~)_部署k8s集群
文章浏览阅读863次,点赞23次,收藏16次。当部署完 Kubernetes,便拥有了一个完整的集群。一组工作机器,称为节点, 会运行容器化应用程序。每个集群至少有一个工作节点。工作节点会 托管Pod ,而 Pod 就是作为应用负载的组件。控制平面管理集群中的工作节点和Pod。说人话版本:集群:cluster,多个几点被组织到一起共同为系统提供服务过程称之为集群。本质上是将承载同一个软件服务节点组织到一起,称之为该软件(服务)的集群,当然集群中的节点身份地位是不一样的。k8s集群也是如此,他也是多个节点组成。
文章浏览阅读943次。Rancher是一个开源的企业级多集群Kubernetes管理平台,实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理,以确保集群的安全性,加速企业数字化转型。Rancher 1.0版本在2016年就已发布,时至今日,Rancher已经成长为企业在生产环境中运行容器和Kubernetes的首要选择。_rancher管理k8s
文章浏览阅读742次,点赞2次,收藏3次。本篇来讲解如何在centos下安装部署高可用k8s集群。_kubeadm ha keepalived + nginx
文章浏览阅读1.9k次,点赞21次,收藏25次。那么这个空间设置成内存的2倍大小。点击IPv4设置--手动--添加--设置ip--设置DNS服务器,最后点击--“保存”;首先选中--“本地标准磁盘”,存储配置--自定义分区,点击--“完成”;在--主机名--设置主机名:(例如k8s-master01),点击--点击+,设置--挂载点/boot--期望容量,点击--添加挂载点;点击--+--挂载点swap--期望容量,点击--“添加挂载点”;默认选择--亚洲--上海,并调整日期和时间,点击--“完成”;设备类型--确认--LVM,卷组--选择“修改”;_euler 服务器搭建
文章浏览阅读1k次。在1.25版本的k8s集群中部署gpu-manage时,虽然显示gpu节点上gpu-manage的pod实例都是running状态,但是给pod申领。既可以用源码的Makefile自动编译打包成新的镜像,但是源码的。说明gpu-manager和容器运行时接口通信失败了。编译后的镜像在1.25版本的k8s中可以正常使用。,但是在k8s1.23版本之后,接口路径已经改为。资源时,却始终找不到有资源的节点。,另外有一些依赖需要国际上的支持。可以看到这里用的运行时接口是。查看节点的详情时,返回的。_launch gpu manager 报错 can't create container runtime manager: context dead
文章浏览阅读1k次,点赞18次,收藏16次。SelfLink:API的资源对象之一,表示资源对象在集群当中自身的一个连结,self-Link是一个唯一的标识号,可以用于标识k8s集群当中的每个资源的对象。容器里使用的配置,在provisioner当中定义好环境变量,传给容器,storageclass的名称,NFS服务器的地址,NFS的目录。NFS的provisionner的客户端以pod的方式运行在集群当中,监听k8s集群当中PV的请求,然后动态的创建于NFS相关的PV。命名为 nfs-client-provisioner-clusterrole。
文章浏览阅读6.3k次,点赞2次,收藏20次。k8s证书过期解决方案之替换证书_k8s证书过期如何更换
文章浏览阅读1k次。KMS,Key Management Service,即密钥管理服务,在K8S集群中,以驱动和插件的形式启用对Secret,Configmap进行加密。以保护敏感数据
文章浏览阅读888次。exporter对于云服务的监控还是很不完美,毕竟每家都有自己的护城河。自动发现多实例这样的借助consul 阿波罗这样的会简单一些。aws可以借助cloudwatch这样的导入模板到grafana中。还是希望能将类似腾讯云云监控中的这些指标采集到prometheus中,但是这过程应该还很遥远grafana出图 prometheus查询语法这些东西有时间的好好研究一下。报警有必要进行分级别,收敛配置一下!_command: - "-redis.password-file=/redis_passwd.json
文章浏览阅读1k次。可以在此处(https://cloud.google.com/kubernetes-engine/docs/how-to/kube-dns)和此处(https://www.digitalocean.com/community/tutorials/an-introduction-to-the-kubernetes-dns-service)找到更多的详细信息。-or-ipvs/)和此处(https://arthurchiao.art/blog/cracking-k8s-node-proxy/)。_k8s默认命名空间
文章浏览阅读4.9k次,点赞11次,收藏32次。如果运行runc命令时提示:runc: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory,则表明runc没有找到libseccomp,需要检查libseccomp是否安装,本次安装默认就可以查询到。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。_kubernetes 1.28
文章浏览阅读3.6w次,点赞118次,收藏144次。Canal 提供了网络功能,使得 Kubernetes 集群中的 Pod 可以相互通信,并与集群外部的服务进行通信。它通过网络插件的方式,为每个 Pod 分配唯一的 IP 地址,并管理网络流量的路由和转发。此外,Canal 还支持网络策略,用于定义 Pod 之间的通信规则和安全策略。Canal 基于 Calico 和 Flannel 项目,结合了二者的优点。它使用 Calico 的数据平面,提供高性能的网络转发和安全特性,同时使用 Flannel 的控制平面,实现 IP 地址管理和网络策略的配置。_k8s canal