etcd 集群运维实践

etcd 是 Kubernetes 集群的数据核心，最严重的情况是，当 etcd 出问题彻底无法恢复的时候，解决问题的办法可能只有重新搭建一个环境。因此围绕 etcd 相关的运维知识就比较重要，etcd 可以容器化部署，也可以在宿主机自行搭建，以下内容是通用的。

集群的备份和恢复

添加备份

1. #!/bin/bash

2. IP=123.123.123.123

3. BACKUP_DIR=/alauda/etcd_bak/

4. mkdir -p $BACKUP_DIR

5. export ETCDCTL_API=3

6. etcdctl --endpoints=http://$IP:2379 snapshot save $BACKUP/snap-$(date +%Y%m%d%H%M).db

8. # 备份一个节点的数据就可以恢复，实践中，为了防止定时任务配置的节点异常没有生成备份，建议多加几个

恢复集群

1. #!/bin/bash

3. # 使用 etcdctl snapshot restore 生成各个节点的数据

5. # 比较关键的变量是

6. # --data-dir 需要是实际 etcd 运行时的数据目录

7. # --name  --initial-advertise-peer-urls  需要用各个节点的配置

8. # --initial-cluster  initial-cluster-token 需要和原集群一致

10. ETCD_1=10.1.0.5

11. ETCD_2=10.1.0.6

12. ETCD_3=10.1.0.7

14. for i in ETCD_1 ETCD_2 ETCD_3

15. do

17. export ETCDCTL_API=3

18. etcdctl snapshot restore snapshot.db

19. --data-dir=/var/lib/etcd

20. --name $i

21. --initial-cluster ${ETCD_1}=http://${ETCD_1}:2380,${ETCD_2}=http://${ETCD_2}:2380,${ETCD_3}=http://${ETCD_3}:2380

22. --initial-cluster-token k8s_etcd_token

23. --initial-advertise-peer-urls http://$i:2380 &&

24. mv /var/lib/etcd/ etcd_$i

26. done

28. # 把 etcd_10.1.0.5 复制到 10.1.0.5节点，覆盖/var/lib/etcd（同--data-dir路径）

29. # 其他节点依次类推

用 etcd 自动创建的 SnapDb 恢复

1. #!/bin/bash

2. export ETCDCTL_API=3

3. etcdctl snapshot restore snapshot.db

4. --skip-hash-check

5. --data-dir=/var/lib/etcd

6. --name 10.1.0.5

7. --initial-cluster 10.1.0.5=http://10.1.0.5:2380,10.1.0.6=http://10.1.0.6:2380,10.1.0.7=http://10.1.0.7:2380

8. --initial-cluster-token k8s_etcd_token

9. --initial-advertise-peer-urls http://10.1.0.5:2380

11. # 也是所有节点都需要生成自己的数据目录，参考上一条

12. # 和上一条命令唯一的差别是多了  --skip-hash-check  （跳过完整性校验）

13. # 这种方式不能确保 100% 可恢复，建议还是自己加备份

14. # 通常恢复后需要做一下数据压缩和碎片整理，可参考相应章节

踩过的坑
[ 3.0.14 版 etcd restore 功能不可用 ] https://github.com/etcd-io/etcd/issues/7533
使用更新的 etcd 即可。
总结：恢复就是要拿 DB 去把 etcd 的数据生成一份，用同一个节点的，可以保证除了 restore 时候指定的参数外，所有数据都一样。这就是用一份 DB，操作三次（或者5次）的原因。

集群的扩容——从 1 到 3

执行添加

1. #!/bin/bash

2. export ETCDCTL_API=2

3. etcdctl --endpoints=http://10.1.0.6:2379 member add 10.1.0.6 http://10.1.0.6:2380

4. etcdctl --endpoints=http://10.1.0.7:2379 member add 10.1.0.7 http://10.1.0.7:2380

6. # ETCD_NAME="etcd_10.1.0.6"

7. # ETCD_INITIAL_CLUSTER="10.1.0.6=http://10.1.0.6:2380,10.1.0.5=http://10.1.0.5:2380"

8. # ETCD_INITIAL_CLUSTER_STATE="existing"

准备添加的节点 etcd 参数配置

1. #!/bin/bash

2. /usr/local/bin/etcd

3. --data-dir=/data.etcd

4. --name 10.1.0.6

5. --initial-advertise-peer-urls http://10.1.0.6:2380

6. --listen-peer-urls http://10.1.0.6:2380

7. --advertise-client-urls http://10.1.0.6:2379

8. --listen-client-urls http://10.1.0.6:2379

9. --initial-cluster 10.1.0.6=http://10.1.0.6:2380,10.1.0.5=http://10.1.0.5:2380

10. --initial-cluster-state exsiting

11. --initial-cluster-token k8s_etcd_token

