容器云平臺運維最佳實踐

1、 容器云平臺運維最佳實踐 定位問題，是在分析問題后，我們可以結(jié)合各種日志、監(jiān)控告警等平臺提供的功能來排除干擾項，找到問題的誘發(fā)根因。問題背景：容器平臺上線一年多后，總有很少部分租戶稱他們的某個業(yè)務(wù)部署在Kubernetes容器平臺后經(jīng)常會重啟，也很少部分租戶稱某個業(yè)務(wù)在運行一段時間時會產(chǎn)生大量的CLOSE-WAIT，還有租戶反饋說某個業(yè)務(wù)跑著就會hang住。剛開始我們都會讓業(yè)務(wù)開發(fā)者先自己找問題，因為這些租戶反映的只是偶偶發(fā)生，大多數(shù)租戶沒有反映類似問題，我們會理所當(dāng)然的認為是租戶業(yè)務(wù)自身問題，而非平臺問題。當(dāng)然大多數(shù)情況下，還是租戶業(yè)務(wù)本身程序沒有寫好，或者健康檢查配置不當(dāng)?shù)纫?。本文繼續(xù)結(jié)

2、合案例講解如何定位容器云平臺重大問題。1 排除干擾項分析完了問題，一般會根據(jù)經(jīng)驗先從比較簡單的可能產(chǎn)生的影響因素開始排除干擾選項，這樣我們大概就會有一個比較接近問題根因的方向。比如上面三個問題中的其中一個 容器內(nèi)出現(xiàn)大量處于CLOSE_WAIT狀態(tài)的TCP鏈接：“CLOSE-WAIT”有很多原因引起，有可能是服務(wù)端代碼處理TCP揮手不合理引起，比如忘記了close相應(yīng)的socket連接，那么自然不會發(fā)出FIN包；還比如出現(xiàn)死循環(huán)之類的問題，導(dǎo)致close最后沒有被調(diào)用執(zhí)行；還有可能是服務(wù)端程序響應(yīng)過慢，或者存在耗時邏輯，導(dǎo)致close延后；也可能是accept的backlog設(shè)置的太大，導(dǎo)致服

3、務(wù)端來不及消費的情況，引起多余的請求還在隊列里就被對方關(guān)閉了。還有可能是內(nèi)核參數(shù)配置沒有做優(yōu)化處理，比如調(diào)整“tcp_keepalive_time” / “tcp_keepalive_intvl” / “tcp_keepalive_probes”等。林林總總，但經(jīng)過我們排查后，以上的可能影響點都不是，所以排除上述這些干擾選項。在排查業(yè)務(wù)問題的時候，我們還要結(jié)合“業(yè)務(wù)方”與“平臺方”的各自對自身代碼熟悉的優(yōu)勢，發(fā)揮出凝聚力，一起來排查?！皹I(yè)務(wù)方”從如下幾個方向進行了代碼方面的排查：1、多次檢查TCP四次揮手代碼邏輯；2、檢查 springboot的相關(guān)配置是否恰當(dāng)；3、由于連接數(shù)過多，也排查了t

4、omcat線程池相關(guān)代碼；4、修改ActiveMQ連接池的配置；5、采用jstack、jmap查看應(yīng)用的線程堆棧，確定程序沒有死鎖，只看到少量線程在 block和wait狀態(tài)；6、采用jstack-gcutil查看java垃圾回收時間，因為其可能會引起垃圾回收異常等；以上發(fā)現(xiàn)都是正常的，無果。“平臺方”嘗試過以下排查：1、修改Kubernetes node主機的內(nèi)核相關(guān)配置（比如：tcp keepalived相關(guān)參數(shù)，ulimit限制數(shù)等）；2、檢查Kubernetes Ingress入口Nginx的配置（比如：Kubernetes Nginx的超時配置與業(yè)務(wù)自身Nginx的超時時間減少些，比

5、如900秒；改用NodePort模式不經(jīng)過Nginx代理等），發(fā)現(xiàn)同樣有問題，這個就排除采用 Nginx代理引起，也就排除了Nginx參數(shù)配置問題；3、排查docker分區(qū)的文件系統(tǒng)，排除容器底層導(dǎo)致；4、查看dockerd日志和系統(tǒng)日志；5、還有各種其他可能的方面都嘗試過等等；以上的可能影響點都不是，所以排除上述這些干擾選項。到此為止，雖然都沒有找到一點頭緒，但我們至少排除了很多干擾項，這個也是接近根因的必經(jīng)之路。當(dāng)時在分析問題的過程中，實然閃現(xiàn)在我腦海中，會不會是程序本身hang住了，才引起了CLOSE-WAIT出現(xiàn)？這個問題其實是需要界定的，后面會講到。2 日志分析日志平臺是日志分析的主

