建立Kubernetes cluster時,ETCD 是必不可少的元件,事實上Kubernetes所有資料都會存進ETCD store中,如果要讓Kubernetes的運行效能更好,其中一種方法是在部署之前對ETCD的性能進行優化設計。
本篇整理了之前研究ETCD時的一些文章和相關知識,以及在規劃時需要注意的重點,希望能夠幫助大家在部署前有一些可以參考的原則。

- K8S是如何連接ETCD
- Kubernetes 物件在ETCD的儲存路徑
- 堆疊型的ETCD
- 外部的ETCD cluster
- 性能調校
1. K8S是如何連接ETCD
- etcd是Kubernetes的後端儲存
- 針對每個Kubernetes物件都有對應負責的儲存操作
- 初始化kubeadm-config 中指定ETCD servers的集群,例如:

ETCD對於Kube-apiserver是一個Client的角色,需要它們的certificates並指定這些節點的位置
2. Kubernetes 物件在ETCD的儲存路徑
#-------------------------------------------------
# S2-1. 以以下方式找出路徑
#-------------------------------------------------
[root]# ETCDCTL_API=3 etcdctl \
--cert /etc/kubernetes/pki/etcd/peer.crt \
--key /etc/kubernetes/pki/etcd/peer.key \
--cacert /etc/kubernetes/pki/etcd/ca.crt \
--endpoints https://10.107.88.15:2379
[root]# etcdctl get / --prefix --keys-only
* --keys-only: 只列出key不列出內容

#----------------------------------------------
# S2-2. 將路徑的內容dump出來
#----------------------------------------------
[root]# etcdctl get /registry/namespaces/default -w json | jq

#--------------------------------------------
# S2-3. key還可以再解析出來
#--------------------------------------------
[root]# echo "key" | base64 --decode
/registry/namespaces/default
以上是apiserver透過/api/v1/registry/namespaces/default
去get namespace時,就等於在etcd內get /registry/namespaces/default
,整體邏輯是一樣的,將整段組成一支key之後儲存在ETEC內。
3. 堆疊型的ETCD
將ETCD的三個節點與三個Master結合,好處是建立容易,副本的管理容易,由於是在同一個節點,所以可以直接讀取,不用再透過網路傳輸,速度更快。缺點是當Master有一個節點故障就代表etcd cluster也會有失去一個成員的風險。
這種方式的ETCD會以Pod的型式存在,由Kubelet自行管理,方式如下:
--> kubelet讀取config,config內定義了static pod路徑,透過kubelet掃描這個路徑來看有沒有Pod,如果有就直接掛載
Note: ETCD cluster重視disk io

4. 外部的ETCD cluster
將ETCD與Master間的關係解開,所以當一台Master出現問題後影響ETCD member的較少。缺點是需要的主機數量更多,至少要再加3台主機成為ETCD cluster。

5. 性能調校
ETCD的回應速度會直接影響Kubernetes cluster的操作,進一步也會影響Cluster的穩定性。
平時就需要監控ETCD成員的效能表現,對於效能有問題的成員進行修復或移除,如果發現整體效能低下時,可以用以下原則進行調校。
一般影響的因素有以下二個:
- 網路延遲(RTT)
- Disk IO (資料實際儲存需要的時間)
以下是針對性能調校幾個考量因素:
※ 思考點-成員:

愈多愈好?
- 成員是1個? 3個? 5個?
- 保證高可用性是否最重要?
- 成員如果變多會提升整體同時讀取的能力?
- apiserver的設定連接到本地的etcd 成員?
- 有需要動態擴展嗎?
※ 結論:
(1) 因為ETCD為投票方式決定Leader,如果偶數會出現票數相等的情況導致出現重新投票,Leader的產生就會很久,所以選擇奇數
。
成員數選擇:
- 1個:沒有高可用容錯,但效能最佳,但資料無法保證安全
- 3個:具備最基本的容錯,效能在中間
- 5個:效能最差,但節點更多,成本更高
(2) ETCD cluster邏輯與一般不同,成員愈多時,資料寫入所需要確認的成員就愈多,效能就會更低。
(3) 所有寫入
都是由Leader成員執行
(4) apiserver的設定會指定所有的ETCD 成員,但只有目前連接的etcd成員異常,apiserver才會換目標
※ 思考點 — apiserver 與ETCD之間的溝通:

有效率的溝通
要怎麼確保apiserver與ETCD之間的溝通是有效率的,可以做以下考量:
- 將apiserver與etcd部署在同一個節點
- 因為apiserver與etcd之間的溝通是基於
gRPC
,有以下特點:
gRPC:不管從同一個Client有多少請求,都會重復使用同一個connection到server,
同一個group也是共有一個gRPC connection,故pod , node都是透過同一個gRPC連到etcd
- 問題:大規模的cluster可能link會很滿,例如:1000個pod,一次list所傳回的資料量可能會超過100M
# kubectl get pod - all-namespace | wc -l
# kubectl get pod -o yaml - all-namespace > pods
# ls -al pods
結論:
- put 時盡量避免大量的數值。避免頻繁建立key-value(kv),例如k8s節點心跳回報機制(kube-node-lease)合理利用 apiserver 中的Cache,避免大量請求打到 etcd上,如集群異常回復後大量的Pod同步。
6.結論:
尤於篇幅過長,之後將繼續於另一篇文章進行說明。
自從深入了解ETCD之後,發現這個元件本身的知識量就很多,但因為ETCD在Kubernetes的角色的關係,個人認為如果事先規劃有做好,大致上在部署之後不會面對到太多會需要直接操作的機會(最好也不要 :) )。
當了解這些考慮因素後,進行部署前的溝通會議將可以更加清晰且具有方向。
Reference: