阿里雲容器Kubernetes監控(九) - Kubernetes事件離線工具kube-eventer正式開源

前言

監控是保障系統穩定性的重要組成部分，在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。支持離線kubernetes事件到釘釘機器人、SLS日誌服務、Kafka開源消息隊列、InfluxDB時序數據庫等等。

在本次正式發佈的v1.0.0的版本中，做了以下功能的加強。

• 釘釘插件支持Namespace、Kind的過濾
• 支持與NPD插件的集成與部署
• 優化SLS插件的數據離線性能
• 修復InfluxDB插件啓動參數失效的問題
• 修復Dockerfile的安全漏洞
• 以及其餘共11項功能修復

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。