優化效能的關鍵: 加速 ETCD

建立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的集群，例如：

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:

• Etcd 高可用集群与性能优化
• etcd总结
• https://kubernetes.io/docs/concepts/architecture/nodes/