13. # --initial-cluster 集群所有节点的 name=ip:peer_url

14. # --initial-cluster-state exsiting 告诉 etcd 自己归属一个已存在的集群，不要自立门户

踩过的坑
从 1 到 3 期间，会经过集群是两节点的状态，这时候可能集群的表现就像挂了，endpoint status 这些命令都不能用，所以我们需要用 member add 先把集群扩到三节点，然后再依次启动 etcd 实例，这样做就能确保 etcd 就是健康的。
从 3 到更多，其实还是 member add 啦，就放心搞吧。

集群加证书

生成证书

1. curl -s -L -o /usr/bin/cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64

2. curl -s -L -o /usr/bin/cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64

3. chmod +x /usr/bin/{cfssl,cfssljson}

4. cd /etc/kubernetes/pki/etcd

1. #  cat ca-config.json

2. {

3.  "signing": {

4.    "default": {

5.      "expiry": "100000h"

6.    },

7.    "profiles": {

8.      "server": {

9.        "usages": ["signing", "key encipherment", "server auth", "client auth"],

10.        "expiry": "100000h"

11.      },

12.      "client": {

13.        "usages": ["signing", "key encipherment", "server auth", "client auth"],

14.        "expiry": "100000h"

15.      }

16.    }

17.  }

18. }

1. #  cat ca-csr.json

2. {

3.  "CN": "etcd",

4.  "key": {

5.    "algo": "rsa",

6.    "size": 4096

7.  },

8.  "names": [

9.    {

10.      "C": "CN",

11.      "L": "Beijing",

12.      "O": "Alauda",

13.      "OU": "PaaS",

14.      "ST": "Beijing"

15.    }

16.  ]

17. }

1. #  cat server-csr.json

2. {

3.  "CN": "etcd-server",

4.  "hosts": [

5.    "localhost",

6.    "0.0.0.0",

7.    "127.0.0.1",

8.    "所有master 节点ip ",

9.    "所有master 节点ip ",

10.    "所有master 节点ip "

11.  ],

12.  "key": {

13.    "algo": "rsa",

14.    "size": 4096

15.  },

16.  "names": [

17.    {

18.      "C": "CN",

19.      "L": "Beijing",

20.      "O": "Alauda",

21.      "OU": "PaaS",

22.      "ST": "Beijing"

23.    }

24.  ]

25. }

1. # cat client-csr.json

3. {

4.  "CN": "etcd-client",

5.  "hosts": [

6.    ""

7.  ],

8.  "key": {

9.    "algo": "rsa",

10.    "size": 4096

11.  },

12.  "names": [

13.    {

14.      "C": "CN",

15.      "L": "Beijing",

16.      "O": "Alauda",

17.      "OU": "PaaS",

18.      "ST": "Beijing"

19.    }

20.  ]

21. }

1. cd /etc/kubernetes/pki/etcd

3. cfssl gencert -initca ca-csr.json | cfssljson -bare ca

5. cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server server-csr.json | cfssljson -bare server

7. cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client client-csr.json | cfssljson -bare client

参考链接：https://lihaoquan.me/2017/3/29/etcd-https-setup.html
首先更新节点的peer-urls

1. export ETCDCTL_API=3

2. etcdctl --endpoints=http://x.x.x.x:2379 member list

3.   #  1111111111  ..........

4.   #  2222222222  ..........

5.   #  3333333333  ..........

6. etcdctl --endpoints=http://172.30.0.123:2379 member update 1111111111 --peer-urls=https://x.x.x.x:2380

7.   # 执行三次把三个节点的peer-urls都改成https

修改配置

1. #  vim /etc/kubernetes/main*/etcd.yaml

3. #  etcd启动命令部分修改 http 为 https，启动状态改成 existing

4.    - --advertise-client-urls=https://x.x.x.x:2379

5.    - --initial-advertise-peer-urls=https://x.x.x.x:2380

6.    - --initial-cluster=xxx=https://x.x.x.x:2380,xxx=https://x.x.x.x:2380,xxx=https://x.x.x.x:2380

7.    - --listen-client-urls=https://x.x.x.x:2379

8.    - --listen-peer-urls=https://x.x.x.x:2380

9.    - --initial-cluster-state=existing

11. #  etcd 启动命令部分插入

12.    - --cert-file=/etc/kubernetes/pki/etcd/server.pem

13.    - --key-file=/etc/kubernetes/pki/etcd/server-key.pem

14.    - --peer-cert-file=/etc/kubernetes/pki/etcd/server.pem

15.    - --peer-key-file=/etc/kubernetes/pki/etcd/server-key.pem

16.    - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem

17.    - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem

18.    - --peer-client-cert-auth=true

19.    - --client-cert-auth=true

21. #  检索hostPath在其后插入

22.  - hostPath:

23.      path: /etc/kubernetes/pki/etcd

