對於當今的工程團隊來說，太多的監視和警報疲勞是一個真正的問題。現在有很多開源和第三方工具可以解決這些問題。這聽起來總是像是真的，而且很可能是真的。但是，如果我告訴你，我最喜歡的一個替代方案就在你面前，並且幾乎可以立即從 Kubernetes API 訪問，你會怎么做呢？我說的是 Kubernetes 事件
Kubernetes 事件為集群運行狀況和性能提供了獨特而清晰的見解。在數據太多的日子里，我發現 Kubernetes 事件在沒有太多干擾的情況下提供了清晰的見解。
在本文中，我們將了解 Kubernetes 事件類型，幫助你訪問和存儲事件，並建議一些大多數團隊（無論大小）都會覺得有用的提醒。
什么是 Kubernetes 事件？類型和例子
Kubernetes 事件是一個對象，它顯示了集群、節點、pod 或容器中正在發生的事情。這些對象通常是根據 K8s 系統中發生的更改而生成的。Kubernetes API Server 允許所有核心組件創建這些事件。通常，每個事件都伴隨着一條日志消息。然而，這兩者是非常不同的，不會以任何其他方式影響彼此。
關於 Kubernetes 事件需要注意的一件重要的事情是，它們在默認情況下會在一段時間后被刪除，通常在一個小時以內。因此，你必須在重要事件發生時觀察並收集它們。
訪問 Kubernetes 事件可以使用如下命令：
kubectl get event
結果是這樣的：
新啟動節點的事件
正如你所看到的，許多 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 執行如下命令：
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 的[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
本文轉載自：「CNCF」，原文：https://tinyurl.com/y6a3dvya，版權歸原作者所有。歡迎投稿，投稿郵箱: editor@hi-linux.com。