摘要：是集群的數(shù)據(jù)核心，最嚴(yán)重的情況是，當(dāng)出問題徹底無法恢復(fù)的時(shí)候，解決問題的辦法可能只有重新搭建一個(gè)環(huán)境。因此圍繞相關(guān)的運(yùn)維知識(shí)就比較重要，可以容器化部署，也可以在宿主機(jī)自行搭建，以下內(nèi)容是通用的。

etcd 是 Kubernetes 集群的數(shù)據(jù)核心，最嚴(yán)重的情況是，當(dāng) etcd 出問題徹底無法恢復(fù)的時(shí)候，解決問題的辦法可能只有重新搭建一個(gè)環(huán)境。因此圍繞 etcd 相關(guān)的運(yùn)維知識(shí)就比較重要，etcd 可以容器化部署，也可以在宿主機(jī)自行搭建，以下內(nèi)容是通用的。
集群的備份和恢復(fù)

添加備份

#!/bin/bash
IP=123.123.123.123
BACKUP_DIR=/alauda/etcd_bak/
mkdir -p $BACKUP_DIR
export ETCDCTL_API=3
etcdctl --endpoints=http://$IP:2379 snapshot save $BACKUP/snap-$(date +%Y%m%d%H%M).db
# 備份一個(gè)節(jié)點(diǎn)的數(shù)據(jù)就可以恢復(fù)，實(shí)踐中，為了防止定時(shí)任務(wù)配置的節(jié)點(diǎn)異常沒有生成備份，建議多加幾個(gè)

恢復(fù)集群

#!/bin/bash

# 使用 etcdctl snapshot restore 生成各個(gè)節(jié)點(diǎn)的數(shù)據(jù)

# 比較關(guān)鍵的變量是
# --data-dir 需要是實(shí)際 etcd 運(yùn)行時(shí)的數(shù)據(jù)目錄
# --name  --initial-advertise-peer-urls  需要用各個(gè)節(jié)點(diǎn)的配置
# --initial-cluster  initial-cluster-token 需要和原集群一致

ETCD_1=10.1.0.5
ETCD_2=10.1.0.6
ETCD_3=10.1.0.7

for i in ETCD_1 ETCD_2 ETCD_3
do

export ETCDCTL_API=3
etcdctl snapshot restore snapshot.db 
--data-dir=/var/lib/etcd 
--name $i 
--initial-cluster ${ETCD_1}=http://${ETCD_1}:2380,${ETCD_2}=http://${ETCD_2}:2380,${ETCD_3}=http://${ETCD_3}:2380 
--initial-cluster-token k8s_etcd_token 
--initial-advertise-peer-urls http://$i:2380 && 
mv /var/lib/etcd/ etcd_$i

done

# 把 etcd_10.1.0.5 復(fù)制到 10.1.0.5節(jié)點(diǎn)，覆蓋/var/lib/etcd（同--data-dir路徑）
# 其他節(jié)點(diǎn)依次類推

用 etcd 自動(dòng)創(chuàng)建的 SnapDb 恢復(fù)

#!/bin/bash 
export ETCDCTL_API=3
etcdctl snapshot restore snapshot.db 
--skip-hash-check 
--data-dir=/var/lib/etcd 
--name 10.1.0.5 
--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 
--initial-cluster-token k8s_etcd_token 
--initial-advertise-peer-urls http://10.1.0.5:2380

# 也是所有節(jié)點(diǎn)都需要生成自己的數(shù)據(jù)目錄，參考上一條
# 和上一條命令唯一的差別是多了  --skip-hash-check  （跳過完整性校驗(yàn)）
# 這種方式不能確保 100% 可恢復(fù)，建議還是自己加備份
# 通常恢復(fù)后需要做一下數(shù)據(jù)壓縮和碎片整理，可參考相應(yīng)章節(jié)

踩過的坑
[ 3.0.14 版 etcd restore 功能不可用 ] https://github.com/etcd-io/et...

使用更新的 etcd 即可。

總結(jié)：恢復(fù)就是要拿 DB 去把 etcd 的數(shù)據(jù)生成一份，用同一個(gè)節(jié)點(diǎn)的，可以保證除了 restore 時(shí)候指定的參數(shù)外，所有數(shù)據(jù)都一樣。這就是用一份 DB，操作三次（或者5次）的原因。
集群的擴(kuò)容——從 1 到 3
執(zhí)行添加