24.      type: DirectoryOrCreate

25.    name: etcd-certs

27. #  检索mountPath在其后插入

28.    - mountPath: /etc/kubernetes/pki/etcd

29.      name: etcd-certs

1. #  vim /etc/kubernetes/main*/kube-apiserver.yaml

2. #  apiserver 启动部分插入，修改 http 为https

3.    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.pem

4.    - --etcd-certfile=/etc/kubernetes/pki/etcd/client.pem

5.    - --etcd-keyfile=/etc/kubernetes/pki/etcd/client-key.pem

6.    - --etcd-servers=https://x.x.x.x:2379,https://x.x.x.x:2379,https://x.x.x.x:2379

总结下就是，先准备一套证书。然后修改 etcd 内部通信地址为https，这时候etcd日志会报错(可以忽略)，然后用etcd --带证书的参数启动，把所有链接etcd的地方都用上证书，即可。
遇到的坑
[ etcd 加证书后，apiserver 的健康检查还是 http 请求，etcd 会一直刷日志 ] https://github.com/etcd-io/etcd/issues/9285

1. 2018-02-06 12:41:06.905234 I | embed: rejected connection from "127.0.0.1:35574" (error "EOF", ServerName "")

解决办法：直接去掉 apiserver 的健康检查，或者把默认的检查命令换成 curl（apiserver 的镜像里应该没有 curl，如果是刚需的话自己重新 build 一下吧）。

集群升级

已经是 v3 的的集群不需要太多的配置，保留数据目录，替换镜像（或者二进制）即可；
v2 到 v3 的升级需要一个 merge 的操作，我并没有实际的实践过，也不太推荐这样做。

集群状态检查

其实上述所有步骤都需要这些命令的辅助——

1. #!/bin/bash

2. # 如果证书的话，去掉--cert --key --cacert 即可

3. # --endpoints= 需要写了几个节点的url，endpoint status就输出几条信息

5. export ETCDCTL_API=3

7. etcdctl

8. --endpoints=https://x.x.x.x:2379

9. --cert=/etc/kubernetes/pki/etcd/client.pem

10. --key=/etc/kubernetes/pki/etcd/client-key.pem

11. --cacert=/etc/kubernetes/pki/etcd/ca.pem

12. endpoint status -w table

14. etcdctl --endpoints=xxxx endpoint health

16. etcdctl --endpoints=xxxx member list

18. kubectl get cs

数据操作（删除、压缩、碎片整理）

删除

1. ETCDCTL_API=2 etcdctl rm --recursive            # v2 的 api 可以这样删除一个“目录”

2. ETCDCTL_API=3 etcdctl --endpoints=xxx del /xxxxx --prefix # v3 的版本

4. # 带证书的话，参考上一条添加 --cert --key --cacert 即可

遇到的坑：在一个客户环境里发现 Kubernetes 集群里的 “事件” 超级多，就是 kubectl describe xxx 看到的 events 部分信息，数据太大导致 etcd 跑的很累，我们就用这样的方式删掉没用的这些数据。
碎片整理

1. ETCDCTL_API=3 etcdctl --endpoints=xx:xx,xx:xx,xx:xx defrag

2. ETCDCTL_API=3 etcdctl --endpoints=xx:xx,xx:xx,xx:xx endpoint status # 看数据量

压缩

1. ETCDCTL_API=3 etcdctl --endpoints=xx:xx,xx:xx,xx:xx compact

3. # 这个在只有 K8s 用的 etcd 集群里作用不太大，可能具体场景我没遇到

4. # 可参考这个文档

5. # https://www.cnblogs.com/davygeek/p/8524477.html

6. # 不过跑一下不碍事

8. etcd --auto-compaction-retention=1

10. # 添加这个参数让 etcd 运行时自己去做压缩

常见问题 

1. etcd 对时间很依赖，所以集群里的节点时间一定要同步

2. 磁盘空间不足，如果磁盘是被 etcd 自己吃完了，就需要考虑压缩和删数据啦

3. 加证书后所有请求就都要带证书了，要不会提示 context deadline exceeded

4. 做各个操作时 etcd 启动参数里标明节点状态的要小心，否则需要重新做一遍前面的步骤很麻烦

日志收集 

etcd 的日志暂时只支持 syslog 和 stdout 两种——https://github.com/etcd-io/etcd/issues/7936。
etcd 的日志在排查故障时很有用，如果我们用宿主机来部署 etcd，日志可以通过 systemd 检索到，但 kubeadm 方式启动的 etcd 在容器重启后就会丢失所有历史。我们可以用以下的方案来做——
shell 的重定向

1. etcd --xxxx --xxxx   >  /var/log/etcd.log

2. # 配合 logratate 来做日志切割

3. # 将日志通过 volume 挂载到宿主机

