監(jiān)控是保障系統(tǒng)穩(wěn)定性的重要組成部分，在Kubernetes開源生態(tài)中，資源類的監(jiān)控工具與組件百花齊放。除了社區(qū)自己孵化的metrics-server，還有從CNCF畢業(yè)的Prometheus等等，開發(fā)者可選的方案有很多。但是，只有資源類的監(jiān)控是遠遠不夠的，因為資源監(jiān)控存在如下兩個主要的缺欠：大部分資源監(jiān)控都是基于推或者拉的模式進行數(shù)據(jù)離線，因此通常數(shù)據(jù)是每隔一段時間采集一次，如果在時間間隔內(nèi)出現(xiàn)一些毛刺或者異常，而在下一個采集點到達時恢復，大部分的采集系統(tǒng)會吞掉這個異常。而針對毛刺的場景，階段的采集會自動削峰，從而造成準確性的降低。 部分監(jiān)控場景是無法通過資源表述的，比如Pod的啟動停止，是無法簡單的用資源的利用率來計量的，因為當資源為0的時候，我們是不能區(qū)分這個狀態(tài)產(chǎn)生的真實原因。 基于上述兩個問題，Kubernetes是怎么解決的呢？ 事件監(jiān)控-監(jiān)控的新維度Kubernetes作為云原生的平臺實現(xiàn)，從架構設計上將接口與實現(xiàn)做到了完整的解耦和插拔，以狀態(tài)機為整體的設計原則，通過設定期望狀態(tài)、執(zhí)行狀態(tài)轉(zhuǎn)換、檢查并補償狀態(tài)的方式將資源的生命周期進行接管。 
狀態(tài)之間的轉(zhuǎn)換會產(chǎn)生相應的轉(zhuǎn)換事件，在Kubernetes中，事件分為兩種，一種是Warning事件，表示產(chǎn)生這個事件的狀態(tài)轉(zhuǎn)換是在非預期的狀態(tài)之間產(chǎn)生的；另外一種是Normal事件，表示期望到達的狀態(tài)，和目前達到的狀態(tài)是一致的。我們用一個Pod的生命周期進行舉例，當創(chuàng)建一個Pod的時候，首先Pod會進入Pending的狀態(tài)，等待鏡像的拉取，當鏡像錄取完畢并通過健康檢查的時候，Pod的狀態(tài)就變?yōu)镽unning。此時會生成Normal的事件。而如果在運行中，由于OOM或者其他原因造成Pod宕掉，進入Failed的狀態(tài)，而這種狀態(tài)是非預期的，那么此時會在Kubernetes中產(chǎn)生Warning的事件。那么針對這種場景而言，如果我們能夠通過監(jiān)控事件的產(chǎn)生就可以非常及時的查看到一些容易被資源監(jiān)控忽略的問題。 一個標準的Kubernetes事件有如下幾個重要的屬性，通過這些屬性可以更好地診斷和告警問題。 Namespace：產(chǎn)生事件的對象所在的命名空間。 Kind：綁定事件的對象的類型，例如：Node、Pod、Namespace、Componenet等等。 Timestamp：事件產(chǎn)生的時間等等。 Reason：產(chǎn)生這個事件的原因。 Message: 事件的具體描述。 其他信息
通過事件的機制，我們可以豐富Kuernetes在監(jiān)控方面的維度和準確性，彌補其他監(jiān)控方案的缺欠。 kube-eventer v1.0.0的發(fā)布與開源
針對Kubernetes的事件監(jiān)控場景，Kuernetes社區(qū)在Heapter中提供了簡單的事件離線能力，后來隨著Heapster的廢棄，相關的能力也一起被歸檔了。為了彌補事件監(jiān)控場景的缺失，阿里云容器服務發(fā)布并開源了kubernetes事件離線工具kube-eventer。支持離線kubernetes事件到釘釘機器人、SLS日志服務、Kafka開源消息隊列、InfluxDB時序數(shù)據(jù)庫等等。 在本次正式發(fā)布的v1.0.0的版本中，作了如下功能的增強。
|