6、要工具，它也是收集業(yè)務(wù)容器日志及系統(tǒng)日志的輸入口，業(yè)務(wù)日志的展示與統(tǒng)計、分析的窗口。容器的日志都需要統(tǒng)一輸出到日志平臺，有以下幾點考慮：因為容器的臨時性，容器重啟或銷毀后就會丟失日志，所以需要日志平臺的持久存儲。需要按日志存儲時間、日志量大小、日志錯誤類型、業(yè)務(wù)訪問率、客戶端訪問方式等等來搜索、分析。需要以圖形化展示各種統(tǒng)計效果，方便觀察整體表現(xiàn)形為，抓住容易被忽視的抽像部分，也就是有大局觀。2.1 日志平臺架構(gòu)下面我稍微簡要介紹一些日志平臺使用到的相關(guān)組件的概念，詳情請參考相關(guān)文獻。早期一般使用ELK架構(gòu)模式，即由ElasticSearch、Logstash和Kiabana三個開源工具組成：

7、ElasticSearch是一個基于Lucene的開源分布式搜索引擎。它的特點有很多，比如分布式，零配置，自動發(fā)現(xiàn)，索引自動分片，索引副本機制，RESTful風(fēng)格接口，多數(shù)據(jù)源，自動搜索負載等等。它提供了一個分布式、多用戶能力的全文搜索引擎，基于RESTful web接口。ElasticSearch是用Java開發(fā)的，并作為Apache許可條款下的開放源碼發(fā)布。設(shè)計用于云計算中，能夠達到實時搜索，穩(wěn)定，可靠，快速，安裝使用方便。在ElasticSearch中，所有節(jié)點的數(shù)據(jù)是均等的。Logstash是一個完全開源的工具，它可以對你的日志進行收集、過濾、分析，支持大量的數(shù)據(jù)獲取方法，并將其存儲以

8、實現(xiàn)搜索、統(tǒng)計等功能。它帶有一個web界面，可以搜索和展示所有日志。一般工作方式為C/S架構(gòu)，Client端安裝在需要收集日志的主機上，Server端負責(zé)將收到的各節(jié)點日志進行過濾、修改等。Kibana是一個基于瀏覽器頁面的 ElasticSearch前端展示工具，也是一個開源和免費的工具，Kibana可以為Logstash和ElasticSearch提供的日志分析友好的Web界面，可以幫助您匯總、分析和搜索重要數(shù)據(jù)日志。最近一般我們采用EFK架構(gòu)模式，即采用fluentd或者fluent bit來采集容器日志（包括標(biāo)準控制臺日志及用戶自定義業(yè)務(wù)日志）代替Logstash，其他工具保持不變。F

9、luentd是一個開源的通用日志采集和分發(fā)系統(tǒng)，可以從多個數(shù)據(jù)源采集日志，并將日志過濾和加工后分發(fā)到多種存儲和處理系統(tǒng)。Fluentd處于日志采集流程的中間層。它可以從Apache/Nginx等廣泛應(yīng)用的系統(tǒng)、數(shù)據(jù)庫、自定義系統(tǒng)中采集日志，數(shù)據(jù)進入Fluentd后可根據(jù)配置進行過濾、緩存，最終分發(fā)到各種后端系統(tǒng)中。這些后端系統(tǒng)包括告警系統(tǒng)（Nagios）、分析系統(tǒng)（MongoDB、MySQL、Hadoop、ElasticSearch）、存儲系統(tǒng)（Amazon S3）等。也就是說，F(xiàn)luentd就是把通常的日志采集-分發(fā)-存儲流程提煉出來，用戶只需要考慮業(yè)務(wù)數(shù)據(jù)，至于數(shù)據(jù)的傳輸、容錯等過程細節(jié)都

