容器云平臺(tái)運(yùn)維最佳實(shí)踐

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

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

3、務(wù)端來不及消費(fèi)的情況，引起多余的請(qǐng)求還在隊(duì)列里就被對(duì)方關(guān)閉了。還有可能是內(nèi)核參數(shù)配置沒有做優(yōu)化處理，比如調(diào)整“tcp_keepalive_time” / “tcp_keepalive_intvl” / “tcp_keepalive_probes”等。林林總總，但經(jīng)過我們排查后，以上的可能影響點(diǎn)都不是，所以排除上述這些干擾選項(xiàng)。在排查業(yè)務(wù)問題的時(shí)候，我們還要結(jié)合“業(yè)務(wù)方”與“平臺(tái)方”的各自對(duì)自身代碼熟悉的優(yōu)勢(shì)，發(fā)揮出凝聚力，一起來排查?！皹I(yè)務(wù)方”從如下幾個(gè)方向進(jìn)行了代碼方面的排查：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垃圾回收時(shí)間，因?yàn)槠淇赡軙?huì)引起垃圾回收異常等；以上發(fā)現(xiàn)都是正常的，無果?！捌脚_(tái)方”嘗試過以下排查：1、修改Kubernetes node主機(jī)的內(nèi)核相關(guān)配置（比如：tcp keepalived相關(guān)參數(shù)，ulimit限制數(shù)等）；2、檢查Kubernetes Ingress入口Nginx的配置（比如：Kubernetes Nginx的超時(shí)配置與業(yè)務(wù)自身Nginx的超時(shí)時(shí)間減少些，比

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

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

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

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

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

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

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

12、顯。攜程團(tuán)隊(duì)曾對(duì)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)測(cè)試ClickHouse的查詢速度比ElasticSearch快5

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

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

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

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

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

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

19、r/kube-scheduler/kube-apiserver/kubelet/kube-proxy 5個(gè)基礎(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)控，早期一般會(huì)配合相關(guān)的shell腳本，通過crond開啟后監(jiān)控各組件狀態(tài)，目前可以使用Prometheus來實(shí)現(xiàn)系統(tǒng)組件級(jí)別的監(jiān)控。容器相關(guān)的監(jiān)控，早期采用傳統(tǒng)的Heapster+Influxdb+

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

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

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

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