如何進(jìn)行etcd集群運(yùn)維實(shí)踐

131次閱讀

共計(jì) 9808 個(gè)字符，預(yù)計(jì)需要花費(fèi) 25 分鐘才能閱讀完成。

本篇文章為大家展示了如何進(jìn)行 etcd 集群運(yùn)維實(shí)踐，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。

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

集群的備份和恢復(fù)

添加備份

#!/bin/bashIP=123.123.123.123BACKUP_DIR=/alauda/etcd_bak/mkdir -p $BACKUP_DIRexport ETCDCTL_API=3etcdctl –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.5ETCD_2=10.1.0.6ETCD_3=10.1.0.7for i in ETCD_1 ETCD_2 ETCD_3doexport ETCDCTL_API=3etcdctl 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_$idone# 把 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=3etcdctl 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 （跳過(guò)完整性校驗(yàn)）# 這種方式不能確保 100% 可恢復(fù)，建議還是自己加備份# 通常恢復(fù)后需要做一下數(shù)據(jù)壓縮和碎片整理，可參考相應(yīng)章節(jié)

踩過(guò)的坑

[3.0.14 版 etcd restore 功能不可用] https://github.com/etcd-io/etcd/issues/7533 使用更新的 etcd 即可。總結(jié)：恢復(fù)就是要拿 DB 去把 etcd 的數(shù)據(jù)生成一份，用同一個(gè)節(jié)點(diǎn)的，可以保證除了 restore 時(shí)候指定的參數(shù)外，所有數(shù)據(jù)都一樣。這就是用一份 DB，操作三次（或者 5 次）的原因。

集群的擴(kuò)容——從 1 到 3

執(zhí)行添加

#!/bin/bashexport ETCDCTL_API=2etcdctl –endpoints=http://10.1.0.6:2379 member add 10.1.0.6 http://10.1.0.6:2380etcdctl –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è)已存在的集群，不要自立門戶

踩過(guò)的坑

從 1 到 3 期間，會(huì)經(jīng)過(guò)集群是兩節(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-amd64curl -s -L -o /usr/bin/cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64chmod +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/etcdcfssl gencert -initca ca-csr.json | cfssljson -bare cacfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server server-csr.json | cfssljson -bare servercfssl 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=3etcdctl –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: DirectoryOrCreatename: 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 請(qǐng)求，etcd 會(huì)一直刷日志] 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 的健康檢查，或者把默認(rèn)的檢查命令換成 curl（apiserver 的鏡像里應(yīng)該沒有 curl，如果是剛需的話自己重新 build 一下吧）

集群升級(jí)

已經(jīng)是 v3 的的集群不需要太多的配置，保留數(shù)據(jù)目錄，替換鏡像（或者二進(jìn)制）即可；v2 到 v3 的升級(jí)需要一個(gè) merge 的操作，我并沒有實(shí)際的實(shí)踐過(guò)，也不太推薦這樣做。

集群狀態(tài)檢查

其實(shí)上述所有步驟都需要這些命令的輔助——

#!/bin/bash# 如果證書的話，去掉 –cert –key –cacert 即可 # –endpoints= 需要寫了幾個(gè)節(jié)點(diǎn)的 url，endpoint status 就輸出幾條信息 export ETCDCTL_API=3etcdctl –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 tableetcdctl –endpoints=xxxx endpoint healthetcdctl –endpoints=xxxx member listkubectl 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 集群里的“事件”超級(jí)多，就是 kubectl describe xxx 看到的 events 部分信息，數(shù)據(jù)太大導(dǎo)致 etcd 跑的很累，我們就用這樣的方式刪掉沒用的這些數(shù)據(jù)。

碎片整理

ETCDCTL_API=3 etcdctl –endpoints=xx:xx,xx:xx,xx:xx defragETCDCTL_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 集群里作用不太大，可能具體場(chǎng)景我沒遇到 # 可參考這個(gè)文檔# https://www.cnblogs.com/davygeek/p/8524477.html# 不過(guò)跑一下不礙事 etcd –auto-compaction-retention=1# 添加這個(gè)參數(shù)讓 etcd 運(yùn)行時(shí)自己去做壓縮

常見問(wèn)題

etcd 對(duì)時(shí)間很依賴，所以集群里的節(jié)點(diǎn)時(shí)間一定要同步磁盤空間不足，如果磁盤是被 etcd 自己吃完了，就需要考慮壓縮和刪數(shù)據(jù)啦加證書后所有請(qǐng)求就都要帶證書了，要不會(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/etcd/issues/7936etcd 的日志在排查故障時(shí)很有用，如果我們用宿主機(jī)來(lái)部署 etcd，日志可以通過(guò) systemd 檢索到，但 kubeadm 方式啟動(dòng)的 etcd 在容器重啟后就會(huì)丟失所有歷史。我們可以用以下的方案來(lái)做——

shell 的重定向

etcd –xxxx –xxxx /var/log/etcd.log # 配合 logratate 來(lái)做日志切割 # 將日志通過(guò) volume 掛載到宿主機(jī)

supervisor

supervisor 從容器剛開始流行時(shí)，就是保持服務(wù)持續(xù)運(yùn)行很有效的工具。

sidecar 容器（后續(xù)我在 GitHub 上補(bǔ)充一個(gè)例子，github.com/jing2uo）

Sidecar 可以簡(jiǎn)單理解為一個(gè) Pod 里有多個(gè)容器（比如 kubedns）他們彼此可以看到對(duì)方的進(jìn)程，因此我們可以用傳統(tǒng)的 strace 來(lái)捕捉 etcd 進(jìn)程的輸出，然后在 Sidecar 這個(gè)容器里和 shell 重定向一樣操作。

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

Kubeadm 1.13 部署的集群

最近我們測(cè)試 Kubernetes 1.13 集群時(shí)發(fā)現(xiàn)了一些有趣的改變，詐一看我們上面的命令就沒法用了——https://kubernetes.io/docs/set … logy/ 區(qū)分了 Stacked etcd topology 和 External etcd topology，官方的鏈接了這個(gè)圖很形象——

這種模式下的 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：請(qǐng)問(wèn) etcd 監(jiān)控和告警如何做的？告警項(xiàng)都有哪些？

A：告警要看用的什么監(jiān)控吧，和 Kubernetes 配套比較常見的是普羅米修思和 Grafana 了。告警項(xiàng)我沒有具體配過(guò)，可以關(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è)把組件開起來(lái)，之后對(duì) Kubernetes 的組件關(guān)系會(huì)理解更好的。

Q：etcd 跨機(jī)房高可用如何保證呢？管理 etcd 有好的 UI 工具推薦么？

A：etcd 對(duì)時(shí)間和網(wǎng)絡(luò)要求很高，所以跨機(jī)房的網(wǎng)絡(luò)不好的話性能很差，光在那邊選請(qǐng)輸入鏈接描述舉去了。我分享忘了提一個(gè) etcd 的 mirror，可以去參考下做法。跨機(jī)房的話，我覺得高速網(wǎng)絡(luò)是個(gè)前提吧，不過(guò)還沒做過(guò)。UI 工具沒找過(guò)，都是命令行操作來(lái)著。

Q：Kubeadm 啟動(dòng)的集群內(nèi) etcd 節(jié) 點(diǎn)，kubectl 操作 etcd 的備份恢復(fù)有嘗試過(guò)嗎？

A：沒有用 kubectl 去處理過(guò) etcd 的備份恢復(fù)。etcd 的恢復(fù)依賴用 SnapDb 生成數(shù)據(jù)目錄，把 etcd 進(jìn)程丟進(jìn)容器里，類似的操作避免不了，還有啟動(dòng)的狀態(tài)需要修改。kubeadm 啟動(dòng)的 etcd 可以通過(guò) kubectl 查詢和 exec，但是數(shù)據(jù)操作應(yīng)該不可以，比如恢復(fù) etcd ing 時(shí)，無(wú)法連接 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)來(lái)，或者在 kubeadm 操作之前，先搭一個(gè) etcd 集群。然后 kubeadm 調(diào)用它就可以。

Q：有沒有試過(guò) Kubeadm 的滾動(dòng)升級(jí)，etcd 版本變更，各 Master 機(jī)分別重啟，數(shù)據(jù)同步是否有異常等等？

A：做過(guò)。Kubeadm 的滾動(dòng)升級(jí)公司內(nèi)部有從 1.7 一步步升級(jí)到 1.11、1.12 的文檔，或多或少有一點(diǎn)小坑，不過(guò)今天主題是 etcd 所以沒提這部分。各個(gè) Master 分別重啟后數(shù)據(jù)的一致我們測(cè)試時(shí)沒問(wèn)題，還有比較極端的是直接把三 Master 停機(jī)一天，再啟動(dòng)后也能恢復(fù)。

上述內(nèi)容就是如何進(jìn)行 etcd 集群運(yùn)維實(shí)踐，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。

正文完