10、交給Fluentd來做。fluent bit是一個C實現(xiàn)的輕量級多平臺開源日志收集工具，相比 fluentd 資源占用要小，相對的插件數(shù)量上要比fluentd要少的多，功能上也少一些。它允許從不同的源收集數(shù)據(jù)并發(fā)送到多個目的地。完全兼容Docker和Kubernetes生態(tài)環(huán)境。在查詢搜索方面，主流的有ElasticSearch，目前也有很多公司開始使用ClickHouse。ClickHouse是近年來備受關(guān)注的開源列式數(shù)據(jù)庫（columnar DBMS），主要用于數(shù)據(jù)分析（OLAP）領(lǐng)域。目前國內(nèi)社區(qū)火熱，各個大廠紛紛跟進大規(guī)模使用。傳統(tǒng)數(shù)據(jù)庫在數(shù)據(jù)大小比較小，索引大小適合內(nèi)存，數(shù)據(jù)緩存命中

11、率足夠高的情形下能正常提供服務(wù)。但這種理想情況最終會隨著業(yè)務(wù)的增長而走到盡頭，使得查詢會變得越來越慢。我們可能會通過增加更多的內(nèi)存，訂購更快的磁盤等縱向擴展的方式來解決問題。如果我們的需求是解決怎樣快速查詢出結(jié)果，那么這就是ClickHouse的主場了。它適用于讀多于寫；大寬表，讀大量行但是少量列，結(jié)果集較小；數(shù)據(jù)批量寫入，且數(shù)據(jù)不更新或少更新；無需事務(wù)，數(shù)據(jù)一致性要求低；靈活多變，不適合預(yù)先建模等場景。在我們的生產(chǎn)環(huán)境中，一般 7 天內(nèi)的熱日志從ElasticSearch中查詢，7 天外的冷日志從ClickHouse中查詢，因為隨著天數(shù)的增加，數(shù)據(jù)量越來越多，ClickHouse作用越來越明

12、顯。攜程團隊曾對ClickHouse與ElasticSearch做過一次比較，他們得出了如下結(jié)論：ClickHouse寫入吞吐量大，單服務(wù)器日志寫入量在50MB到200MB/s，每秒寫入超過60W記錄數(shù)，是ElasticSearch的五倍以上。在ElasticSearch中比較常見的寫Rejected導(dǎo)致數(shù)據(jù)丟失、寫入延遲等問題，在ClickHouse中不容易發(fā)生。查詢速度快，官方宣稱數(shù)據(jù)在pagecache中，單服務(wù)器查詢速率大約在2-30GB/s；沒在pagecache的情況下，查詢速度取決于磁盤的讀取速率和數(shù)據(jù)的壓縮率。經(jīng)測試ClickHouse的查詢速度比ElasticSearch快5

13、-30倍以上。ClickHouse比ElasticSearch服務(wù)器成本更低。一方面ClickHouse的數(shù)據(jù)壓縮比比ElasticSearch高，相同數(shù)據(jù)占用的磁盤空間只有ElasticSearch的1/3到1/30，節(jié)省了磁盤空間的同時，也能有效的減少磁盤IO，這也是ClickHouse查詢效率更高的原因之一；另一方面ClickHouse比ElasticSearch占用更少的內(nèi)存，消耗更少的CPU資源。我們預(yù)估用ClickHouse處理日志可以將服務(wù)器成本降低一半。相比ElasticSearch，ClickHouse穩(wěn)定性更高，運維成本更低。ElasticSearch中不同的Group負載

14、不均衡，有的Group負載高，會導(dǎo)致寫Rejected等問題，需要人工遷移索引；在ClickHouse中通過集群和Shard策略，采用輪詢寫的方法，可以讓數(shù)據(jù)比較均衡的分布到所有節(jié)點。ElasticSearch中一個大查詢可能導(dǎo)致OOM的問題；ClickHouse通過預(yù)設(shè)的查詢限制，會查詢失敗，不影響整體的穩(wěn)定性。ElasticSearch需要進行冷熱數(shù)據(jù)分離，每天200T的數(shù)據(jù)搬遷，稍有不慎就會導(dǎo)致搬遷過程發(fā)生問題，一旦搬遷失敗，熱節(jié)點可能很快就會被撐爆，導(dǎo)致一大堆人工維護恢復(fù)的工作；ClickHouse按天分partition，一般不需要考慮冷熱分離，特殊場景用戶確實需要冷熱分離的，數(shù)據(jù)量

