英文原文：Extracting value from the Kubernetes events feed

譯文原文：從Kubernetes事件中提取價值

客座文章作者：Nate Matherson，ContainIQ 聯合創始人和執行長

對於當今的工程團隊來說，太多的監視和警報疲勞是一個真正的問題。現在有很多開源和第三方工具可以解決這些問題。這聽起來總是像是真的，而且很可能是真的。但是，如果我告訴你，我最喜歡的一個替代方案就在你面前，並且幾乎可以立即從 Kubernetes API 訪問，你會怎麼做呢？我說的是 Kubernetes 事件。

Kubernetes 事件為叢集執行狀況和效能提供了獨特而清晰的見解。在資料太多的日子裡，我發現 Kubernetes 事件在沒有太多幹擾的情況下提供了清晰的見解。

在本文中，我們將瞭解 Kubernetes 事件型別，幫助你訪問和儲存事件，並建議一些大多數團隊（無論大小）都會覺得有用的提醒。

什麼是 Kubernetes 事件？型別和例子

Kubernetes 事件是一個物件，它顯示了叢集、節點、pod 或容器中正在發生的事情。這些物件通常是根據 K8s 系統中發生的更改而生成的。Kubernetes API Server 允許所有核心元件建立這些事件。通常，每個事件都伴隨著一條日誌訊息。然而，這兩者是非常不同的，不會以任何其他方式影響彼此。

關於 Kubernetes 事件需要注意的一件重要的事情是，它們在預設情況下會在一段時間後被刪除，通常在一個小時以內。因此，你必須在重要事件發生時觀察並收集它們。

訪問 Kubernetes 事件可以使用如下命令：

kubectlgetevent

結果是這樣的：

新啟動節點的事件

正如你所看到的，許多 Kubernetes 事件都是由節點狀態的改變引起的。每個事件都有一個 Reason 欄位。你可以使用這個欄位來確定 K8s 事件物件的型別。以下是一些基於事件原因的標準分類。

失敗事件

當 K8s 建立容器或其他資源失敗時，將生成失敗事件。這可能是由於錯誤的映象、輸入錯誤、不充分的原因，以及許多不同的原因。幾乎可以肯定的是，失敗事件會導致應用的功能失效；因此，監視這些型別的事件是必要的。

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

驅逐事件

驅逐事件經常發生，因為 K8s 經常會介入並驅逐流氓容器和 pod（那些不必要地消耗大量資源的容器和 pod）。雖然這是預期的行為，但你仍然需要注意這些事件的發生。大量的驅逐表明你沒有在系統中設定適當的閾值。通常情況下，K8s 可能無法確定要驅逐的最佳實體，從而導致不相關的驅逐，從而損失正常執行時間。

與節點相關的事件

許多 K8s 事件都基於節點及其生命週期活動。你可能已經注意到上面示例中的 NodeHasSufficientMemory、NoteHasSufficientPID、NodeReady 和其他事件。這些資訊傳遞與節點相關的狀態變化，在查詢系統不穩定行為的來源時可以派上用場。

與儲存相關的事件

所有基於雲的應用都以這樣或那樣的方式利用儲存空間。K8s 主要通過 Docker 連線 AWS、GCP 等外部服務或內部資源進行儲存。在某些情況下，pod 可能無法掛載儲存資源。你應該檢視 FailedMount 和 FailedAttachVolume 事件，以確定錯誤的儲存掛載情況。

排程事件

排程事件可以洞察資源管理策略的效率。如果你沒有很好地管理你的資源，可能沒有任何剩餘來分配給新的 pod。記憶體或 CPU 不足通常是罪魁禍首，在大多數情況下，你會收到一個 FailedScheduling 事件，其中清楚地描述了為什麼排程不能發生。

訪問 Kubernetes 事件

要訪問 Kubernetes 事件，可以對 pod 執行如下命令：

kubectldescribe<podname>

或者，如果需要根據事件型別或其他欄位檢視更大的事件集合，可以執行以下命令：

kubectlgetevents–field-selectortype!=Normal

雖然這些命令為你提供了命令列上的最新事件，但對於需要進行歷史資料分析的大規模部署，它們將不會有幫助。可以使用如下命令匯出 Kubernetes API 中的事件資料，進行詳細分析：

