騰訊雲多Kubernetes的多維度監控實踐

歡迎你們前往騰訊雲社區，獲取更多騰訊海量技術實踐乾貨哦~

本次內容根據2017年11月4日 K8S Geek Gathering 沙龍深圳站騰訊雲高級工程師王天夫的演講內容整理而成。

本次分享的主要內容涉及騰訊雲容器的頂層總體設計，包括產品功能，及提供的附加能力。同時會介紹咱們如今Master集羣化部署的總體方案。經過這些內容的提早了解，能夠更好理解後面和你們分享的關於容器監控的內容，全部監控的設計都是依賴於Master集羣化部署的。最後會和你們分享騰訊雲容器服務監控的Future Work。

你們能夠看一下這個圖，這是騰訊雲容器服務PaaS平臺頂層的設計，最上面是雲Portal，意義是用戶在使用咱們容器服務的時候可以從這幾個維度去掌控他們的集羣、建立他們的容器。第一個是MC，能夠理解爲是控制管理臺，你們都知道Kubernetes自己的概念是比較複雜的，對一個剛剛接手Kubernetes的人來講理解成本是特別大的，咱們在Kubernetes之上包裝了它的概念，對於剛剛接手的人來講是很是好的理解。同時可視化出來提供頁面給你們用。第二點是支持原生的K8S API，由於整個容器服務是基於K8S開發的，爲了保證用戶使用不一樣的Kubernetes，因此咱們在Kubernetes主幹上並不會去作很大的改動，由於一開始咱們是作過這方面的東西，可是咱們發現若是咱們在K8S上作了特別大的改動，在第二次提供給用戶或者升級的時候，是一個很是困難的事情，由於你們知道K8S的迭代是很是快的，大概是半年到一年時間就會升級一個大版本，因此咱們基本上都是原生基於K8S開發。最後咱們還把咱們本身包裝的概念經過一個雲API提供給用戶使用，由於如今不少的用戶都是有本身的運營系統的，他們會使用雲API去封裝一些本身的運營平臺，因此咱們這裏也支持了一下。

中間這塊是整個容器服務三個大部分，第一塊是整個CCS，這塊提供了以下的功能，像集羣管理、模板應用管理，應用管理這裏指的是咱們會把全部的服務包裝成一個大的應用，方便用戶去一鍵部署本身的應用。第三個是服務管理，咱們把K8S裏面提到的概念，像deployment,service,pod封裝成服務的概念提供給用戶，後面還有日誌、券和配額，這些都是咱們這邊開發的。最底層，由於咱們要支持原生的Kubernetes，因此不可避免的須要有些開發，好比和IaaS層、PaaS層的打通，就須要有日誌、網絡、券、負載均衡的驅動開發。第二塊是CCR，是我剛纔提到的鏡像服務。鏡像服務支持有多個hub源的鏡像，還有自建的Cloud的鏡像，還有第三方的也支持。同時咱們作了一些比較重要的優化，咱們在海外搭建了不少節點，幫助用戶可以快速的拉取鏡像，而且作成mirror，同時咱們的鏡像倉庫是分地域部署。同時咱們還會定時拉去Docker Hub上的鏡像作緩存，進一步提高效率。最後一塊是CI/CD，CI/CD是去定義自動部署、自動構建的策略，例如提交代碼時自動觸發。

下面是我如今負責的CCS-Monitor Server，包括監控上面整套容器服務的體系。最底下是對咱們本身騰訊雲的IaaS和PaaS層的集合，譬如說CVM、黑石，你們能夠理解爲公有云和私有云，同時咱們集成塊存儲、對象存儲、CFS，咱們還有日誌中心，後面我會講一下。最後還有彈性伸縮和負載均衡，彈性伸縮主要能夠理解爲HPA和HNA，這是騰訊服務頂層的計。

接下來第二點，給你們講一下騰訊雲Master集羣化部署。下圖是如今騰訊容器服務Master集羣化部署的概覽，我給你們說一下大概的背景。當初騰訊雲的容器服務剛開始上線的時候，這個地方並非這樣子的。