15、也會小很多，ClickHouse自帶的冷熱分離機制就可以很好的解決。ClickHouse采用SQL 語法，比ElasticSearch的DSL更加簡單，學(xué)習(xí)成本更低。2.2 業(yè)務(wù)日志分析幾乎每個容器平臺團隊，都會構(gòu)建自己的日志平臺，這樣就方便在系統(tǒng)或業(yè)務(wù)出問題的時候進行排查。一些簡單的問題，我們通過業(yè)務(wù)輸出的日志就能夠定位到問題，但很多情況下，一些棘手的問題，都需要結(jié)合日志統(tǒng)計分析，從全局觀入手，還要我們善于觀察細節(jié)，才好定位出問題點。我們在定位上述三個問題的時候，也查看了業(yè)務(wù)日志，但剛開始沒有發(fā)現(xiàn)什么可疑點，后面我們進行“統(tǒng)計分析”時發(fā)現(xiàn)，我們注意到幾點：一個非常關(guān)鍵的信息，就是業(yè)務(wù)的單條日

16、志太長了，目測單行有上萬個字符（當(dāng)然租戶日志在生產(chǎn)中輸出這么多日志，本身就很不科學(xué)，正是這種不科學(xué)，才給了我們排查這個問題的機會！）。另外一個就是，1秒鐘輸出了大量的日志，一條接一條，很快。這兩個點，引起了我們的注意。我們在和業(yè)務(wù)方排查問題時，我們又注意到一個問題，就是在K8S平臺的該業(yè)務(wù)容器對應(yīng)的控制臺突然看不到業(yè)務(wù)日志輸出了，會不會程序掛了？這個信息很關(guān)鍵，因為這個是一瞬間的事情，由于業(yè)務(wù)應(yīng)用設(shè)置了健康檢查，一旦檢查失敗超過設(shè)定次數(shù)，就會自動重啟，然后日志重新正常輸出，丟失了現(xiàn)場，或者沒有注意到這些關(guān)鍵細節(jié)就不好排查了。這時執(zhí)行“ss-ant”查看發(fā)現(xiàn)“CLOSE-WAIT”在不斷的增加，

17、而此前在日志正常輸出時，只會產(chǎn)生少量“CLOSE-WAIT”，所以我斷定是業(yè)務(wù)Hang引起了CLOSE-WAIT的增加。我連續(xù)三次敲下統(tǒng)計命令，從圖中也可以看出程序掛了后，其CLOSE-WAIT在不斷的增加，從166-174-176-178，增長很快。所以我們讓租戶把日志輸出關(guān)閉后，重新壓測兩天后，并沒有產(chǎn)生“CLOSE-WAIT”，到這里我們基本斷定了和日志輸出有關(guān)了。也就是說整個過程是：先有日志過長，導(dǎo)致業(yè)務(wù)掛死（不過是單條日志過長引起，還是日志輸出過快引起，這個需要后面進一步構(gòu)建模擬代碼來判斷），最終出現(xiàn)大量CLOSE-WAIT，業(yè)務(wù)掛了，健康檢查失敗了，容器自然會重啟，突然發(fā)現(xiàn)，這三個