supervisor
supervisor 从容器刚开始流行时，就是保持服务持续运行很有效的工具。
Sidecar 容器（后续我在 GitHub 上补充一个例子，github.com/jing2uo）
Sidecar 可以简单理解为一个 Pod 里有多个容器（比如 kubedns）他们彼此可以看到对方的进程，因此我们可以用传统的 strace 来捕捉 etcd 进程的输出，然后在 Sidecar 这个容器里和 shell 重定向一样操作。

1. strace  -e trace=write -s 200 -f -p 1

Kubeadm 1.13 部署的集群

最近我们测试 Kubernetes 1.13 集群时发现了一些有趣的改变，诈一看我们上面的命令就没法用了——
https://kubernetes.io/docs/setup/independent/ha-topology/
区分了 Stacked etcd topology 和 External etcd topology，官方的链接了这个图很形象—— 

这种模式下的 etcd 集群，最明显的差别是容器内 etcd 的initial-cluster 启动参数只有自己的 IP，会有点懵挂了我这该怎么去恢复。其实基本原理没有变，Kubeadm 藏了个 ConfigMap，启动参数被放在了这里——

1. kubectl get cm  etcdcfg -n kube-system -o yaml

1.    etcd:

2.      local:

3.        serverCertSANs:

4.        - "192.168.8.21"

5.        peerCertSANs:

6.        - "192.168.8.21"

7.        extraArgs:

8.          initial-cluster: 192.168.8.21=https://192.168.8.21:2380,192.168.8.22=https://192.168.8.22:2380,192.168.8.20=https://192.168.8.20:2380

9.          initial-cluster-state: new

10.          name: 192.168.8.21

11.          listen-peer-urls: https://192.168.8.21:2380

12.          listen-client-urls: https://192.168.8.21:2379

13.          advertise-client-urls: https://192.168.8.21:2379

14.          initial-advertise-peer-urls: https://192.168.8.21:2380

Q&A

Q：请问 etcd 监控和告警如何做的？告警项都有哪些？A：告警要看用的什么监控吧，和 Kubernetes 配套比较常见的是普罗米修思和 Grafana 了。告警项我没有具体配过，可以关注的点是：endpoint status -w table 里可以看到数据量，endpoints health 看到健康状态，还有内存使用这些，具体可以参考普罗米修思的 exporter 是怎么做的。
Q：使用 Kubeadm 部署高可用集群是不是相当于先部署三个独立的单点 Master，最后靠 etcd 添加节点操作把数据打通？A：不是，Kubeadm 部署会在最开始就先建一个 etcd 集群，apiserver 启动之前就需要准备好 etcd，否则 apiserver 起不了，集群之间就没法通信。可以尝试手动搭一下集群，不用 Kubeadm，一个个把组件开起来，之后对Kubernetes的组件关系会理解更好的。
Q：etcd 跨机房高可用如何保证呢？管理 etcd 有好的 UI 工具推荐么？A：etcd 对时间和网络要求很高，所以跨机房的网络不好的话性能很差，光在那边选请输入链接描述举去了。我分享忘了提一个 etcd 的 mirror，可以去参考下做法。跨机房的话，我觉得高速网络是个前提吧，不过还没做过。UI 工具没找过，都是命令行操作来着。
Q：Kubeadm 启动的集群内 etcd节点，kubectl 操作 etcd 的备份恢复有尝试过吗？A：没有用 kubectl 去处理过 etcd 的备份恢复。etcd 的恢复依赖用 SnapDb 生成数据目录，把 etcd 进程丢进容器里，类似的操作避免不了，还有启动的状态需要修改。kubeadm 启动的 etcd 可以通过 kubectl 查询和 exec，但是数据操作应该不可以，比如恢复 etcd ing 时，无法连接 etcd，kubectl 还怎么工作？
Q：kubeadm-ha 启动 3 个 Master，有 3 个 etcd 节点，怎么跟集群外的 3 个 etcd 做集群，做成 3 Master 6 etcd？A：可以参考文档里的扩容部分，只要保证 etcd 的参数正确，即使一个集群一部分容器化，一部分宿主机，都是可以的（当然不建议这么做）。可以先用 kubeadm 搭一个集群，然后用扩容的方式把其他三个节点加进来，或者在 kubeadm 操作之前，先搭一个 etcd 集群。然后 kubeadm 调用它就可以。
Q：有没有试过 Kubeadm 的滚动升级，etcd 版本变更，各 Master 机分别重启，数据同步是否有异常等等？A：做过。Kubeadm 的滚动升级公司内部有从 1.7 一步步升级到 1.11、1.12 的文档，或多或少有一点小坑，不过今天主题是 etcd 所以没提这部分。各个 Master 分别重启后数据的一致我们测试时没问题，还有比较极端的是直接把三 Master 停机一天，再启动后也能恢复。

阅读原文