阿里雲容器Kubernetes監控(九)
前言
監控是保障系統穩定性的重要組成部分，在Kubernetes開源生態中，資源類的監控工具與元件百花齊放。除了社群自己孵化的metrics-server，還有從CNCF畢業的Prometheus等等，開發者可選的方案有很多。但是，只有資源類的監控是遠遠不夠的，因為資源監控存在如下兩個主要的缺欠：
- 監控的實時性與準確性不足
大部分資源監控都是基於推或者拉的模式進行資料離線，因此通常資料是每隔一段時間採集一次，如果在時間間隔內出現一些毛刺或者異常，而在下一個採集點到達時恢復，大部分的採集系統會吞掉這個異常。而針對毛刺的場景，階段的採集會自動削峰，從而造成準確性的降低。
- 監控的場景覆蓋範圍不足
部分監控場景是無法通過資源表述的，比如Pod的啟動停止，是無法簡單的用資源的利用率來計量的，因為當資源為0的時候，我們是不能區分這個狀態產生的真實原因。
基於上述兩個問題，Kubernetes是怎麼解決的呢？
事件監控-監控的新維度
Kubernetes作為雲原生的平臺實現，從架構設計上將介面與實現做到了完整的解耦和插拔，以狀態機為整體的設計原則，通過設定期望狀態、執行狀態轉換、檢查並補償狀態的方式將資源的生命週期進行接管。
狀態之間的轉換會產生相應的轉換事件，在Kubernetes中，事件分為兩種，一種是Warning事件，表示產生這個事件的狀態轉換是在非預期的狀態之間產生的；另外一種是Normal事件，表示期望到達的狀態，和目前達到的狀態是一致的。我們用一個Pod的生命週期進行舉例，當建立一個Pod的時候，首先Pod會進入Pending的狀態，等待映象的拉取，當映象錄取完畢並通過健康檢查的時候，Pod的狀態就變為Running。此時會生成Normal的事件。而如果在執行中，由於OOM或者其他原因造成Pod宕掉，進入Failed的狀態，而這種狀態是非預期的，那麼此時會在Kubernetes中產生Warning的事件。那麼針對這種場景而言，如果我們能夠通過監控事件的產生就可以非常及時的檢視到一些容易被資源監控忽略的問題。
一個標準的Kubernetes事件有如下幾個重要的屬性，通過這些屬性可以更好地診斷和告警問題。
- Namespace：產生事件的物件所在的名稱空間。
- Kind：繫結事件的物件的型別，例如：Node、Pod、Namespace、Componenet等等。
- Timestamp：事件產生的時間等等。
- Reason：產生這個事件的原因。
- Message: 事件的具體描述。
- 其他資訊
通過事件的機制，我們可以豐富Kuernetes在監控方面的維度和準確性，彌補其他監控方案的缺欠。
kube-eventer v1.0.0的釋出與開源
針對Kubernetes的事件監控場景，Kuernetes社群在Heapter中提供了簡單的事件離線能力，後來隨著Heapster的廢棄，相關的能力也一起被歸檔了。為了彌補事件監控場景的缺失，阿里雲容器服務釋出並開源了kubernetes事件離線工具kube-eventer
在本次正式釋出的v1.0.0的版本中，作了如下功能的增強。
- 釘釘外掛支援Namespace、Kind的過濾
- 支援與NPD外掛的整合與部署
- 優化SLS外掛的資料離線效能
- 修復InfluxDB外掛啟動引數失效的問題
- 修復Dockerfile的安全漏洞
- 以及其他共11項功能修復
典型場景分析：
- 使用釘釘進行事件告警
- 使用SLS進行事件告警
- 結合NPD進行異常檢測與事件告警,此外使用容器服務的開發者可以直接用應用目錄中的Helm Chart進行部署。
專案開源地址：https://github.com/AliyunContainerService/kube-eventer
本文作者：莫源
本文為雲棲社群原創內容，未經