容器云平臺API Server卡頓問題排查
58云計算平臺是58集團架構(gòu)線基于Kubernetes + Docker技術(shù)為集團內(nèi)部服務(wù)開發(fā)的一套業(yè)務(wù)實例管理平臺，它具有簡單，輕量的特點及高效利用物理資源，更快的部署和統(tǒng)一規(guī)范的標(biāo)準(zhǔn)化運行環(huán)境，通過云平臺，使得服務(wù)標(biāo)準(zhǔn)化，上線流程規(guī)范化，資源利用合理化。然而云平臺的建設(shè)過程不是一帆風(fēng)順，也不乏出現(xiàn)一些問題挑戰(zhàn)，本文就針對云平臺現(xiàn)實中遇到的一個問題和大家分享。
1、關(guān)于問題
1.1 問題概述
近期，很多業(yè)務(wù)同事反饋使用云平臺上線存在容器部署慢，平臺反應(yīng)慢的問題。通過詳細的問題排查定位后，最終問題得以解決。
1.2 Kubernetes基本知識
私有云平臺通過Kubernetes對容器進行編排。Kubernetes整體架構(gòu)如下圖所示：
其中幾個主要的模塊的功能簡要描述如下：
- etcd：用于Kubernetes的后端存儲。
- Pod：Kubernetes最基本的操作單元，包含一個或多個緊密相關(guān)的容器。
- Replication Controller：副本控制器，用來保證Deployment或者RC中副本的數(shù)量。
- Scheduler：Kubernetes的調(diào)度器，Scheduler監(jiān)聽API Server，當(dāng)需要創(chuàng)建新的Pod時Scheduler負責(zé)選擇該Pod與哪個Node進行綁定。
- Kubelet：每個Node節(jié)點上都會有一個Kubelet負責(zé)Master下發(fā)到該節(jié)點的具體任務(wù)，管理該節(jié)點上的Pod和容器。
- API Server：對于整個Kubernetes集群而言，API Server是通過暴露Kubernetes API的方式提供給內(nèi)部組件或者外部程序調(diào)用去完成對Kubernetes的操作。各個組件之間也是通過API Server作為橋梁進行間接通信，這種方式做到各個組件間充分解耦。
業(yè)務(wù)同事操作管理平臺發(fā)出創(chuàng)建集群請求到集群創(chuàng)建完成的整個流程如下：
- 業(yè)務(wù)同學(xué)操作管理平臺進行升級操作，管理平臺通過http方式向API Server發(fā)出請求。
- API Server處理和解析請求參數(shù)，將待創(chuàng)建的Pod信息通過API Server存儲到etcd。
- Scheduler通過API Server的watch機制，查看到新的Pod，嘗試為Pod綁定Node。
- 經(jīng)過預(yù)選篩除不合適節(jié)點及從待選節(jié)點中根據(jù)一定規(guī)則選出最適合的節(jié)點。
- 對選中的節(jié)點及Pod進行binding操作，將相關(guān)的結(jié)果通過API Server存儲到etcd。
- 對應(yīng)Node的Kubelet進程調(diào)用容器運行時創(chuàng)建容器。
2. 定位問題
2.1 問題排查
從1.2可以看到，API Server在創(chuàng)建Pod過程中起到非常關(guān)鍵的中間橋梁作用，解析外部請求及讀寫etcd。因此決定首先從API Server進程所在宿主機的各項性能指標(biāo)及日志方面進行排查，看是否有所發(fā)現(xiàn)。
目前線上環(huán)境有3臺主機運行API Server，以達到流量負載均衡的目的，異常時間段網(wǎng)卡eth2入流量如下圖所示：
由3臺API Server主機的監(jiān)控數(shù)據(jù)，發(fā)現(xiàn)服務(wù)器A的網(wǎng)卡入流量遠高于另外兩臺，說明絕大部分請求發(fā)送到了服務(wù)器A。
通過對比三臺服務(wù)器API Server 的CPU利用率，發(fā)現(xiàn)服務(wù)器A的API Server進程CPU使用率一直保持在2000%(20核)上下波動，而另外兩臺服務(wù)器的API Server的CPU利用率沒有超過100%(1核)。進一步證實了A的API Server進程處理了絕大多數(shù)的請求。
查看A服務(wù)器的API Server的相關(guān)log，發(fā)現(xiàn)正在大量輸出如下的日志：
這個日志顯示有大量請求通過API Server到etcd查詢Pod的狀態(tài)。
對于Kubernetes后端的存儲目前采用5個etcd節(jié)點組成etcd集群。登陸其中一個節(jié)點(E1)，發(fā)現(xiàn)對E1節(jié)點執(zhí)行etcd操作命令，比如命令：“etcdctl ls /registry/pods/default”，命令執(zhí)行也會經(jīng)常超時。如果你想和更多Kubernetes技術(shù)專家交流，可以加我微信liyingjiese，備注『加群』。群里每周都有全球各大公司的***實踐以及行業(yè)***動態(tài)。
同時對比5臺etcd節(jié)點的流量，發(fā)現(xiàn)有一個節(jié)點網(wǎng)卡入流量遠高于其他四個節(jié)點，該節(jié)點(E1)的etcd進程的CPU利用率在100%左右，明顯高于剩余的4個節(jié)點CPU利用率。查看節(jié)點E1的etcd進程日志，經(jīng)?？吹饺缦聢箦e：
可以推斷節(jié)點E1的負載非常高，節(jié)點間同步心跳都已經(jīng)超時，無法正常的響應(yīng)外部的請求了。
2.2 問題分析
經(jīng)過上述排查，主要集中在這兩個問題上：
2.2.1負載均衡策略失效
首先可以看到對Kubernetes集群的操作請求大部分都落在某個API Server上，導(dǎo)致其中一個API Server負載很高，那么有可能負載均衡策略有些問題。那就先看看當(dāng)前負載均衡策略是如何的。
當(dāng)前我們租賃的是騰訊的機房，負載均衡策略采用的是TGW(Tencent Gateway)系統(tǒng)所自帶支持的負載均衡策略。騰訊云上有關(guān)介紹如下：
TGW負載均衡策略保證請求的分攤轉(zhuǎn)發(fā)，也會自動對resource server(RS)進行存活檢測，每分鐘會有心跳包去對接入TGW的IP Port進行探測。
關(guān)于TGW相關(guān)配置具體如下：
- 做域名解析：我們對需要訪問到API Server的物理機都做了本地DNS，將一個固定域名(D)解析到一個特定的VIP(V)，而該VIP就是TGW對外提供的虛擬IP。
- 配置TGW服務(wù)的RS列表：將三臺API Server節(jié)點對應(yīng)的物理IP加入到RS列表。
正常情況下，所有需要訪問API Server的請求都先本地域名解析到虛擬IP V，將請求的數(shù)據(jù)包都發(fā)送到V，V相當(dāng)于是TGW對外的接入點，再通過TGW內(nèi)部負載均衡策略將請求數(shù)據(jù)包進行目的網(wǎng)絡(luò)地址轉(zhuǎn)換(DNAT)，分發(fā)到不同的RS上。
經(jīng)排查，TGW的監(jiān)控檢測模塊定期向所有的RS發(fā)送心跳包，但是TGW監(jiān)控檢測模塊只能收到A服務(wù)器的回包，因此TGW認為只有A節(jié)點是存活狀態(tài)，所有的請求數(shù)據(jù)包最終就由TGW轉(zhuǎn)發(fā)到A服務(wù)器上了，這就是負載均衡策略失效的根本原因。
這里還有一個現(xiàn)象是為什么etcd集群中只有一個節(jié)點的負載很高呢?
五個節(jié)點的etcd集群中只有一個節(jié)點負載很高，其他正常，通過查看A服務(wù)器的API Server的log，可以看到的大量的讀請求都固定發(fā)送到了同一個etcd節(jié)點。
對于這個現(xiàn)象，可以看下API Server訪問后端存儲的源碼，目前線上Kubernetes基于v1.7.12的源碼編譯運行，API Server訪問etcd是在內(nèi)部初始化一個etcd client端，然后通過etcd client端發(fā)送請求到etcd server端。etcd client端有v2和v3兩個版本。線上API Server使用的是v2版本客戶端。主要代碼如下：
- //初始化etcd工作
- func New(cfg Config) (Client, error) {
- c := &httpClusterClient{//返回一個http類型的client
- clientFactory: newHTTPClientFactory(cfg.transport(), cfg.checkRedirect(), cfg.HeaderTimeoutPerRequest),
- rand: rand.New(rand.NewSource(int64(time.Now().Nanosecond()))),//傳入一個當(dāng)前時間的隨機種子
- selectionMode: cfg.SelectionMode,
- }
- if err := c.SetEndpoints(cfg.Endpoints); err != nil {
- return nil, err
- }
- return c, nil
- }
- //對etcd列表進行打亂
- func (c *httpClusterClient) SetEndpoints(eps []string) error {
- ...
- neps, err := c.parseEndpoints(eps)
- c.Lock()
- defer c.Unlock()
- c.endpoints = shuffleEndpoints(c.rand, neps)//打亂etcd列表
- c.pinned = 0
- ...
- return nil
- }
- func shuffleEndpoints(r *rand.Rand, eps []url.URL) []url.URL {
- p := r.Perm(len(eps))//rank庫的Perm方法可以返回[0,n)之間的隨機亂序數(shù)組
- neps := make([]url.URL, len(eps))
- for i, k := range p {
- neps[i] = eps[k]
- }
- return neps
- }
可以看到在初始化etcd客戶端時候會傳入一個當(dāng)前時間的隨機種子去打亂所有Endpoints(etcd節(jié)點)的順序。
對于etcd的操作都是通過API Server內(nèi)部的etcd客戶端發(fā)送http請求到etcd Server端，最主要是調(diào)用如下方法：
- func (c *httpClusterClient) Do(ctx context.Context, act httpAction) (*http.Response, []byte, error) {
- ...
- for i := pinned; i < leps+pinned; i++ {
- k := i % leps
- hc := c.clientFactory(eps[k])
- resp, body, err = hc.Do(ctx, action)
- ...
- if resp.StatusCode/100 == 5 {
- switch resp.StatusCode {
- case http.StatusInternalServerError, http.StatusServiceUnavailable:
- cerr.Errors = ...
- default:
- cerr.Errors = ...
- }
- ...
- continue
- }
- if k != pinned {
- c.Lock()
- c.pinned = k
- c.Unlock()
- }
- return resp, body, nil
- }
- return nil, nil, cerr
- }
該方法表明每次請求時候，會從pinned節(jié)點開始嘗試發(fā)送請求，如果發(fā)送請求異常，則按照初始化時候打亂順序的下一個節(jié)點(pinned++)開始嘗試發(fā)送數(shù)據(jù)。如此看來，如果API Server使用了某個endpoint發(fā)送數(shù)據(jù)，除非用壞了這個節(jié)點，否則會一直使用該節(jié)點(pinned)發(fā)送數(shù)據(jù)。這就說明了，沒有異常情況下，一個API Server就對應(yīng)往一個固定的etcd發(fā)送請求。
對于etcd集群，如果是寫請求的話，follower節(jié)點會把請求先轉(zhuǎn)發(fā)給leader節(jié)點處理，然后leader再轉(zhuǎn)發(fā)給follower同步。那么5個節(jié)點CPU負載不會這么不均衡，但是根據(jù)2.1排查API Server日志看到這里是大量的讀請求，相對于寫請求，讀請求是所有follower節(jié)點都能對外提供的。也就是大量請求由于負載均衡策略失效都轉(zhuǎn)發(fā)到A服務(wù)器，A再把查詢請求都打到其中一個固定的etcd，導(dǎo)致該節(jié)點忙于處理etcd查詢請求，負載就會飆高。
總的來說，TGW做負載均衡時候，由于心跳檢測模塊和其中兩個Resource Server間連接不通，導(dǎo)致誤將所有請求都轉(zhuǎn)發(fā)到其中一個API Server，而一個特定的API Server使用v2版本etcd客戶端就只會往一個固定的etcd服務(wù)端發(fā)請求，這樣整個負載均衡策略就失效了。
2.2.2 etcd存取數(shù)據(jù)緩慢
namespace未做劃分：
從2.1中查看API Server 的日志可以看出，很多get請求Pod對象信息，比如：“Get /api/v1/namespaces/default/pods?...” 這些都是從default namespace下獲取Pod信息，這就說明線上并沒有對Pod的namespace做劃分。
Kubernetes是通過namespace對容器資源進行隔離，默認情況下，如果未指定namespace的話，創(chuàng)建的容器都被劃分到default namespace下，因為這個原因也給后面往etcd中存儲容器元數(shù)據(jù)信息也留下了坑。所有的Kuberentes的元數(shù)據(jù)都存儲在etcd的/registry目錄下，整體如下圖所示：
Kubernetes中Pod的信息存儲在/registry/pods/#{命名空間}/#{具體實例名}的目錄結(jié)構(gòu)中，正因為如果不指定namespace的話，就會存儲到default的namespace中，也就是/registry/pods/default目錄下保存了線上全部Pod對象信息。
也就是說大量get請求Pod對象信息，由于未做namespace劃分,每次都會去訪問default子目錄，每次請求相當(dāng)于都要做全局搜索，隨著集群的增多，Pod不斷的存入到該子目錄中，搜索性能也會變得越來越差。
查詢結(jié)果未加入緩存：
從2.1中查看API Server 的日志看到很多Get/List操作，那么可以仔細看看相關(guān)方法的執(zhí)行流程，下面是List方法執(zhí)行過程中調(diào)用的中間函數(shù)：
- f
- unc (c *Cacher) GetToList(ctx context.Context, key string, resourceVersion string, pred SelectionPredicate, listObj runtime.Object) error {
- if resourceVersion == "" {
- return c.storage.GetToList(ctx, key, resourceVersion, pred, listObj)//直接查詢etcd
- }
- listRV, err := ParseListResourceVersion(resourceVersion)
- ...
- obj, exists, readResourceVersion, err := c.watchCache.WaitUntilFreshAndGet(listRV, key, trace)//從緩存中獲取
- ...
- return nil
- }
可以看到，GetToList方法中傳入的有個resourceVersion 參數(shù)，如果設(shè)置了就會從緩存中獲取，如果不設(shè)置就會去etcd中查詢。這個也是一個關(guān)鍵點，有關(guān)resourceVersion 的相關(guān)使用如下：
- 不設(shè)置：通過API Server從etcd讀取。
- 設(shè)置成0：從API Server的cache讀取，減輕API Server和etcd壓力。例如Kubelet經(jīng)常通過此方法Get Node對象，Kubernetes Infomer***次啟動時List也通過此方法獲得對象。
- 大于0：讀取對象指定版本。
線上管理平臺通過http接口去查詢Pod信息時候是沒有設(shè)置resourceVersion，所以每次通過Get/List方法獲取資源時候都會查詢etcd，如此一來經(jīng)常大量高頻率的查詢etcd會導(dǎo)致其壓力較大，開啟緩存策略不僅可以減輕訪問etcd壓力而且還可以加快查詢速度。
總結(jié)以上兩點：所有的請求都發(fā)往一個固定的API Server，導(dǎo)致該API Server節(jié)點負載較高，同時該API Server又會將查詢請求固定的發(fā)給某個etcd節(jié)點，然而請求結(jié)果并沒有在API Server端做緩存，每次都會直接查詢etcd，在從etcd中獲取Pod信息又是從default這個大的子目錄中全局搜索，每次請求都比較費時，這樣導(dǎo)致某一個固定的etcd一直處理大量的費時的請求，最終將該etcd資源耗盡，負載過高，因而查詢結(jié)果不能及時返回給API Server，導(dǎo)致創(chuàng)建Pod時候拿不到相關(guān)的信息，Pod創(chuàng)建工作無法進行，所以最終表象是集群部署長時間卡頓。
3、解決方案
切換負載均衡方案：臨時切換為DNS輪詢方式，保證每個API Server節(jié)點的流量均衡。同時跟進TGW對于某些網(wǎng)段的RS和TGW服務(wù)不能探測心跳及后續(xù)改進。
將Kubernetes中Pod按多個namespace劃分，目前線上所有的Pod都劃分到默認的default的namespace下，每次讀取Pod信息都是從etcd檢索整個namespace，比較損耗etcd性能，目前已經(jīng)將Pod的namespace進行細分，加快了讀取Pod信息速度同時減少了etcd性能損耗。
etcd v3版本客戶端會對Endpoints定期打亂，后續(xù)我們會升級到v3版本，這樣同一個API Server的請求就不會一直落到某一個etcd上，這樣即使負載均衡策略失效也能做到對etcd請求的分攤。
查詢Kubernetes資源信息時帶入resourceVersion開啟緩存機制，減輕對etcd的訪問壓力。
4、總結(jié)
從API Server卡頓問題排查過程來看，潛在的問題是長期存在的，只是積累到一定量后，問題的影響才會凸顯。這就要求我們平時對Kubernetes相關(guān)組件的性能指標(biāo)，日志等要保持時刻敏感，要對Kubernetes各種默認策略及參數(shù)非常熟悉，同時對于重要功能模塊做到源碼層面了解，這樣才能規(guī)避潛在風(fēng)險和出問題后能快速定位，保證生產(chǎn)環(huán)境穩(wěn)定健康的運行。