剛開始咱們會爲用戶的每一個集羣建立一個Master，這個Master當初是一個虛擬機，爲了作高可用，咱們會爲用戶再部署一個stand by的Master，當Master出現故障的時候，咱們能夠方便的切換。

最後就形成不少多的問題，一是成本的問題，若是每一個集羣都部署一個Master，部署一臺虛擬機，成本很大。二是運維成本，每臺Master都是一臺虛擬機，每一個master的組件，是一個二進制文件部署在Master上面。這種狀況下，若是對某個Master進行升級，不可避免的就會出現不少問題。

基於這個考慮，咱們從新優化了整個咱們的Master部署，咱們採用的方案是調研了社區裏面一些熱門的方案，這個方案就是kubernetes in kubernetes，不知道你們有沒有了解過這個東西。咱們單獨部署一套K8S集羣，全部Master的組件，你們知道的三大組件都會以pod的形式運行在K8S集羣中。咱們爲Pod綁定雙網卡，一個網卡是彈性網卡，它會單獨與用戶的VPC作網絡通訊，另一個網卡是原生的，這個網卡會是Master集羣中使用的網卡。

每一個API的組件都是一個Pod，好處是，一是Master集羣的部署，主要是以K8S管理，這樣HA、SLA都有很大的保證，包括後面運維的提高，可使用K8S原生的rolling update去操做。其次是成本，有些用戶可能Master不須要那麼大的CPU Memory，咱們能夠共同調整CPU Memory的request，同時對於大型的客戶，譬如說在集羣中運行了上千個Pod狀況下，經過動態調整擴展Master的配置，增大更多的Api server作一個負載調優。

這裏大概講了如今集羣化部署的方案，後面我監控的方案都會依賴於這個，給你們稍微先講一下這塊。

第三，基礎的指標監控。咱們的基礎指標監控主要仍是以IaaS層爲主，就是你們所說的Cpu,Memory、DiSK和Network方面。這裏一共有四塊，Node、Deployment，Deployment，Pod，container，全部IaaS層的監控指標都會依照這四個模塊來作聚合。

上面的四塊是我講的IaaS層基礎指標，這裏我選取了幾個重要的指標，若是你們之後有自建容器監控，但願對你們有所幫助。CPU Memory有些指標是很是重要的，例如CPU Usage和Memory Usage，這裏的Cpu Usage和Memory Usage是佔整個pod request或者 limit的整個比例，若是這兩個指標比較高，就必須警覺起來，可能會形成pod不可用的問題發生，另外我提一下，你們知道，在K8S中，有一個request 和limit的概念，若是request limit不配置，在一些測試環境，不知道你們有沒有試過，當一個Pod跑到很高的狀況下，會出現雪崩的效應，好比跑掛一臺機器，這時候掛了以後，節點異常，K8S會自動的把這臺機器上全部的Pod踢走，Pod會自動建立到另外的機器上，繼續拖垮另一臺機器，這種能夠稱之爲「雪崩效應」。最後形成的結果是K8S集羣不可用。其次，CPU node和Memory node。當前你的K8S集羣中還有剩餘的CPU和Memory可分配的比例，當一個K8S pod配置的request limit不能知足當前集羣中所剩餘的量，就會形成，新的Pod沒法調度。Network比較基本，一個是進出帶寬、進出流量，還有進出包量。Disk有幾個比較重要的，traffic、iops，這些本身自建的時候也須要關注。
最後單獨提一下Inode，有一次用戶使用過程發現Pod建立不成功，通過多方面調查，發現Inode滿了，爲何出現這種狀況？咱們看了K8S代碼，它對鏡像和日誌都有回收機制，可是對Inode的回收和清理是沒有的，社區也有討論，可是一直沒有解決。因此說Inode這塊是必需要監控起來的，它會形成你整個集羣中某個節點沒法建立服務，因此說我單獨把它拎出來和你們提一下，我不知道如今的1.8版本有沒有解決這個問題。

