優化效能的關鍵: 加速 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的集群，例如：
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:
