前言

監控是保障系統穩定性的重要組成部分，在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項功能修復

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的Kubernetes事件离线工具kube-eventer正式开源的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。