18、問題有了關(guān)聯(lián)了！為了證實猜想，我們就需要在之后構(gòu)建測試程序，來模擬業(yè)務(wù)程序并復(fù)現(xiàn)bug。3 監(jiān)控與告警監(jiān)控與告警平臺是整個容器平臺非常重要的輔助功能，它可以幫助我們守護集群健康并及時預(yù)警通知，它也是實現(xiàn)自動化運維的必經(jīng)之路。3.1 監(jiān)控告警平臺架構(gòu)監(jiān)控告警平臺，除了實現(xiàn)傳統(tǒng)物理主機層面的監(jiān)控外，主要會實現(xiàn)容器級別的業(yè)務(wù)狀態(tài)、資源使用率等監(jiān)控。主機層面的監(jiān)控，可以采用傳統(tǒng)的Zabbix進行，比較成熟，這里不做介紹。容器級別監(jiān)控的對象主要包括K8S集群（各組件）、應(yīng)用服務(wù)、Pod、容器及網(wǎng)絡(luò)等。這些對象主要表現(xiàn)為以下三個方面：K8S集群自身健康狀態(tài)監(jiān)控(kube-controller-manage

19、r/kube-scheduler/kube-apiserver/kubelet/kube-proxy 5個基礎(chǔ)組件、Docker、Etcd、網(wǎng)絡(luò)插件calico，DNS等）系統(tǒng)性能的監(jiān)控，比如：cpu、內(nèi)存、磁盤、網(wǎng)絡(luò)、filesystem及processes等；業(yè)務(wù)資源狀態(tài)監(jiān)控，主要包括：rc/rs/deployment/hpa/ds、Pod、Service、Ingress等。K8S組件相關(guān)的監(jiān)控，早期一般會配合相關(guān)的shell腳本，通過crond開啟后監(jiān)控各組件狀態(tài)，目前可以使用Prometheus來實現(xiàn)系統(tǒng)組件級別的監(jiān)控。容器相關(guān)的監(jiān)控，早期采用傳統(tǒng)的Heapster+Influxdb+

20、Grafana方案，目前還是Prometheus用的比較多，下面會簡要介紹這兩種架構(gòu)方案，具體還請參考相關(guān)文獻。3.1.1 Heapster+Influxdb+Grafana方案監(jiān)控與告警架構(gòu)Cadvisor：將數(shù)據(jù)，寫入InfluxDBInfluxDB：時序數(shù)據(jù)庫，提供數(shù)據(jù)的存儲，存儲在指定的目錄下Grafana：是一個開源的數(shù)據(jù)監(jiān)控分析可視化平臺，支持多種數(shù)據(jù)源配置(支持的數(shù)據(jù)源包括 InfluxDB，MySQL，Elasticsearch，OpenTSDB，Graphite 等)和豐富的插件及模板功能，支持圖表權(quán)限控制和報警。Heapster首先從K8S Master獲取集群中所有Nod

21、e的信息，每個Node通過“kubelet”調(diào)用“cAdvisor API”來采集所有容器的數(shù)據(jù)信息（資源使用率和性能特征等）。這樣既拿到了Node級別的資源使用狀況信息，又拿到了容器級別的信息，它可以通過標(biāo)簽來分組這些信息，之后聚合所有監(jiān)控數(shù)據(jù)，一起“sink”到“Heapster”配置的后端存儲中（“Influxdb”)，通過“Grafana”來支持數(shù)據(jù)的可視化。所以需要為Heapster設(shè)置幾個重要的啟動參數(shù)，一個是“-source”用來指定Master 的 URL作為數(shù)據(jù)來源，一個是“-sink”用來指定使用的后端存儲系統(tǒng)（Influxdb)，還有就是“-metric_resoluti

22、on”來指定性能指標(biāo)的精度，比如：“30s”表示將過去30秒的數(shù)據(jù)進行聚合并存儲。這里說一下Heapster的后端存儲，它有兩個，一個是“metricSink”，另一個是 “influxdbSink”。metricSink是存放在本地內(nèi)存中的metrics數(shù)據(jù)池，會默認創(chuàng)建，當(dāng)集群比較大的時候，內(nèi)存消耗會很大。Heapster API獲取到的數(shù)據(jù)都是從它那獲取的。而influxdbSink接的是我們真正的數(shù)據(jù)存儲后端，在新版本中支持多后端數(shù)據(jù)存儲，比如可以指定多個不同的influxDB 。通過Grafana，用戶可以使用各種正則表達式或者選項查看自己的業(yè)務(wù)監(jiān)控詳情，還可以按系統(tǒng)性能（cpu、內(nèi)

23、存、磁盤、網(wǎng)絡(luò)、filesystem）進行排序查看等等。監(jiān)控示例當(dāng)監(jiān)控到一定的數(shù)量級，超過某個閾值時，將產(chǎn)生告警。雖然Grafana目前支持郵件進行一些簡單的告警，但我們還是通過制定一些監(jiān)控點、告警機制、告警等級等，然后接入公司內(nèi)部現(xiàn)有告警平臺來進行告警。郵件告警示例如下：3.1.2 Promethues方案Prometheus是一套開源的系統(tǒng)監(jiān)控和報警框架，靈感源自Google的Borgmon監(jiān)控系統(tǒng)。2012年，SoundCloud的Google前員工創(chuàng)造了Prometheus，并作為社區(qū)開源項目進行開發(fā)。2015年，該項目正式發(fā)布。2016年，Prometheus加入云原生計算基金會（Cloud Native Computing Foundation），成為受歡迎度僅次于Kubernetes的項目。Prometheus具有以下特性：多維的數(shù)據(jù)模型（基于時間序列的 Key、Value鍵值對）靈活的查詢和聚合語言PromQL提供本地存儲和分布式存儲通過基于HTTP的Pull模型采集時間序列數(shù)據(jù)可利用Pushgateway（Pro