如何從Kubernetes Event中提取有效信息

對於今天的基礎設施工程團隊來說,太多的監控和告警疲勞是一個真正的問題。現在有很多開源和第三方的工具提供了過濾噪音的能力。這聽起來總是很好,而且很可能是真的。但是,如果我告訴你,我最喜歡的替代品之一就在你面前,而且幾乎可以立即從 Kubernetes 的 API 中獲得呢?我說的是 Kubernetes 事件反饋。

Kubernetes 事件提供了對集羣健康和性能的獨特而清晰的見解。而在數據過多的時代,我發現 Kubernetes 事件提供了清晰的洞察力,而沒有太多的噪音。

在這篇文章中,我們將瞭解 Kubernetes 事件類型,幫助你訪問和存儲事件,並建議一些大多數團隊,無論大小,發現有幫助的告警。

什麼是 Kubernetes 事件?類型和示例

Kubernetes 事件是一個對象,它顯示集羣、節點、pod 或容器內發生的事情。這些對象通常是爲了響應 K8s 系統內部發生的變化而生成的。該 Kubernetes API 服務器使所有核心組件來創建這些事件。通常,每個事件還伴隨着一條日誌消息。但是,這兩者非常不同,不會以任何其他方式相互影響。

關於 Kubernetes 事件需要注意的一件重要事情是,它們會在一段時間後被默認刪除,通常在一個小時內。因此,您必須注意並收集發生的重要事件。

要訪問 Kubernetes 事件,您可以運行以下命令:

kubectl get event

結果如下所示:

如您所見,許多 Kubernetes 事件是由節點中的狀態更改引起的。每個事件都有一個 Reason 字段。您可以使用此字段來確定 K8s 事件對象的類型。以下是一些基於事件原因的標準分類。

失敗的事件

當 K8s 無法創建一個容器或其他資源時,就會產生失敗事件。這可能是由於錯誤的鏡像、輸入錯誤、沒有預料到的原因以及許多不同的原因。幾乎可以肯定的是,失敗的事件將導致你的應用程序的功能被破壞;因此監測這些類型的事件是非常重要的。

FailedToCreateContainer、FailedToStartContainer、FailedToPullImage、FailedToKillPod等是一些失敗事件的例子。

驅逐事件

驅逐事件經常發生,因爲 K8s 經常介入並驅逐惡意容器和 pod(那些不必要地消耗大量資源的容器)。雖然這是預期的行爲,但你仍然需要注意這些事件的發生。大量的驅逐事件表明,你沒有在系統中設置適當的閾值。更多的時候,K8s 可能無法識別要驅逐的最佳實體,導致不相關的驅逐,從而導致服務流量損失。

節點特定事件

許多 K8s 事件都是基於節點及其生命週期活動。您可能已經注意到NodeHasSufficientMemory、NoteHasSufficientPID、NodeReady和上面示例中的其他事件。這些事件傳達了節點相關的狀態變化,並在尋找系統不穩定行爲的根源時派上用場。

存儲特定事件

所有基於雲的應用程序都以一種或另一種方式利用存儲。K8s 主要連接 AWS、GCP 等外部服務,或者 Docker 內部資源進行存儲。在某些情況下,Pod 可能無法掛載存儲資源。您應該注意FailedMount、FailedAttachVolume事件以識別錯誤存儲安裝的情況。

調度事件

調度事件提供了對資源管理策略效率的洞察。如果您沒有很好地管理您的資源,則可能沒有任何剩餘的資源可以分配給新的 Pod。內存或 CPU 不足通常是罪魁禍首,在大多數情況下,您會收到FailedScheduling事件,並清楚說明爲什麼無法進行調度。

獲取 Kubernetes 事件

要訪問 Kubernetes 事件,您可以爲 Pod 運行以下命令:

kubectl describe <podname>
或者,如果您想根據事件類型或任何其他字段查看更大的事件集合,您可以運行以下命令:

kubectl get events –field-selector type!=Normal
雖然這些命令爲您提供命令行上的最新事件,但它們對需要歷史數據分析的大規模部署沒有幫助。您可以使用以下命令從 Kubernetes API 導出事件數據以進行詳細分析:

kubectl get events -o json
這會將最新事件導出到 JSON 文件中,您可以將其導入到您最喜歡的可視化工具中以獲得更多信息。

如何收集和存儲事件

上面討論的最後一種方法是從 Kubernetes 導出事件的最原始方法之一。您可以使用多種其他技術來安全地收集和存儲事件。

本地觀看和導出事件
Kubectl 提供了另一個方便的命令來觀察系統中發生的事件:

kubectl get events –watch
這將開始將事件流式傳輸到您的終端。同樣,這對於分析和可視化不是很有用。所以你應該考慮將它與像 Banzai Cloud 這樣的第三方日誌收集器結合起來進行分析。

KubeWatch

KubeWatch 是一個很棒的開源工具,用於觀看 K8s 事件並將其流式傳輸到第三方工具和 webhook。您可以將其配置爲在 Slack 通道中發送重要狀態更改的消息。您還可以使用它向 Prometheus 等分析和告警工具發送事件。

您可以通過您最喜歡的 Kubernetes 工具(如 kubectl 或 helm)安裝 KubeWatch。以下是 KubeWatch 的 Slack 通知快照信息:

KubeWatch 提供了一個簡單的設置過程,但不提供獨立的存儲或管理功能。此外,您不會獲得任何指標或日誌記錄功能。

Events Exporter

該 Kubernetes Events Exporter https://github.com/caicloud/e... 是在 K8S 本地觀看的一個很好的替代。它允許您持續監控 K8s 事件並在需要時列出它們。它還從收集的數據中提取了大量指標,如事件計數、唯一事件計數等,併爲您提供基本的監控設置。它非常易於安裝,並且可以成爲在使用更全面的工具安頓下來之前嘗試的絕佳替代方案。

EventRouter

EventRouter https://github.com/heptiolabs...是另一個收集 Kubernetes 事件的偉大開源工具。它的設置毫不費力,旨在將 Kubernetes 事件流向多個源或匯,正如其文檔中所說的那樣。然而,就像 KubeWatch 一樣,它也不提供查詢或持久性功能。你需要將它與第三方存儲和分析工具連接起來,以獲得全面的體驗。

一旦你瞭解了你的監控目標並制定了策略,你可以考慮轉移到一個專門的、付費的 K8s 事件監控服務。你會得到強大的查詢功能和跨平臺的警報。

對常見的警告事件發出告警

實時觀察 K8s 事件對了解系統中發生的情況至關重要。然而,你也需要建立一個強大的警報策略,在出現異常或緊急情況時通知你。

作爲一個經驗法則,你應該密切關注失敗和調度事件,因爲忽視這些事件會破壞你的應用程序的功能。你可以將被驅逐的事件設置爲低優先級,因爲它們通常是由於 K8s 的常規清理而產生的。節點特定的事件和存儲特定的事件必須告警(雖然 NodeReady 是一個很好的事件,但你不需要每次都爲它發出警報)。

大多數工具允許通過 webhooks 或 Slack 等常用協作平臺發送告警。雖然這很簡單,也很容易設置,但你可以通過把你的監控工具連接到一個更高級的告警平臺上,使它更進一步。Prometheus 的 AlertManager 也是一個不錯的選擇。你也可以考慮使用基於 SaaS 的解決方案,比如 ContainIQ,它有專門的接口來創建告警事件,在廣泛的平臺上發送,並能夠將事件與其他指標聯繫起來。

最後的想法

Kubernetes 事件是監控 K8s 集羣運行狀況和活動的好方法。但是,當與實用的策略和廣泛的工具集相結合時,它們會變得更加強大。本指南幫助您瞭解 Kubernetes 事件的重要性以及如何從中獲取最大價值。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章