螞蟻集團(tuán)運(yùn)維著可能是全球最大的k8s集群：k8s官方以5k node作為k8s規(guī)模化的頂峰，而螞蟻集團(tuán)事實(shí)上運(yùn)維著規(guī)模達(dá)到10k node規(guī)模的k8s集群。一個(gè)形象的比喻就是，如果官方以及跟著官方的k8s使用者能想象到的k8s的集群規(guī)模是泰山，那么螞蟻集團(tuán)在官方的解決方案之上已經(jīng)實(shí)現(xiàn)了一個(gè)珠穆朗瑪峰，引領(lǐng)了k8s規(guī)?；夹g(shù)的提升。
這個(gè)量級(jí)的差異，不僅僅是量的差異，更是k8s管理維護(hù)的質(zhì)的提升。能維護(hù)有如此巨大挑戰(zhàn)巨量規(guī)模的k8s集群，其背后原因是螞蟻集團(tuán)付出了遠(yuǎn)大于k8s官方的優(yōu)化努力。
所謂萬丈高樓平地起，本文著重討論下螞蟻集團(tuán)的在k8s的基石---etcd層面做出的高可用建設(shè)工作：只有etcd這個(gè)基石穩(wěn)當(dāng)了，k8s這棟高樓大廈才保持穩(wěn)定性，有tidb大佬黃東旭朋友圈佐證【圖片已獲黃總授權(quán)】。
面臨的挑戰(zhàn)
etcd首先是k8s集群的KV數(shù)據(jù)庫。
從數(shù)據(jù)庫的角度來看，k8s整體集群架構(gòu)各個(gè)角色如下：
etcd集群的數(shù)據(jù)庫
kube-apiserver etcd的API接口代理、數(shù)據(jù)緩存層
kubelet數(shù)據(jù)的生產(chǎn)者和消費(fèi)者
kube-controller-manager數(shù)據(jù)的消費(fèi)者和生產(chǎn)者
kube-scheduler數(shù)據(jù)的消費(fèi)者和生產(chǎn)者
etcd本質(zhì)是一個(gè)KV數(shù)據(jù)庫，存儲(chǔ)了k8s自身資源、用戶自定義的CRD以及k8s系統(tǒng)的event等數(shù)據(jù)。每種數(shù)據(jù)的一致性和數(shù)據(jù)安全性要求不一致，如event數(shù)據(jù)的安全性小于k8s自身的資源數(shù)據(jù)以及CRD數(shù)據(jù)。
k8s的早期擁護(hù)者在推廣k8s時(shí)，宣稱其比OpenStack的優(yōu)勢(shì)之一是k8s沒有使用消息隊(duì)列，其延遲比OpenStack低。這其實(shí)是一個(gè)誤解，無論是etcd提供的watch接口，還是k8s client包中的informer機(jī)制，無不表明k8s是把etcd當(dāng)做了消息隊(duì)列，k8s消息的載體很多，譬如k8s event。
從消息隊(duì)列的角度來看，k8s整體集群架構(gòu)各個(gè)角色如下：
etcd消息路由器
kube-apiserver etcd生產(chǎn)者消息代理和消息廣播【或者成為次級(jí)消息路由器、消費(fèi)者代理】
kubelet消息的生產(chǎn)者和消費(fèi)者
kube-controller-manager消息的消費(fèi)者和生產(chǎn)者
kube-scheduler消息的消費(fèi)者和生產(chǎn)者
etcd是推模式的消息隊(duì)列。etcd是k8s集群的KV數(shù)據(jù)庫和消息路由器，充當(dāng)了OpenStack集群中的MySQL和MQ兩個(gè)角色，這樣的實(shí)現(xiàn)貌似簡(jiǎn)化了集群的結(jié)構(gòu)，但其實(shí)不然。在large scale規(guī)模k8s集群中，一般經(jīng)驗(yàn)，首先都會(huì)使用一個(gè)單獨(dú)etcd集群存儲(chǔ)event數(shù)據(jù)：把KV數(shù)據(jù)和一部分MQ數(shù)據(jù)物理隔離開，實(shí)現(xiàn)了KV和MQ角色的部分分離。如參考文檔2中提到美團(tuán)“針對(duì)etcd的運(yùn)營，通過拆分出獨(dú)立的event集群降低主庫的壓力”。
當(dāng)k8s集群規(guī)模擴(kuò)大時(shí)，etcd承載著KV數(shù)據(jù)劇增、event消息暴增以及消息寫放大的三種壓力。為了證明所言非虛，特引用部分?jǐn)?shù)據(jù)為佐證：
etcd KV數(shù)據(jù)量級(jí)在100萬以上；
etcd event數(shù)據(jù)量在10萬以上；
etcd讀流量壓力峰值在30萬pqm以上，其中讀event在10k qpm以上；
etcd寫流量壓力峰值在20萬pqm以上，其中寫event在15k qpm以上；
etcd CPU經(jīng)常性飆升到900%以上；
etcd內(nèi)存RSS在60 GiB以上；
etcd磁盤使用量可達(dá)100 GiB以上；
etcd自身的goroutine數(shù)量9k以上；
etcd使用的用戶態(tài)線程達(dá)1.6k以上；
etcd gc單次耗時(shí)常態(tài)下可達(dá)15ms。
使用Go語言實(shí)現(xiàn)的etcd管理這些數(shù)據(jù)非常吃力，無論是CPU、內(nèi)存、gc、goroutine數(shù)量還是線程使用量，基本上都接近go runtime管理能力極限：經(jīng)常在CPU profile中觀測(cè)到go runtime和gc占用資源超過50%以上。
螞蟻的k8s集群在經(jīng)歷高可用項(xiàng)目維護(hù)之前，當(dāng)集群規(guī)模突破7千節(jié)點(diǎn)規(guī)模時(shí)，曾出現(xiàn)如下性能瓶頸問題：
etcd出現(xiàn)大量的讀寫延遲，延遲甚至可達(dá)分鐘級(jí)；
kube-apiserver查詢pods/nodes/configmap/crd延時(shí)很高，導(dǎo)致etcd oom；
etcd list-all pods時(shí)長(zhǎng)可達(dá)30分鐘以上；
2020年etcd集群曾因list-all壓力被打垮導(dǎo)致的事故就達(dá)好幾起；
控制器無法及時(shí)感知數(shù)據(jù)變化，如出現(xiàn)watch數(shù)據(jù)延遲可達(dá)30s以上。
如果說這種狀況下的etcd集群是在刀鋒上跳舞，此時(shí)的整個(gè)k8s集群就是一個(gè)活火山：稍不留神就有可能背個(gè)P級(jí)故障，彼時(shí)的整個(gè)k8s master運(yùn)維工作大概是整個(gè)螞蟻集團(tuán)最危險(xiǎn)的工種之一。
高可用策略
實(shí)現(xiàn)一個(gè)分布式系統(tǒng)高可用能力的提升，大概有如下手段：
提升自身穩(wěn)定性與性能；
精細(xì)管理上游流量；
保證服務(wù)下游服務(wù)SLO。
etcd經(jīng)過社區(qū)與各方使用者這么多年的錘煉，其自身的穩(wěn)定性足夠。螞蟻人能做到的，無非是使出周扒皮的本事，提高集群資源整體利用率，scale out和scale up兩種技術(shù)手段雙管齊下，盡可能的提升其性能。
etcd自身作為k8s的基石，其并無下游服務(wù)。如果說有，那也是其自身所使用的物理node環(huán)境了。下面分別從etcd集群性能提升、請(qǐng)求流量管理等角度闡述我們?cè)趀tcd層面所做出的高可用能力提升工作。
文件系統(tǒng)升級(jí)
在山窩里飛出金鳳凰，誠非易事。讓etcd跑的更快這件事，沒有什么手段比提供一個(gè)高性能的機(jī)器更短平快地見效了。
1.使用NVMe ssd
etcd自身=etcd程序+其運(yùn)行環(huán)境。早期etcd服務(wù)器使用的磁盤是SATA盤，經(jīng)過簡(jiǎn)單地測(cè)試發(fā)現(xiàn)etcd讀磁盤速率非常慢，老板豪橫地把機(jī)器鳥槍換炮---升級(jí)到使用了NVMe SSD的f53規(guī)格的機(jī)器：etcd使用NVMe ssd存儲(chǔ)boltdb數(shù)據(jù)后，隨機(jī)寫速率可提升到70 MiB/s以上。
參考文檔2中提到美團(tuán)“基于高配的SSD物理機(jī)器部署可以達(dá)到日常5倍的高流量訪問”，可見提升硬件性能是大廠的首選，能折騰機(jī)器千萬別浪費(fèi)人力。
2.使用tmpfs
NVMe ssd雖好，理論上其讀寫極限性能跟內(nèi)存比還是差一個(gè)數(shù)量級(jí)。我們測(cè)試發(fā)現(xiàn)使用tmpfs【未禁止swap out】替換NVMe ssd后，etcd在讀寫并發(fā)的情況下性能仍然能提升20%之多?？疾靕8s各種數(shù)據(jù)類型的特點(diǎn)后，考慮到event對(duì)數(shù)據(jù)的安全性要求不高但是對(duì)實(shí)時(shí)性要求較高的特點(diǎn)，我們毫不猶豫的把event etcd集群運(yùn)行在了tmpfs文件系統(tǒng)之上，將k8s整體的性能提升了一個(gè)層次。
3.磁盤文件系統(tǒng)
磁盤存儲(chǔ)介質(zhì)升級(jí)后，存儲(chǔ)層面能夠進(jìn)一步做的事情就是研究磁盤的文件系統(tǒng)格式。目前etcd使用的底層文件系統(tǒng)是ext4格式，其block size使用的是默認(rèn)的4 KiB。我們團(tuán)隊(duì)曾對(duì)etcd進(jìn)行單純的在單純寫并行壓測(cè)時(shí)發(fā)現(xiàn)，把文件系統(tǒng)升級(jí)為xfs，且block size為16 KiB【在測(cè)試的KV size總和10 KiB條件下】時(shí)，etcd的寫性能仍然有提升空間。
但在讀寫并發(fā)的情況下，磁盤本身的寫隊(duì)列幾乎毫無壓力，又由于etcd 3.4版本實(shí)現(xiàn)了并行緩存讀，磁盤的讀壓力幾乎為零，這就意味著：繼續(xù)優(yōu)化文件系統(tǒng)對(duì)etcd的性能提升空間幾乎毫無幫助。自此以后單節(jié)點(diǎn)etcd scale up的關(guān)鍵就從磁盤轉(zhuǎn)移到了內(nèi)存：優(yōu)化其內(nèi)存索引讀寫速度。
4.磁盤透明大頁
在現(xiàn)代操作系統(tǒng)的內(nèi)存管理中，有huge page和transparent huge page兩種技術(shù)，不過一般用戶采用transparent huge page實(shí)現(xiàn)內(nèi)存page的動(dòng)態(tài)管理。在etcd運(yùn)行環(huán)境，關(guān)閉transparent huge page功能，否則RT以及QPS等經(jīng)常性的監(jiān)控指標(biāo)會(huì)經(jīng)常性的出現(xiàn)很多毛刺，導(dǎo)致性能不平穩(wěn)。
etcd調(diào)參
MySQL運(yùn)維工程師常被人稱為“調(diào)參工程師”，另一個(gè)有名的KV數(shù)據(jù)庫RocksDB也不遑多讓，二者可調(diào)整的參數(shù)之多到了令人發(fā)指的地方：其關(guān)鍵就在于針對(duì)不同存儲(chǔ)和運(yùn)行環(huán)境需要使用不同的參數(shù)，才能充分利用硬件的性能。etcd隨不及之，但也不拉人后，預(yù)計(jì)以后其可調(diào)整參數(shù)也會(huì)越來越多。
etcd自身也對(duì)外暴露了很多參數(shù)調(diào)整接口。除了阿里集團(tuán)k8s團(tuán)隊(duì)曾經(jīng)做出的把freelist由list改進(jìn)為map組織形式優(yōu)化外，目前常規(guī)的etcd可調(diào)整參數(shù)如下：
write batch
compaction
1.write batch
像其他常規(guī)的DB一樣，etcd磁盤提交數(shù)據(jù)時(shí)也采用了定時(shí)批量提交、異步寫盤的方式提升吞吐，并通過內(nèi)存緩存的方式平衡其延時(shí)。具體的調(diào)整參數(shù)接口如下：
batch write number批量寫KV數(shù)目，默認(rèn)值是10k；
batch write interval批量寫事件間隔，默認(rèn)值是100 ms。
etcd batch這兩個(gè)默認(rèn)值在大規(guī)模k8s集群下是不合適的，需要針對(duì)具體的運(yùn)行環(huán)境調(diào)整之，避免導(dǎo)致內(nèi)存使用OOM。一般地規(guī)律是，集群node數(shù)目越多，這兩個(gè)值就應(yīng)該成比例減小。
2.compaction
etcd自身由于支持事務(wù)和消息通知，所以采用了MVCC機(jī)制保存了一個(gè)key的多版本數(shù)據(jù)，etcd使用定時(shí)的compaction機(jī)制回收這些過時(shí)數(shù)據(jù)。etcd對(duì)外提供的壓縮任務(wù)參數(shù)如下：
compaction interval壓縮任務(wù)周期時(shí)長(zhǎng)；
compaction sleep interval單次壓縮批次間隔時(shí)長(zhǎng)，默認(rèn)10 ms；
compaction batch limit單次壓縮批次KV數(shù)目，默認(rèn)1000。
（1）壓縮任務(wù)周期
k8s集群的etcd compaction可以有兩種途徑進(jìn)行compaction：
etcd另外提供了comapct命令和API接口，k8s kube-apiserver基于這個(gè)API接口也對(duì)外提供了compact周期參數(shù)；
etcd自身會(huì)周期性地執(zhí)行compaction；
etcd對(duì)外提供了自身周期性compaction參數(shù)調(diào)整接口，這個(gè)參數(shù)的取值范圍是(0,1 hour]；
其意義是：etcd compaction即只能打開不能關(guān)閉，如果設(shè)置的周期時(shí)長(zhǎng)大于1 hour，則etcd會(huì)截?cái)酁? hour。
螞蟻k8s團(tuán)隊(duì)在經(jīng)過測(cè)試和線下環(huán)境驗(yàn)證后，目前的壓縮周期取值經(jīng)驗(yàn)是：
在etcd層面把compaction周期盡可能地拉長(zhǎng)，如取值1 hour，形同在etcd自身層面關(guān)閉compaction，把compaction interval的精細(xì)調(diào)整權(quán)交給k8s kube-apiserver；
在k8s kube-apiserver層面，根據(jù)線上集群規(guī)模取值不同的compaction interval。
之所以把etcd compaction interval精細(xì)調(diào)整權(quán)調(diào)整到kube-apiserver層面，是因?yàn)閑tcd是KV數(shù)據(jù)庫，不方便經(jīng)常性地啟停進(jìn)行測(cè)試，而kube-apiserver是etcd的緩存，其數(shù)據(jù)是弱狀態(tài)數(shù)據(jù)，相對(duì)來說啟停比較方便，方便調(diào)參。至于compaction interval的取值，一條經(jīng)驗(yàn)是：集群node越多compaction interval取值可以適當(dāng)調(diào)大。compaction本質(zhì)是一次寫動(dòng)作，在大規(guī)模集群中頻繁地執(zhí)行compaction任務(wù)會(huì)影響集群讀寫任務(wù)的延時(shí)，集群規(guī)模越大，其延時(shí)影響越明顯，在kube-apiserver請(qǐng)求耗時(shí)監(jiān)控上表現(xiàn)就是有頻繁出現(xiàn)地周期性的大毛刺。
更進(jìn)一步，如果平臺(tái)上運(yùn)行的任務(wù)有很明顯的波谷波峰特性，如每天的8:30 am~21:45 pm是業(yè)務(wù)高峰期，其他時(shí)段是業(yè)務(wù)波峰期，那么可以這樣執(zhí)行compaction任務(wù)：
在etcd層面設(shè)定compaction周期是1 hour；
在kube-apiserver層面設(shè)定comapction周期是30 minutes；
在etcd運(yùn)維平臺(tái)上啟動(dòng)一個(gè)周期性任務(wù)：當(dāng)前時(shí)間段在業(yè)務(wù)波谷期，則啟動(dòng)一個(gè)10 minutes周期的compaction任務(wù)。
其本質(zhì)就是把etcd compaction任務(wù)交給etcd運(yùn)維平臺(tái)，當(dāng)發(fā)生電商大促銷等全天無波谷的特殊長(zhǎng)周期時(shí)間段時(shí)，就可以在平臺(tái)上緊急關(guān)閉compaction任務(wù)，把compaction任務(wù)對(duì)正常的讀寫請(qǐng)求影響降低到最低。
（2）單次壓縮
即使是單次壓縮任務(wù)，etcd也是分批執(zhí)行的。因?yàn)閑tcd使用的存儲(chǔ)引擎boltdb的讀寫形式是多讀一寫：可以同時(shí)并行執(zhí)行多個(gè)讀任務(wù)，但是同時(shí)刻只能執(zhí)行一個(gè)寫任務(wù)。
為了防止單次compaction任務(wù)一直占用boltdb的讀寫鎖，每次執(zhí)行一批固定量【compaction batch limit】的磁盤KV壓縮任務(wù)后，etcd會(huì)釋放讀寫鎖sleep一段時(shí)間【compaction sleep interval】。
在v3.5之前，compaction sleep interval固定為10 ms，在v3.5之后etcd已經(jīng)把這個(gè)參數(shù)開放出來方便大規(guī)模k8s集群進(jìn)行調(diào)參。類似于batch write的interval和number，單次compaction的sleep interval和batch limit也需要不同的集群規(guī)模設(shè)定不同的參數(shù)，以保證etcd平穩(wěn)運(yùn)行和kube-apiserver的讀寫RT指標(biāo)平穩(wěn)無毛刺。
運(yùn)維平臺(tái)
無論是etcd調(diào)參，還是升級(jí)其運(yùn)行的文件系統(tǒng)，都是通過scale up的手段提升etcd的能力。還有兩種scale up手段尚未使用：
通過壓測(cè)或者在線獲取etcd運(yùn)行profile，分析etcd流程的瓶頸，然后優(yōu)化代碼流程提升性能；
通過其他手段降低單節(jié)點(diǎn)etcd數(shù)據(jù)量。
通過代碼流程優(yōu)化etcd性能，可以根據(jù)etcd使用方的人力情況進(jìn)行之，更長(zhǎng)期的工作應(yīng)該是緊跟社區(qū)，及時(shí)獲取其版本升級(jí)帶來的技術(shù)紅利。通過降低etcd數(shù)據(jù)規(guī)模來獲取etcd性能的提升則必須依賴etcd使用方自身的能力建設(shè)了。
我們?cè)鴮?duì)etcd的單節(jié)點(diǎn)RT與QPS性能與KV數(shù)據(jù)量的關(guān)系進(jìn)行過benchmark測(cè)試，得到的結(jié)論是：當(dāng)KV數(shù)據(jù)量增加時(shí)，其RT會(huì)隨之線性增加，其QPS吞吐則會(huì)指數(shù)級(jí)下降。這一步測(cè)試結(jié)果帶來的啟示之一即是：通過分析etcd中的數(shù)據(jù)組成、外部流量特征以及數(shù)據(jù)訪問特點(diǎn)，盡可能地降低單etcd節(jié)點(diǎn)的數(shù)據(jù)規(guī)模。
目前螞蟻的etcd運(yùn)維平臺(tái)具有如下數(shù)據(jù)分析功能：
longest N KV---長(zhǎng)度最長(zhǎng)的N個(gè)KV
top N KV---段時(shí)間內(nèi)訪問次數(shù)最多的N個(gè)KV
top N namespace---KV數(shù)目最多的N個(gè)namespace
verb+resoure---外部訪問的動(dòng)作和資源統(tǒng)計(jì)
連接數(shù)---每個(gè)etcd節(jié)點(diǎn)的長(zhǎng)連接數(shù)目
client來源統(tǒng)計(jì)---每個(gè)etcd節(jié)點(diǎn)的外部請(qǐng)求來源統(tǒng)計(jì)
冗余數(shù)據(jù)分析---etcd集群中近期無外部訪問的KV分布
根據(jù)數(shù)據(jù)分析結(jié)果，可以進(jìn)行如下工作：
客戶限流
負(fù)載均衡
集群拆分
冗余數(shù)據(jù)刪除
業(yè)務(wù)流量精細(xì)分析
1.集群拆分
前文提到，etcd集群性能提升的一個(gè)經(jīng)典手段就是把event數(shù)據(jù)獨(dú)立拆分到一個(gè)獨(dú)立的etcd集群，因?yàn)閑vent數(shù)據(jù)是k8s集群一中量級(jí)比較大、流動(dòng)性很強(qiáng)、訪問量非常高的數(shù)據(jù)，拆分之后可以降低etcd的數(shù)據(jù)規(guī)模并減輕etcd單節(jié)點(diǎn)的外部客戶端流量。
一些經(jīng)驗(yàn)性的、常規(guī)性的etcd拆分手段有：
pod/cm
node/svc
event,lease
這些數(shù)據(jù)拆分后，大概率能顯著提升k8s集群的RT與QPS，但是更進(jìn)一步的數(shù)據(jù)拆分工作還是有必要的。依據(jù)數(shù)據(jù)分析平臺(tái)提供的熱數(shù)據(jù)【top N KV】量級(jí)以及外部客戶訪問【verb+resource】情況，進(jìn)行精細(xì)分析后可以作為etcd集群拆分工作的依據(jù)。
2.客戶數(shù)據(jù)分析
針對(duì)客戶數(shù)據(jù)的分析分為longest N KV分析、top N namespace。
一個(gè)顯然成立的事實(shí)是：?jiǎn)未巫x寫訪問的KV數(shù)據(jù)越長(zhǎng)，則etcd響應(yīng)時(shí)間越長(zhǎng)。通過獲取客戶寫入的longest N KV數(shù)據(jù)后，可以與平臺(tái)使用方研究其對(duì)平臺(tái)的使用方法是否合理，降低業(yè)務(wù)對(duì)k8s平臺(tái)的訪問流量壓力和etcd自身的存儲(chǔ)壓力。
一般地，k8s平臺(tái)每個(gè)namespace都是分配給一個(gè)業(yè)務(wù)單獨(dú)使用。前面提到k8s可能因?yàn)閘ist-all壓力導(dǎo)致被壓垮，這些數(shù)據(jù)訪問大部分情況下都是namespace級(jí)別的list-all。從平臺(tái)獲取top N namespace后，重點(diǎn)監(jiān)控這些數(shù)據(jù)量級(jí)比較大的業(yè)務(wù)的list-all長(zhǎng)連接請(qǐng)求，在kube-apiserver層面對(duì)其采取限流措施，就可以基本上保證k8s集群不會(huì)被這些長(zhǎng)連接請(qǐng)求打垮，保證集群的高可用。
3.冗余數(shù)據(jù)分析
etcd中不僅有熱數(shù)據(jù)，還有冷數(shù)據(jù)。這些冷數(shù)據(jù)雖然不會(huì)帶來外部流量訪問壓力，但是會(huì)導(dǎo)致etcd內(nèi)存索引鎖粒度的增大，進(jìn)而導(dǎo)致每次etcd訪問RT時(shí)延增加和整體QPS的下降。
近期通過分析某大規(guī)?！?k node以上】k8s集群etcd中的冗余數(shù)據(jù)，發(fā)現(xiàn)某業(yè)務(wù)數(shù)據(jù)在etcd中存儲(chǔ)了大量數(shù)據(jù)，其數(shù)據(jù)量大卻一周內(nèi)沒有訪問過一次，與業(yè)務(wù)方詢問后獲悉：業(yè)務(wù)方把k8s集群的etcd當(dāng)做其crd數(shù)據(jù)的冷備使用。與業(yè)務(wù)方溝通后把數(shù)據(jù)從etcd中遷移掉后，內(nèi)存key數(shù)目立即下降20%左右，大部分etcd KV RT P99延時(shí)立即下降50%~60%之多。
4.負(fù)載均衡
k8s平臺(tái)運(yùn)維人員一般都有這樣一條經(jīng)驗(yàn)：etcd集群如果發(fā)生了啟停，需要盡快對(duì)所有k8s kube-apiserver進(jìn)行一次重啟，以保證kube-apiserver與etcd之間連接數(shù)的均衡。其原因有二：
kube-apiserver在啟動(dòng)時(shí)可以通過隨機(jī)方式保證其與etcd集群中某個(gè)節(jié)點(diǎn)建立連接，但etcd發(fā)生啟停后，kube-apiserver與etcd之間的連接數(shù)并無規(guī)律，導(dǎo)致每個(gè)etcd節(jié)點(diǎn)承擔(dān)的客戶端壓力不均衡；
kube-apiserver與etcd連接數(shù)均衡時(shí)，其所有讀寫請(qǐng)求有2/3概率是經(jīng)過follower轉(zhuǎn)發(fā)到leader，保證整體etcd集群負(fù)載的均衡，如果連接不均衡則集群性能無法評(píng)估。
通過etcd運(yùn)維平臺(tái)提供的每個(gè)etcd的連接負(fù)載壓力，可以實(shí)時(shí)獲取集群連接的均衡性，進(jìn)而決定運(yùn)維介入的時(shí)機(jī)，保證etcd集群整體的健康度。
其實(shí)最新的etcd v3.5版本已經(jīng)提供了etcd客戶端和etcd節(jié)點(diǎn)之間的自動(dòng)負(fù)載均衡功能，但這個(gè)版本才發(fā)布沒多久，目前最新版本的k8s尚未支持這個(gè)版本，可以及時(shí)跟進(jìn)k8s社區(qū)對(duì)這個(gè)版本的支持進(jìn)度以及時(shí)獲取這一技術(shù)紅利，減輕平臺(tái)運(yùn)維壓力。
未來之路
通過一年多的包括kube-apiserver和etcd在內(nèi)的k8s高可用建設(shè)，目前k8s集群已經(jīng)穩(wěn)定下來，一個(gè)顯著的特征是半年內(nèi)k8s集群沒有發(fā)生過一次P級(jí)故障，但其高可用建設(shè)工作不可能停歇---作為全球k8s規(guī)?；ㄔO(shè)領(lǐng)導(dǎo)力象限的螞蟻集團(tuán)正在挑戰(zhàn)node量級(jí)更大規(guī)模的k8s集群，這一工作將推動(dòng)etcd集群建設(shè)能力的進(jìn)一步提升。
前面提到的很多etcd能力提升工作都是圍繞其scale up能力提升展開的，這方面的能力還需要更深層次的加強(qiáng)：
etcd最新feature地及時(shí)跟進(jìn)，及時(shí)把社區(qū)技術(shù)進(jìn)步帶來的開源價(jià)值轉(zhuǎn)換為螞蟻k8s平臺(tái)上的客戶價(jià)值
及時(shí)跟進(jìn)阿里集團(tuán)在etcd compact算法優(yōu)化、etcd單節(jié)點(diǎn)多multiboltdb的架構(gòu)優(yōu)化以及kube-apiserver的服務(wù)端數(shù)據(jù)壓縮等etcd優(yōu)化工作【見參考文檔1】，對(duì)兄弟團(tuán)隊(duì)的工作進(jìn)行借鑒和反饋，協(xié)同作戰(zhàn)共同提升
跟進(jìn)螞蟻?zhàn)陨韐8s平臺(tái)上etcd的性能瓶頸，提出我們自己的解決方案，在提升我們平臺(tái)的技術(shù)價(jià)值的同時(shí)反哺開源
除了關(guān)注etcd單節(jié)點(diǎn)性能的提升，我們下一步的工作將圍繞分布式etcd集群這一scale out方向展開。前面提到的etcd集群拆分工作，其本質(zhì)就是通過分布式etcd集群的方式提升etcd集群整體的性能：該集群的數(shù)據(jù)劃分方式是依據(jù)k8s業(yè)務(wù)層面的數(shù)據(jù)類型進(jìn)行的。
該工作可以進(jìn)一步拓展為：不區(qū)分KV的業(yè)務(wù)意義，從單純的KV層面對(duì)把數(shù)據(jù)根據(jù)某種路由方式把數(shù)據(jù)寫入后端多etcd子集群，實(shí)現(xiàn)etcd集群整體的冷熱負(fù)載均衡。
分布式etcd集群的實(shí)現(xiàn)有兩種方式：proxyless和proxy based：proxy based etcd分布式集群的請(qǐng)求鏈路是client[kube-apiserver]->proxy->etcd server，而謂的proxyless分布式etcd集群的請(qǐng)求鏈路是client[kube-apiserver]->etcd server。
proxy based etcd分布式集群的好處是可以直接基于etcd社區(qū)提供的etcd proxy進(jìn)行開發(fā)，后期亦可回饋社區(qū)，實(shí)現(xiàn)其開源價(jià)值、技術(shù)價(jià)值和客戶價(jià)值的統(tǒng)一。但經(jīng)過測(cè)試：按照測(cè)試發(fā)現(xiàn)，kube-apiserver經(jīng)過proxy向etcd發(fā)起讀寫請(qǐng)求后RT和QPS降低20%~25%。所以下一步的工作重點(diǎn)是開發(fā)proxyless etcd集群。
目前的拆分后的etcd分布式集群本質(zhì)或者67%的概率是proxy based分布式集群：kube-apiserver的請(qǐng)求大概有三分之二的概率是經(jīng)過follower轉(zhuǎn)發(fā)到leader，此處的follower本質(zhì)就是一個(gè)proxy。如果kube-apiserver所有請(qǐng)求都是與leader直連后被處理，理論上當(dāng)前的k8s集群的RT和QPS就有67%*20%≈13.4%的性能收益。
proxyless etcd分布式集群的缺點(diǎn)是如果把proxy的路由邏輯放入kube-apiserver中，會(huì)造成kube-apiserver版本升級(jí)成本增加，但相比于至少20%【將來通過etcd集群規(guī)模擴(kuò)充這個(gè)收益肯定會(huì)更大】的收益，這個(gè)僅僅影響了kube-apiserver單個(gè)組件的版本升級(jí)的成本是值得的。
除了multiple etcd clusters的思路外，數(shù)據(jù)中間件團(tuán)隊(duì)基于OBKV之上實(shí)現(xiàn)了etcd V3 API，算是另一種比較好的技術(shù)路線，頗類似于本文開頭黃東旭提到的在tikv之上etcd V3 API接口層，可以稱之為類etcd系統(tǒng)，目前相關(guān)工作也在推進(jìn)中。
總之，隨著我們k8s規(guī)模越來越大，螞蟻集團(tuán)etcd整體工作的重要性就日益凸顯。如果說前期etcd的高可用建設(shè)之路是在泥濘小道上蹣跚前行，那么以后的etcd高可用建設(shè)之路必是康莊大道---道路越走越寬廣！