kubectlgetevents-ojson

這將匯出最新的事件到一個 JSON 檔案，你可以匯入到你最喜歡的視覺化工具，以獲得更多的見解。

如何收集和儲存事件

上面討論的最後一種方法是從 Kubernetes 匯出事件的最原始的方法之一。還有其他各種技術可以用來安全地收集和儲存事件。下面是一些最常見的。

原生觀看和匯出事件

Kubectl 提供了另一個方便的命令來監視系統中發生的事件：

kubectlgetevents–watch

這將開始流事件到你的終端。同樣，這對於分析和視覺化不是很有用。因此，你應該考慮將其與第三方日誌操作器（如Banzai Cloud 的^[1]）耦合起來進行分析。

KubeWatch

KubeWatch^[2]是一個很棒的開源工具，可以觀看 K8s 的活動並將其流媒體到第三方工具和網路鉤子上。你可以將其配置為在 Slack 通道中傳送重要狀態更改的訊息。你還可以使用它將事件傳送到分析和提醒工具（如 Prometheus）。

你可以通過 kubectl 或 helm 等你最喜歡的 Kubernetes 工具來安裝 KubeWatch。下面是 KubeWatch 的 Slack 通知的簡圖：

KubeWatch Slack Notifications（來源：KubeWatch）

KubeWatch 提供了簡單的設定過程，但不提供獨立的儲存或管理功能。此外，你也沒有獲得任何度量或日誌記錄功能。

Event Exporter

Kubernetes Event Exporter^[3]是 K8s 中原生觀看方法的一個很好的替代方案。它允許你持續監視 K8s 事件，並在需要時列出它們。它還從收集的資料中提取了大量的指標，如事件計數、獨特事件計數等，併為你提供了基本的監視設定。它安裝起來非常容易，在使用一個更全面的工具之前，可以先試用它。

EventRouter

EventRouter^[4]是另一個收集 Kubernetes 事件的開源工具。它可以輕鬆地設定和將 Kubernetes 事件流到多個目標。然而，就像 KubeWatch 一樣，它也不提供查詢或永續性特性。你需要將其與第三方儲存和分析工具連線起來，以獲得完整的體驗。

一旦瞭解了監視目標並制定了策略，就可以考慮轉向專用的付費 K8s 事件監視服務。你可以在各種平臺上獲得強大的查詢功能和警報。

常見的警告事件

實時觀察 K8s 事件對於瞭解系統中發生的情況至關重要。但是，你還需要設定一個可靠的警報策略，以便在異常或緊急情況下通知你。

根據經驗，你應該密切關注失敗事件和排程事件，因為忽略這些事件會破壞應用的功能。你可以將被驅逐的事件設定為低優先順序，因為它們通常是由 K8s 的例行清理生成的。特定於節點和特定於儲存的事件必須手動選擇以發出警報（雖然知道 NodeReady 是一個很好的事件，但你不需要每次都為它發出警報）。

大多數工具都允許通過網路鉤子或 Slack 等通用協作平臺傳送警報。雖然這很簡單，設定起來也很容易，但是你可以更進一步，將監視工具連線到更高階的警報平臺。Prometheus 中的AlertManager^[5]也是一個不錯的選擇。你還可以考慮使用基於 SaaS 的解決方案，如ContainIQ^[6]，它具有專門的介面，用於建立警報條件、在廣泛的平臺上傳送警報條件，以及將事件與其他指標關聯起來的能力。

總結

Kubernetes 事件是監視 K8s 叢集執行狀況和活動的好方法。然而，當它們與實用的策略和廣泛的工具集結合在一起時，會變得更加強大。本指南幫助你理解 Kubernetes 事件的重要性，以及如何從它們中汲取最大的價值。

參考資料

[1]Banzai Cloud 的: https://github.com/banzaicloud/logging-operator

[2] KubeWatch: https://github.com/bitnami-labs/kubewatch

[3]Kubernetes Event Exporter: https://github.com/caicloud/event_exporter

[4]EventRouter: https://github.com/heptiolabs/eventrouter

[5]AlertManager: https://prometheus.io/docs/alerting/latest/alertmanager/

[6]ContainIQ: https://www.containiq.com/kubernetes-monitoring