最後是LB的監控，你們能夠知道，servers有幾種提供的訪問方式，騰訊雲容器服務的servers與騰訊雲的LB作了綁定，用戶建立servers的時候，若是指定的方式是LB，咱們經過插件的方式幫他申請一個LB掛在上面，不論是內網仍是外網。用戶對本身服務的監控，咱們能夠經過LB的Httpcode和當前的鏈接數、回包的時間等指標去作，就能準確的判斷出當前業務的健康狀態。

這是基礎監控指標大概的架構（見下圖）。咱們主要使用開源的方式，你們在網上關注監控就知道，容器的監控大概有這麼幾種方案，當時咱們作方案評估的時候也考慮過其餘幾種，最後仍是選擇了heapster的方式，仍是業務驅動，由於調研的時候發現cadvisor對K8S中的聚合沒有作得特別好，它的數據都是原始的數據，若是咱們在以Kubernetes的方式聚合，這是很複雜的。普羅米修斯，咱們考慮它比較重，一個是集收集，告警和存儲一體的，咱們須要的僅僅是收集這塊，因此說普羅米修斯並不適合咱們這裏的業務，最後咱們就選擇使用heapster。咱們這裏的heapster也是以容器的方式部署在Master集羣化部署的集羣裏面，對用戶是無感知的，也不消耗用戶的資源。其次heapster咱們幫它綁定兩張網卡，一張是去用戶的集羣中拉取監控數據，由於你們知道heapster須要與Kubernetes通訊，拉取一些監控數據，因此咱們這裏必須綁定兩張網卡。其次咱們會構建一個CCS Monitorserver，定時拉取一些集羣的監控數據，作一些彙總或計算。最後，咱們會把這些收集到的數據Push到Barad server，這能夠理解爲騰訊雲整個監控的組件，這是平臺級的組件。Barad server作了幾件事，一是聚合，會把咱們全部上報的指標聚合成，好比咱們加一些時間粒度的彙總，1分鐘、5分鐘、10分鐘這種，包括咱們以Node的形式展現出整個Node下全部pod平均的監控指標。作這種聚合。最後咱們會提供雲API的方式給接入層使用，接入層主要是用戶調取須要的監控指標，還有HPA和HNA，就是Pod和Node水平擴展，這個是咱們直接拉取Barad API的數據作擴展工做。

第四，事件指標。其實在問題發生的時候，若是僅僅只看基礎的監控指標是遠遠不夠的，由於你只能發現你的服務出現了問題，可是你不能很好的去知道究竟是哪一個服務出現了問題，事件指標主要以下幾個問題：一、匯聚當前K8S全部資源事件的彙總，咱們會根據這些事件作本身的提煉，同時push到事件中心。二、事件中心指標彌補指標監控信息部直接的短板，我剛纔說到過。三、提升問題的定位效率。四、事件指標支持告警。事件指標主要分兩大塊：一、異常事件；二、狀態事件。異常事件你們能夠理解爲Pod建立失敗、重啓、節點異常、內存不足、調度失敗的事件。狀態事件是一些正常事件，好比Pod啓動、銷燬、更新中、HPA觸發、HNA觸發。它對對於定位問題也有很大的幫助。

事件指標的總體方案，咱們當前是從API server中拉取K8S全部的事件，會存儲在ES集羣中，咱們會有內部的Cluster作數據的查詢和展現。ES中匯聚的都是每條基礎數據，也就是你們俗稱的源數據。其次CCS Monitor會把它合併成用戶可以理解的彙總的數據，而後推到騰訊雲事件中心去。最後用戶能夠在控制檯上看到這個事件發生的緣由、屬於哪一個資源，最後還會告訴它如何解決這個問題，會有一個幫助文檔。

第五，整個監控中對騰訊最重要的是集羣穩定性的監控。這裏的圖會有點問題，集羣穩定性的監控分爲四大塊，Kube-System和ETCD、Master相關組件監控，好比API server等，最重要的是運行時問題監控。

