摘要:是集群的數(shù)據(jù)核心,最嚴重的情況是,當出問題徹底無法恢復的時候,解決問題的辦法可能只有重新搭建一個環(huán)境。因此圍繞相關的運維知識就比較重要,可以容器化部署,也可以在宿主機自行搭建,以下內(nèi)容是通用的。
etcd 是 Kubernetes 集群的數(shù)據(jù)核心,最嚴重的情況是,當 etcd 出問題徹底無法恢復的時候,解決問題的辦法可能只有重新搭建一個環(huán)境。因此圍繞 etcd 相關的運維知識就比較重要,etcd 可以容器化部署,也可以在宿主機自行搭建,以下內(nèi)容是通用的。
集群的備份和恢復
添加備份
#!/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 # 備份一個節(jié)點的數(shù)據(jù)就可以恢復,實踐中,為了防止定時任務配置的節(jié)點異常沒有生成備份,建議多加幾個
恢復集群
#!/bin/bash # 使用 etcdctl snapshot restore 生成各個節(jié)點的數(shù)據(jù) # 比較關鍵的變量是 # --data-dir 需要是實際 etcd 運行時的數(shù)據(jù)目錄 # --name --initial-advertise-peer-urls 需要用各個節(jié)點的配置 # --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節(jié)點,覆蓋/var/lib/etcd(同--data-dir路徑) # 其他節(jié)點依次類推
用 etcd 自動創(chuàng)建的 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 # 也是所有節(jié)點都需要生成自己的數(shù)據(jù)目錄,參考上一條 # 和上一條命令唯一的差別是多了 --skip-hash-check (跳過完整性校驗) # 這種方式不能確保 100% 可恢復,建議還是自己加備份 # 通常恢復后需要做一下數(shù)據(jù)壓縮和碎片整理,可參考相應章節(jié)
踩過的坑
[ 3.0.14 版 etcd restore 功能不可用 ] https://github.com/etcd-io/et...
使用更新的 etcd 即可。
總結:恢復就是要拿 DB 去把 etcd 的數(shù)據(jù)生成一份,用同一個節(jié)點的,可以保證除了 restore 時候指定的參數(shù)外,所有數(shù)據(jù)都一樣。這就是用一份 DB,操作三次(或者5次)的原因。
集群的擴容——從 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"
準備添加的節(jié)點 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é)點的 name=ip:peer_url # --initial-cluster-state exsiting 告訴 etcd 自己歸屬一個已存在的集群,不要自立門戶
踩過的坑
從 1 到 3 期間,會經(jīng)過集群是兩節(jié)點的狀態(tài),這時候可能集群的表現(xiàn)就像掛了,endpoint status 這些命令都不能用,所以我們需要用 member add 先把集群擴到三節(jié)點,然后再依次啟動 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 節(jié)點ip ", "所有master 節(jié)點ip ", "所有master 節(jié)點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é)點的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í)行三次把三個節(jié)點的peer-urls都改成https
修改配置
# vim /etc/kubernetes/main*/etcd.yaml # etcd啟動命令部分修改 http 為 https,啟動狀態(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 啟動命令部分插入 - --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 內(nèi)部通信地址為https,這時候etcd日志會報錯(可以忽略),然后用etcd --帶證書的參數(shù)啟動,把所有鏈接etcd的地方都用上證書,即可。
遇到的坑
[ etcd 加證書后,apiserver 的健康檢查還是 http 請求,etcd 會一直刷日志 ] 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 的健康檢查,或者把默認的檢查命令換成 curl(apiserver 的鏡像里應該沒有 curl,如果是剛需的話自己重新 build 一下吧)
集群升級
已經(jīng)是 v3 的的集群不需要太多的配置,保留數(shù)據(jù)目錄,替換鏡像(或者二進制)即可;
v2 到 v3 的升級需要一個 merge 的操作,我并沒有實際的實踐過,也不太推薦這樣做。
集群狀態(tài)檢查
其實上述所有步驟都需要這些命令的輔助——
#!/bin/bash # 如果證書的話,去掉--cert --key --cacert 即可 # --endpoints= 需要寫了幾個節(jié)點的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 可以這樣刪除一個“目錄” ETCDCTL_API=3 etcdctl --endpoints=xxx del /xxxxx --prefix # v3 的版本 # 帶證書的話,參考上一條添加 --cert --key --cacert 即可
遇到的坑:在一個客戶環(huán)境里發(fā)現(xiàn) Kubernetes 集群里的 “事件” 超級多,就是 kubectl describe xxx 看到的 events 部分信息,數(shù)據(jù)太大導致 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 # 這個在只有 K8s 用的 etcd 集群里作用不太大,可能具體場景我沒遇到 # 可參考這個文檔 # https://www.cnblogs.com/davygeek/p/8524477.html # 不過跑一下不礙事 etcd --auto-compaction-retention=1 # 添加這個參數(shù)讓 etcd 運行時自己去做壓縮
常見問題
etcd 對時間很依賴,所以集群里的節(jié)點時間一定要同步
磁盤空間不足,如果磁盤是被 etcd 自己吃完了,就需要考慮壓縮和刪數(shù)據(jù)啦
加證書后所有請求就都要帶證書了,要不會提示 context deadline exceeded
做各個操作時 etcd 啟動參數(shù)里標明節(jié)點狀態(tài)的要小心,否則需要重新做一遍前面的步驟很麻煩
日志收集
etcd 的日志暫時只支持 syslog 和 stdout 兩種——https://github.com/etcd-io/et...
etcd 的日志在排查故障時很有用,如果我們用宿主機來部署 etcd,日志可以通過 systemd 檢索到,但 kubeadm 方式啟動的 etcd 在容器重啟后就會丟失所有歷史。我們可以用以下的方案來做——
shell 的重定向
etcd --xxxx --xxxx > /var/log/etcd.log # 配合 logratate 來做日志切割 # 將日志通過 volume 掛載到宿主機
supervisor
supervisor 從容器剛開始流行時,就是保持服務持續(xù)運行很有效的工具。
sidecar 容器(后續(xù)我在 GitHub 上補充一個例子,github.com/jing2uo)
Sidecar 可以簡單理解為一個 Pod 里有多個容器(比如 kubedns)他們彼此可以看到對方的進程,因此我們可以用傳統(tǒng)的 strace 來捕捉 etcd 進程的輸出,然后在 Sidecar 這個容器里和 shell 重定向一樣操作。
strace -e trace=write -s 200 -f -p 1
Kubeadm 1.13 部署的集群
最近我們測試 Kubernetes 1.13 集群時發(fā)現(xiàn)了一些有趣的改變,詐一看我們上面的命令就沒法用了——
https://kubernetes.io/docs/set ... logy/
區(qū)分了 Stacked etcd topology 和 External etcd topology,官方的鏈接了這個圖很形象——
B70D000C-83B2-4B9C-A612-53925238D0DA.png
這種模式下的 etcd 集群,最明顯的差別是容器內(nèi) etcd 的initial-cluster 啟動參數(shù)只有自己的 IP,會有點懵掛了我這該怎么去恢復。其實基本原理沒有變,Kubeadm 藏了個 ConfigMap,啟動參數(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)控和告警如何做的?告警項都有哪些?
A:告警要看用的什么監(jiān)控吧,和 Kubernetes 配套比較常見的是普羅米修思和 Grafana 了。告警項我沒有具體配過,可以關注的點是:endpoint status -w table 里可以看到數(shù)據(jù)量,endpoints health 看到健康狀態(tài),還有內(nèi)存使用這些,具體可以參考普羅米修思的 exporter 是怎么做的。
Q:使用 Kubeadm 部署高可用集群是不是相當于先部署三個獨立的單點 Master,最后靠 etcd 添加節(jié)點操作把數(shù)據(jù)打通?
A:不是,Kubeadm 部署會在最開始就先建一個 etcd 集群,apiserver 啟動之前就需要準備好 etcd,否則 apiserver 起不了,集群之間就沒法通信。可以嘗試手動搭一下集群,不用 Kubeadm,一個個把組件開起來,之后對Kubernetes的組件關系會理解更好的。
Q:etcd 跨機房高可用如何保證呢?管理 etcd 有好的 UI 工具推薦么?
A:etcd 對時間和網(wǎng)絡要求很高,所以跨機房的網(wǎng)絡不好的話性能很差,光在那邊選請輸入鏈接描述舉去了。我分享忘了提一個 etcd 的 mirror,可以去參考下做法。跨機房的話,我覺得高速網(wǎng)絡是個前提吧,不過還沒做過。UI 工具沒找過,都是命令行操作來著。
Q:Kubeadm 啟動的集群內(nèi) etcd節(jié) 點,kubectl 操作 etcd 的備份恢復有嘗試過嗎?
A:沒有用 kubectl 去處理過 etcd 的備份恢復。etcd 的恢復依賴用 SnapDb 生成數(shù)據(jù)目錄,把 etcd 進程丟進容器里,類似的操作避免不了,還有啟動的狀態(tài)需要修改。kubeadm 啟動的 etcd 可以通過 kubectl 查詢和 exec,但是數(shù)據(jù)操作應該不可以,比如恢復 etcd ing 時,無法連接 etcd,kubectl 還怎么工作?
Q:kubeadm-ha 啟動 3 個 Master,有 3 個 etcd 節(jié)點,怎么跟集群外的 3 個 etcd 做集群,做成 3 Master 6 etcd?
A:可以參考文檔里的擴容部分,只要保證 etcd 的參數(shù)正確,即使一個集群一部分容器化,一部分宿主機,都是可以的(當然不建議這么做)。可以先用 kubeadm 搭一個集群,然后用擴容的方式把其他三個節(jié)點加進來,或者在 kubeadm 操作之前,先搭一個 etcd 集群。然后 kubeadm 調(diào)用它就可以。
Q:有沒有試過 Kubeadm 的滾動升級,etcd 版本變更,各 Master 機分別重啟,數(shù)據(jù)同步是否有異常等等?
A:做過。Kubeadm 的滾動升級公司內(nèi)部有從 1.7 一步步升級到 1.11、1.12 的文檔,或多或少有一點小坑,不過今天主題是 etcd 所以沒提這部分。各個 Master 分別重啟后數(shù)據(jù)的一致我們測試時沒問題,還有比較極端的是直接把三 Master 停機一天,再啟動后也能恢復。
以上內(nèi)容根據(jù)2019年1月3日晚微信群分享內(nèi)容整理。分享人郭靖,靈雀云運維開發(fā)工程師,有大規(guī)模集群運維經(jīng)驗,對自動化迷之熱衷,精通Ansible,HashiCorp工具集,容器和Kubernetes鼓搗了三年,喜歡用Python和Go寫小工具,DevOps推崇及踐行者,近期關注和期待OpsMop。DockOne每周都會組織定向的技術分享,歡迎感興趣的同學加微信:liyingjiesd,進群參與,您有想聽的話題或者想分享的話題都可以給我們留言。
文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/32835.html
摘要:是集群的數(shù)據(jù)核心,最嚴重的情況是,當出問題徹底無法恢復的時候,解決問題的辦法可能只有重新搭建一個環(huán)境。因此圍繞相關的運維知識就比較重要,可以容器化部署,也可以在宿主機自行搭建,以下內(nèi)容是通用的。 etcd 是 Kubernetes 集群的數(shù)據(jù)核心,最嚴重的情況是,當 etcd 出問題徹底無法恢復的時候,解決問題的辦法可能只有重新搭建一個環(huán)境。因此圍繞 etcd 相關的運維知識就比較重要...
摘要:容器云的背景伴隨著微服務的架構的普及,結合開源的和等微服務框架,宜信內(nèi)部很多業(yè)務線逐漸了從原來的單體架構逐漸轉移到微服務架構。 容器云的背景 伴隨著微服務的架構的普及,結合開源的Dubbo和Spring Cloud等微服務框架,宜信內(nèi)部很多業(yè)務線逐漸了從原來的單體架構逐漸轉移到微服務架構。應用從有狀態(tài)到無狀態(tài),具體來說將業(yè)務狀態(tài)數(shù)據(jù)如:會話、用戶數(shù)據(jù)等存儲到中間件中服務中。 showI...
摘要:容器云的背景伴隨著微服務的架構的普及,結合開源的和等微服務框架,宜信內(nèi)部很多業(yè)務線逐漸了從原來的單體架構逐漸轉移到微服務架構。 容器云的背景 伴隨著微服務的架構的普及,結合開源的Dubbo和Spring Cloud等微服務框架,宜信內(nèi)部很多業(yè)務線逐漸了從原來的單體架構逐漸轉移到微服務架構。應用從有狀態(tài)到無狀態(tài),具體來說將業(yè)務狀態(tài)數(shù)據(jù)如:會話、用戶數(shù)據(jù)等存儲到中間件中服務中。 showI...
摘要:容器云架構方案。容器云架構方案基于容器技術,運維技術團隊開發(fā)了五阿哥網(wǎng)站的容器云平臺。多云對接私有云和公有云進行統(tǒng)一托管,包含網(wǎng)絡區(qū)域配置,實例開通及的環(huán)境初始化配置等。技術選型及實踐鏡像標準眾所周知,的鏡像是分層的。 前言 五阿哥鋼鐵電商平臺(www.wuage.com)是由鋼鐵行業(yè)第一的中國五礦與互聯(lián)網(wǎng)第一的阿里巴巴聯(lián)手打造,并充分運用雙方股東優(yōu)勢資源,即:阿里巴巴在大數(shù)據(jù)、電商運...
摘要:王磊此次演講的題目為容器新技術架構下的運維實踐,詳細為大家講解了在基于構建容器的過程中,如何以應用為中心,通過新的技術工具對服務節(jié)點集群平臺等多個方面進行管理運維,提高系統(tǒng)的自動化運維能力。 2018年11月16-17日,運維&容器技術盛會 CNUTCon 全球運維技術大會在上海·光大會展中心成功舉辦。時速云聯(lián)合創(chuàng)始人兼 CTO 王磊受邀參加此次大會,并發(fā)表主題演講。王磊此次演講的題目...
閱讀 1050·2021-11-22 15:35
閱讀 1685·2021-10-26 09:49
閱讀 3230·2021-09-02 15:11
閱讀 2075·2019-08-30 15:53
閱讀 2636·2019-08-30 15:53
閱讀 2917·2019-08-30 14:11
閱讀 3527·2019-08-30 12:59
閱讀 3241·2019-08-30 12:53