#!/bin/bash
export ETCDCTL_API=2
etcdctl --endpoints=http://10.1.0.6:2379 member add 10.1.0.6 http://10.1.0.6:2380
etcdctl --endpoints=http://10.1.0.7:2379 member add 10.1.0.7 http://10.1.0.7:2380

# ETCD_NAME="etcd_10.1.0.6" 
# ETCD_INITIAL_CLUSTER="10.1.0.6=http://10.1.0.6:2380,10.1.0.5=http://10.1.0.5:2380"
# ETCD_INITIAL_CLUSTER_STATE="existing"

準(zhǔn)備添加的節(jié)點(diǎn) etcd 參數(shù)配置

#!/bin/bash
/usr/local/bin/etcd 
--data-dir=/data.etcd 
--name 10.1.0.6
--initial-advertise-peer-urls http://10.1.0.6:2380 
--listen-peer-urls http://10.1.0.6:2380 
--advertise-client-urls http://10.1.0.6:2379 
--listen-client-urls http://10.1.0.6:2379 
--initial-cluster 10.1.0.6=http://10.1.0.6:2380,10.1.0.5=http://10.1.0.5:2380
--initial-cluster-state exsiting
--initial-cluster-token k8s_etcd_token

# --initial-cluster 集群所有節(jié)點(diǎn)的 name=ip:peer_url
# --initial-cluster-state exsiting 告訴 etcd 自己歸屬一個(gè)已存在的集群，不要自立門戶

踩過的坑
從 1 到 3 期間，會(huì)經(jīng)過集群是兩節(jié)點(diǎn)的狀態(tài)，這時(shí)候可能集群的表現(xiàn)就像掛了，endpoint status 這些命令都不能用，所以我們需要用 member add 先把集群擴(kuò)到三節(jié)點(diǎn)，然后再依次啟動(dòng) etcd 實(shí)例，這樣做就能確保 etcd 就是健康的。

從 3 到更多，其實(shí)還是 member add 啦，就放心搞吧。
集群加證書
生成證書

curl -s -L -o /usr/bin/cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
curl -s -L -o /usr/bin/cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
chmod +x /usr/bin/{cfssl,cfssljson}
cd /etc/kubernetes/pki/etcd

#  cat ca-config.json
{
"signing": {
"default": {
  "expiry": "100000h"
},
"profiles": {
  "server": {
    "usages": ["signing", "key encipherment", "server auth", "client auth"],
    "expiry": "100000h"
  },
  "client": {
    "usages": ["signing", "key encipherment", "server auth", "client auth"],
    "expiry": "100000h"
  }
}
}
} 

#  cat ca-csr.json
{
"CN": "etcd",
"key": {
"algo": "rsa",
"size": 4096
},
"names": [
{
  "C": "CN",
  "L": "Beijing",
  "O": "Alauda",
  "OU": "PaaS",
  "ST": "Beijing"
}
]
} 

#  cat server-csr.json
{
"CN": "etcd-server",
"hosts": [
"localhost",
"0.0.0.0",
"127.0.0.1",
"所有master 節(jié)點(diǎn)ip ",
"所有master 節(jié)點(diǎn)ip ",
"所有master 節(jié)點(diǎn)ip "
],
"key": {
"algo": "rsa",
"size": 4096
},
"names": [
{
  "C": "CN",
  "L": "Beijing",
  "O": "Alauda",
  "OU": "PaaS",
  "ST": "Beijing"
}
]
} 

# cat client-csr.json

{
"CN": "etcd-client",
"hosts": [
""
],
"key": {
"algo": "rsa",
"size": 4096
},
"names": [
{
  "C": "CN",
  "L": "Beijing",
  "O": "Alauda",
  "OU": "PaaS",
  "ST": "Beijing"
}
]
} 

cd /etc/kubernetes/pki/etcd

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

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

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 ... .html

首先更新節(jié)點(diǎn)的peer-urls

export ETCDCTL_API=3
etcdctl --endpoints=http://x.x.x.x:2379 member list
#  1111111111  ..........
#  2222222222  ..........
#  3333333333  ..........
etcdctl --endpoints=http://172.30.0.123:2379 member update 1111111111 --peer-urls=https://x.x.x.x:2380
# 執(zhí)行三次把三個(gè)節(jié)點(diǎn)的peer-urls都改成https

修改配置

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

#  etcd啟動(dòng)命令部分修改 http 為 https，啟動(dòng)狀態(tài)改成 existing
- --advertise-client-urls=https://x.x.x.x:2379
- --initial-advertise-peer-urls=https://x.x.x.x:2380
- --initial-cluster=xxx=https://x.x.x.x:2380,xxx=https://x.x.x.x:2380,xxx=https://x.x.x.x:2380
- --listen-client-urls=https://x.x.x.x:2379
- --listen-peer-urls=https://x.x.x.x:2380
- --initial-cluster-state=existing

#  etcd 啟動(dòng)命令部分插入
- --cert-file=/etc/kubernetes/pki/etcd/server.pem
- --key-file=/etc/kubernetes/pki/etcd/server-key.pem
- --peer-cert-file=/etc/kubernetes/pki/etcd/server.pem
- --peer-key-file=/etc/kubernetes/pki/etcd/server-key.pem
- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem
- --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem
- --peer-client-cert-auth=true
- --client-cert-auth=true

#  檢索hostPath在其后插入
- hostPath:
  path: /etc/kubernetes/pki/etcd
  type: DirectoryOrCreate
name: etcd-certs

#  檢索mountPath在其后插入
- mountPath: /etc/kubernetes/pki/etcd
  name: etcd-certs

#  vim /etc/kubernetes/main*/kube-apiserver.yaml
#  apiserver 啟動(dòng)部分插入，修改 http 為https
- --etcd-cafile=/etc/kubernetes/pki/etcd/ca.pem
- --etcd-certfile=/etc/kubernetes/pki/etcd/client.pem
- --etcd-keyfile=/etc/kubernetes/pki/etcd/client-key.pem
- --etcd-servers=https://x.x.x.x:2379,https://x.x.x.x:2379,https://x.x.x.x:2379

總結(jié)下就是，先準(zhǔn)備一套證書。然后修改 etcd 內(nèi)部通信地址為https，這時(shí)候etcd日志會(huì)報(bào)錯(cuò)(可以忽略)，然后用etcd --帶證書的參數(shù)啟動(dòng)，把所有鏈接etcd的地方都用上證書，即可。
遇到的坑
[ etcd 加證書后，apiserver 的健康檢查還是 http 請求，etcd 會(huì)一直刷日志 ] https://github.com/etcd-io/et...
2018-02-06 12:41:06.905234 I | embed: rejected connection from "127.0.0.1:35574" (error "EOF", ServerName "")

解決辦法：直接去掉 apiserver 的健康檢查，或者把默認(rèn)的檢查命令換成 curl（apiserver 的鏡像里應(yīng)該沒有 curl，如果是剛需的話自己重新 build 一下吧）
集群升級
已經(jīng)是 v3 的的集群不需要太多的配置，保留數(shù)據(jù)目錄，替換鏡像（或者二進(jìn)制）即可；

v2 到 v3 的升級需要一個(gè) merge 的操作，我并沒有實(shí)際的實(shí)踐過，也不太推薦這樣做。
集群狀態(tài)檢查
其實(shí)上述所有步驟都需要這些命令的輔助——

#!/bin/bash
# 如果證書的話，去掉--cert --key --cacert 即可
# --endpoints= 需要寫了幾個(gè)節(jié)點(diǎn)的url，endpoint status就輸出幾條信息

export ETCDCTL_API=3

etcdctl 
--endpoints=https://x.x.x.x:2379  
--cert=/etc/kubernetes/pki/etcd/client.pem 
--key=/etc/kubernetes/pki/etcd/client-key.pem 
--cacert=/etc/kubernetes/pki/etcd/ca.pem 
endpoint status -w table

etcdctl --endpoints=xxxx endpoint health

etcdctl --endpoints=xxxx member list

kubectl get cs

數(shù)據(jù)操作（刪除、壓縮、碎片整理）
刪除

ETCDCTL_API=2 etcdctl rm --recursive            # v2 的 api 可以這樣刪除一個(gè)“目錄”
ETCDCTL_API=3 etcdctl --endpoints=xxx del /xxxxx --prefix # v3 的版本

# 帶證書的話，參考上一條添加 --cert --key --cacert 即可