集羣穩定性監控採用三個開源的方案，一是Node Detector，主要是作運行時。Fluentd主要是採集每一個Master集羣上每一個容器的node，後面也用了普羅米修斯的方案，沒有再使用heapster，由於普羅米修斯，咱們須要它作一些存儲，不須要作對外展現，這是內部使用，因此咱們須要採用普羅米修斯去定製一些東西去採集更多的指標。你們能夠看到整個Master集羣上，每一個Master集羣上每一個node部署的各個pod，Fluentd會拉取lod。普羅米修斯咱們本身定製了一些插件，在每一個pod上拉取一些咱們基本的指標。同時Node Detector部署在每一個用戶節點上，這是用戶能夠本身選擇的。它主要採集一些Kernel和runtime的問題。Node Detector是K8S官方的項目，若是你們感興趣能夠了解一下。

第六，最後一個監控組件，業務日誌監控。你們知道業務日誌對於一個問題定位幫助是很是大的，若是一個監控僅僅只有事件和指標，其實不少問題都沒法定位，由於容器在使用的時候，更多的會動態的增長和減小。因此咱們這裏會採集容器日誌，而且保存在日誌服務中，供用戶在後期能更方便的去追溯到原來的一些業務問題。業務日誌分四個板塊，容器日誌的收集和節點日誌的收集，還有日誌存儲和日誌處理，如今容器日誌也是前面提到的stdout和stderr日誌，而且附加相關的Kubernetes Metadata，主機特定目錄的日誌並附加指定的label去收集用戶容器達到主機上固定的日誌。存儲方面，咱們支持把日誌發送到用戶本身搭建的Kafka或者ES或者騰訊雲的日誌服務中存儲起來作消費。最後一塊是日誌處理，日誌處理主要是方便用戶可以去方便定位問題，同時咱們支持可以根據必定關鍵字配置一些關鍵字的告警，最後咱們後續可能還會支持作一些大數據的處理工做。

整個業務日誌的監控總體的方案（見PPT），咱們讓用戶定義一個個不一樣的規則，不一樣的規則能夠叫collector，全部的collector會併成一個Config Map，在啓動Fluentd的時候會收集Cluster指定的收集策略，最後發送到不一樣的後端源，當時作這套設計的時候咱們考慮其餘組件的方案，主要採集的agent，咱們考慮了filebeat和fluentd,最後咱們採用的仍是fluentd，一是基於性能的考慮，fluentd是c和ruby寫的，消耗只有在40M左右，filebeat會更大一些。最重要的一點是fluentd支持數據源推的路由，也就是說它可以經過不一樣的規則、不一樣的lable去推到不一樣的終端上。例如我有一條規則A和規則B，它分別推到ES或者Ckafka，因此咱們最後就選擇了fluentd的方案作業務日誌的收集。

最後講一下咱們後期調研的工做和待開發的工做：一、自定義監控。自定義但願讓用戶可以本身去定義一些監控指標，本身Push一些監控指標到咱們的監控平臺。二、調用鏈追蹤和Real-time Monitor的部署，當一個應用起來以後，會有成千上百的容器在裏面傳輸，調用鏈就是很是直觀的監控方向,同時配合realtimemonitor，可以很好的發現服務的健康狀態，其次咱們還會提供一個應用市場，由於如今廣泛上開源也有不少的監控方案，咱們會把它打包成一個個應用提供給用戶使用，最後兩點就是告警的預測和集羣網絡的監控，告警預測咱們但願經過咱們收集的數據去分析可能發生的問題，例如說當一個時間點內某項指標與前段時間週期性比較的指標的發生很大差別的時候，咱們須要可以及時的通知用戶，這裏可能會出現了問題。集羣網絡的監控方面，咱們發現用戶在部署的集羣的時候，常常有些iptables，ACL，或者timeout等網絡的問題，這塊的監控後期一樣會補上。

 

推薦閱讀

騰訊雲批量計算：用搭積木的方式構建高性能計算系統

EB級別雲存儲是如何漲成的？

騰訊雲首發智能網關流控，公有云進入網絡精細管控時代

 

此文已由做者受權騰訊雲技術社區發佈，轉載請註明文章出處 

原文連接：https://cloud.tencent.com/community/article/581671