etcd 叢集運維實踐
【編者的話】etcd 是 Kubernetes 叢集的資料核心，最嚴重的情況是，當 etcd 出問題徹底無法恢復的時候，解決問題的辦法可能只有重新搭建一個環境。因此圍繞 etcd 相關的運維知識就比較重要，etcd 可以容器化部署，也可以在宿主機自行搭建，以下內容是通用的。
叢集的備份和恢復
新增備份
#!/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 # 備份一個節點的資料就可以恢復，實踐中，為了防止定時任務配置的節點異常沒有生成備份，建議多加幾個
恢復叢集
#!/bin/bash
# 使用 etcdctl snapshot restore 生成各個節點的資料
# 比較關鍵的變數是
# --data-dir 需要是實際 etcd 執行時的資料目錄
# --name --initial-advertise-peer-urls 需要用各個節點的配置
# --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 複製到 10.1.0.5節點，覆蓋/var/lib/etcd（同--data-dir路徑）
# 其他節點依次類推
用 etcd 自動建立的 SnapDb 恢復
#!/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 # 也是所有節點都需要生成自己的資料目錄，參考上一條 # 和上一條命令唯一的差別是多了 --skip-hash-check （跳過完整性校驗） # 這種方式不能確保 100% 可恢復，建議還是自己加備份 # 通常恢復後需要做一下資料壓縮和碎片整理，可參考相應章節
踩過的坑
[ 3.0.14 版 etcd restore 功能不可用 ] https://github.com/etcd-io/etcd/issues/7533
使用更新的 etcd 即可。
總結：恢復就是要拿 DB 去把 etcd 的資料生成一份，用同一個節點的，可以保證除了 restore 時候指定的引數外，所有資料都一樣。這就是用一份 DB，操作三次（或者5次）的原因。
叢集的擴容——從 1 到 3
執行新增
#!/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"
準備新增的節點 etcd 引數配置
#!/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 叢集所有節點的 name=ip:peer_url # --initial-cluster-state exsiting 告訴 etcd 自己歸屬一個已存在的叢集，不要自立門戶
踩過的坑
從 1 到 3 期間，會經過叢集是兩節點的狀態，這時候可能叢集的表現就像掛了，endpoint status 這些命令都不能用，所以我們需要用 member add 先把叢集擴到三節點，然後再依次啟動 etcd 例項，這樣做就能確保 etcd 就是健康的。
從 3 到更多，其實還是 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 節點ip ",
"所有master 節點ip ",
"所有master 節點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
首先更新節點的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 # 執行三次把三個節點的peer-urls都改成https
修改配置
# vim /etc/kubernetes/main*/etcd.yaml # etcd啟動命令部分修改 http 為 https，啟動狀態改成 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 啟動命令部分插入 - --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 啟動部分插入，修改 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
總結下就是，先準備一套證書。然後修改 etcd 內部通訊地址為https，這時候etcd日誌會報錯(可以忽略)，然後用etcd --帶證書的引數啟動，把所有連結etcd的地方都用上證書，即可。
遇到的坑
[ etcd 加證書後，apiserver 的健康檢查還是 http 請求，etcd 會一直刷日誌 ] https://github.com/etcd-io/etcd/issues/9285
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 的操作，我並沒有實際的實踐過，也不太推薦這樣做。
叢集狀態檢查
其實上述所有步驟都需要這些命令的輔助——
#!/bin/bash # 如果證書的話，去掉--cert --key --cacert 即可 # --endpoints= 需要寫了幾個節點的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
資料操作（刪除、壓縮、碎片整理）
刪除
ETCDCTL_API=2 etcdctl rm --recursive # v2 的 api 可以這樣刪除一個“目錄” ETCDCTL_API=3 etcdctl --endpoints=xxx del /xxxxx --prefix # v3 的版本 # 帶證書的話，參考上一條新增 --cert --key --cacert 即可
遇到的坑：在一個客戶環境裡發現 Kubernetes 叢集裡的 “事件” 超級多，就是 kubectl describe xxx 看到的 events 部分資訊，資料太大導致 etcd 跑的很累，我們就用這樣的方式刪掉沒用的這些資料。
碎片整理
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 # 看資料量
壓縮
ETCDCTL_API=3 etcdctl --endpoints=xx:xx,xx:xx,xx:xx compact # 這個在只有 K8s 用的 etcd 叢集裡作用不太大，可能具體場景我沒遇到 # 可參考這個文件 # https://www.cnblogs.com/davygeek/p/8524477.html # 不過跑一下不礙事 etcd --auto-compaction-retention=1 # 新增這個引數讓 etcd 執行時自己去做壓縮
常見問題
- etcd 對時間很依賴，所以叢集裡的節點時間一定要同步
- 磁碟空間不足，如果磁碟是被 etcd 自己吃完了，就需要考慮壓縮和刪資料啦
- 加證書後所有請求就都要帶證書了，要不會提示 context deadline exceeded
- 做各個操作時 etcd 啟動引數裡標明節點狀態的要小心，否則需要重新做一遍前面的步驟很麻煩
日誌收集
etcd 的日誌暫時只支援 syslog 和 stdout 兩種——https://github.com/etcd-io/etcd/issues/7936
etcd 的日誌在排查故障時很有用，如果我們用宿主機來部署 etcd，日誌可以通過 systemd 檢索到，但 kubeadm 方式啟動的 etcd 在容器重啟後就會丟失所有歷史。我們可以用以下的方案來做——
shell 的重定向
etcd --xxxx --xxxx > /var/log/etcd.log # 配合 logratate 來做日誌切割 # 將日誌通過 volume 掛載到宿主機
supervisor
supervisor 從容器剛開始流行時，就是保持服務持續執行很有效的工具。
sidecar 容器（後續我在 GitHub 上補充一個例子，github.com/jing2uo）
Sidecar 可以簡單理解為一個 Pod 裡有多個容器（比如 kubedns）他們彼此可以看到對方的程序，因此我們可以用傳統的 strace 來捕捉 etcd 程序的輸出，然後在 Sidecar 這個容器裡和 shell 重定向一樣操作。
strace -e trace=write -s 200 -f -p 1
Kubeadm 1.13 部署的叢集
最近我們測試 Kubernetes 1.13 叢集時發現了一些有趣的改變，詐一看我們上面的命令就沒法用了——
https://kubernetes.io/docs/set ... logy/
區分了 Stacked etcd topology 和 External etcd topology，官方的連結了這個圖很形象——
這種模式下的 etcd 叢集，最明顯的差別是容器內 etcd 的initial-cluster 啟動引數只有自己的 IP，會有點懵掛了我這該怎麼去恢復。其實基本原理沒有變，Kubeadm 藏了個 ConfigMap，啟動引數被放在了這裡——
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 監控和告警如何做的？告警項都有哪些？
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 停機一天，再啟動後也能恢復。
以上內容根據2019年1月3日晚微信群分享內容整理。分享人郭靖，靈雀雲運維開發工程師，有大規模叢集運維經驗，對自動化迷之熱衷，精通Ansible，HashiCorp工具集，容器和Kubernetes鼓搗了三年，喜歡用Python和Go寫小工具，DevOps推崇及踐行者，近期關注和期待OpsMop。DockOne每週都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesd，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。