遇到的坑：在一個(gè)客戶環(huán)境里發(fā)現(xiàn) Kubernetes 集群里的 “事件” 超級多，就是 kubectl describe xxx 看到的 events 部分信息，數(shù)據(jù)太大導(dǎo)致 etcd 跑的很累，我們就用這樣的方式刪掉沒用的這些數(shù)據(jù)。
碎片整理
ETCDCTL_API=3 etcdctl --endpoints=xx:xx,xx:xx,xx:xx defrag
ETCDCTL_API=3 etcdctl --endpoints=xx:xx,xx:xx,xx:xx endpoint status # 看數(shù)據(jù)量

壓縮

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

# 這個(gè)在只有 K8s 用的 etcd 集群里作用不太大，可能具體場景我沒遇到
# 可參考這個(gè)文檔
# https://www.cnblogs.com/davygeek/p/8524477.html
# 不過跑一下不礙事

etcd --auto-compaction-retention=1

# 添加這個(gè)參數(shù)讓 etcd 運(yùn)行時(shí)自己去做壓縮

常見問題
etcd 對時(shí)間很依賴，所以集群里的節(jié)點(diǎn)時(shí)間一定要同步
磁盤空間不足，如果磁盤是被 etcd 自己吃完了，就需要考慮壓縮和刪數(shù)據(jù)啦
加證書后所有請求就都要帶證書了，要不會(huì)提示 context deadline exceeded
做各個(gè)操作時(shí) etcd 啟動(dòng)參數(shù)里標(biāo)明節(jié)點(diǎn)狀態(tài)的要小心，否則需要重新做一遍前面的步驟很麻煩

日志收集
etcd 的日志暫時(shí)只支持 syslog 和 stdout 兩種——https://github.com/etcd-io/et...

etcd 的日志在排查故障時(shí)很有用，如果我們用宿主機(jī)來部署 etcd，日志可以通過 systemd 檢索到，但 kubeadm 方式啟動(dòng)的 etcd 在容器重啟后就會(huì)丟失所有歷史。我們可以用以下的方案來做——
shell 的重定向

etcd --xxxx --xxxx   >  /var/log/etcd.log 
# 配合 logratate 來做日志切割
# 將日志通過 volume 掛載到宿主機(jī)

supervisor
supervisor 從容器剛開始流行時(shí)，就是保持服務(wù)持續(xù)運(yùn)行很有效的工具。
sidecar 容器（后續(xù)我在 GitHub 上補(bǔ)充一個(gè)例子，github.com/jing2uo）
Sidecar 可以簡單理解為一個(gè) Pod 里有多個(gè)容器（比如 kubedns）他們彼此可以看到對方的進(jìn)程，因此我們可以用傳統(tǒng)的 strace 來捕捉 etcd 進(jìn)程的輸出，然后在 Sidecar 這個(gè)容器里和 shell 重定向一樣操作。
strace -e trace=write -s 200 -f -p 1

Kubeadm 1.13 部署的集群
最近我們測試 Kubernetes 1.13 集群時(shí)發(fā)現(xiàn)了一些有趣的改變，詐一看我們上面的命令就沒法用了——

https://kubernetes.io/docs/set ... logy/

區(qū)分了 Stacked etcd topology 和 External etcd topology，官方的鏈接了這個(gè)圖很形象——
B70D000C-83B2-4B9C-A612-53925238D0DA.png

這種模式下的 etcd 集群，最明顯的差別是容器內(nèi) etcd 的initial-cluster 啟動(dòng)參數(shù)只有自己的 IP，會(huì)有點(diǎn)懵掛了我這該怎么去恢復(fù)。其實(shí)基本原理沒有變，Kubeadm 藏了個(gè) ConfigMap，啟動(dòng)參數(shù)被放在了這里——

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

etcd:
  local:
    serverCertSANs:
    - "192.168.8.21"
    peerCertSANs:
    - "192.168.8.21"
    extraArgs:
      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
      initial-cluster-state: new
      name: 192.168.8.21
      listen-peer-urls: https://192.168.8.21:2380
      listen-client-urls: https://192.168.8.21:2379
      advertise-client-urls: https://192.168.8.21:2379
      initial-advertise-peer-urls: https://192.168.8.21:2380

Q&A
Q：請問 etcd 監(jiān)控和告警如何做的？告警項(xiàng)都有哪些？
A：告警要看用的什么監(jiān)控吧，和 Kubernetes 配套比較常見的是普羅米修思和 Grafana 了。告警項(xiàng)我沒有具體配過，可以關(guān)注的點(diǎn)是：endpoint status -w table 里可以看到數(shù)據(jù)量，endpoints health 看到健康狀態(tài)，還有內(nèi)存使用這些，具體可以參考普羅米修思的 exporter 是怎么做的。
Q：使用 Kubeadm 部署高可用集群是不是相當(dāng)于先部署三個(gè)獨(dú)立的單點(diǎn) Master，最后靠 etcd 添加節(jié)點(diǎn)操作把數(shù)據(jù)打通？
A：不是，Kubeadm 部署會(huì)在最開始就先建一個(gè) etcd 集群，apiserver 啟動(dòng)之前就需要準(zhǔn)備好 etcd，否則 apiserver 起不了，集群之間就沒法通信。可以嘗試手動(dòng)搭一下集群，不用 Kubeadm，一個(gè)個(gè)把組件開起來，之后對Kubernetes的組件關(guān)系會(huì)理解更好的。
Q：etcd 跨機(jī)房高可用如何保證呢？管理 etcd 有好的 UI 工具推薦么？
A：etcd 對時(shí)間和網(wǎng)絡(luò)要求很高，所以跨機(jī)房的網(wǎng)絡(luò)不好的話性能很差，光在那邊選請輸入鏈接描述舉去了。我分享忘了提一個(gè) etcd 的 mirror，可以去參考下做法。跨機(jī)房的話，我覺得高速網(wǎng)絡(luò)是個(gè)前提吧，不過還沒做過。UI 工具沒找過，都是命令行操作來著。
Q：Kubeadm 啟動(dòng)的集群內(nèi) etcd節(jié) 點(diǎn)，kubectl 操作 etcd 的備份恢復(fù)有嘗試過嗎？
A：沒有用 kubectl 去處理過 etcd 的備份恢復(fù)。etcd 的恢復(fù)依賴用 SnapDb 生成數(shù)據(jù)目錄，把 etcd 進(jìn)程丟進(jìn)容器里，類似的操作避免不了，還有啟動(dòng)的狀態(tài)需要修改。kubeadm 啟動(dòng)的 etcd 可以通過 kubectl 查詢和 exec，但是數(shù)據(jù)操作應(yīng)該不可以，比如恢復(fù) etcd ing 時(shí)，無法連接 etcd，kubectl 還怎么工作？
Q：kubeadm-ha 啟動(dòng) 3 個(gè) Master，有 3 個(gè) etcd 節(jié)點(diǎn)，怎么跟集群外的 3 個(gè) etcd 做集群，做成 3 Master 6 etcd？
A：可以參考文檔里的擴(kuò)容部分，只要保證 etcd 的參數(shù)正確，即使一個(gè)集群一部分容器化，一部分宿主機(jī)，都是可以的（當(dāng)然不建議這么做）。可以先用 kubeadm 搭一個(gè)集群，然后用擴(kuò)容的方式把其他三個(gè)節(jié)點(diǎn)加進(jìn)來，或者在 kubeadm 操作之前，先搭一個(gè) etcd 集群。然后 kubeadm 調(diào)用它就可以。
Q：有沒有試過 Kubeadm 的滾動(dòng)升級，etcd 版本變更，各 Master 機(jī)分別重啟，數(shù)據(jù)同步是否有異常等等？
A：做過。Kubeadm 的滾動(dòng)升級公司內(nèi)部有從 1.7 一步步升級到 1.11、1.12 的文檔，或多或少有一點(diǎn)小坑，不過今天主題是 etcd 所以沒提這部分。各個(gè) Master 分別重啟后數(shù)據(jù)的一致我們測試時(shí)沒問題，還有比較極端的是直接把三 Master 停機(jī)一天，再啟動(dòng)后也能恢復(fù)。
以上內(nèi)容根據(jù)2019年1月3日晚微信群分享內(nèi)容整理。分享人郭靖，靈雀云運(yùn)維開發(fā)工程師，有大規(guī)模集群運(yùn)維經(jīng)驗(yàn)，對自動(dòng)化迷之熱衷，精通Ansible，HashiCorp工具集，容器和Kubernetes鼓搗了三年，喜歡用Python和Go寫小工具，DevOps推崇及踐行者，近期關(guān)注和期待OpsMop。DockOne每周都會(huì)組織定向的技術(shù)分享，歡迎感興趣的同學(xué)加微信：liyingjiesd，進(jìn)群參與，您有想聽的話題或者想分享的話題都可以給我們留言。