以下是我將要解釋的內容的概述：

• 事件機制
• Kubernetes API 中的事件結構
• 需要關注的事件類型
• 檢索事件的可用解決方案

在本文的最后，會鏈接到 YouTube 和 Github 上的相關教程，這樣你就可以直接學習如何收集和檢索 Kubernetes 事件。

Kubernetes 事件簡介

Kubernetes 會生成許多與我們的工作負載部署、調度等相關的事件。這是一個非常豐富的信息來源，可以幫助我們了解集群中正在發生的事情，即回答諸如“為什么這個特定的 pod 被殺死或重新啟動？”之類的問題。

有兩種方法可以查看 K8s 中的事件：

• kubectl describe pod
• kubectl get events

當應用程序出現問題時，您首先應該查看的是它的事件和它的基礎設施操作。將事件保留更長的時間也很有用，因為它們可以用于事后分析或了解故障是否是由早期事件引起的。

Kubernetes 中有多種類型的事件，因為每個 Kubernetes 對象都會經歷幾種狀態，直到達到所需的狀態。

主節點和工作節點有幾個核心組件，它們允許 K8s 在我們的“服務器”上編排工作負載。調度器在節點上調度 Pod，controller manager 檢測狀態變化以在 Pod 消失的情況下重建 Pod，而 etcd 將存儲各種 K8s 資源的狀態（但僅限于最后一小時）。

所有的這些核心組件都能夠根據事件編排我們的工作負載。這意味著事件對于理解特定情況很重要。

讓我們看一個簡單的例子：

部署 pod 時，調度程序會嘗試識別正確的節點來啟動 pod。同時，pod 將處于pending 狀態。一旦調度程序確定了正確的節點，pod 將處于creating 狀態。

要啟動這個 pod，我們首先需要拉取容器的鏡像。實際上，節點會從外部 docker 注冊表中拉取鏡像。調度程序還更傾向在已經擁有鏡像的節點上調度 pod。

拉取鏡像后，Pod 將處于running 狀態。

如果由于某種原因，pod 消失了，controller manager 將重新創建該 pod。

但是如果 Pod 已經多次重啟并出現相同的錯誤，Pod 將進入狀態CrashLoopBackOff。

如果 Pod 卡在 pending 狀態，則可能意味著節點上沒有可用資源，或者無法找到正確的節點。

Pod 通常有存活探針或就緒探針來幫助 K8s 確定您的 pod 的狀態或健康狀況，即 /health 或 /ready。Kubelet 會調用這些探針。

您還可以使用特定的鏡像定義一個 init 容器，以便 K8s 先執行完成該 init 容器，然后運行其他容器。

如果您在部署文件中提供了錯誤的鏡像，或者 docker 注冊表存在連接問題，則節點無法拉取鏡像，因此 Pod 將永遠不會達到 running 狀態。如果執行 describe 會看到ImagePullBackOff事件

Kubernetes API 中的事件

所有事件都可以在 Kubernetes API（也可以使用 kubectl）的幫助下檢索。通常，我們經常使用“ kubectl describe”來收集狀態、原因等。

與 API 交互時，您將收集：

• message
• reason
• type
• 事件中涉及的對象
• 事件發生次數
• 事件的來源

這正是使用kubectl get events看到的。

Kubernetes 事件有哪些類型？

   信息事件：Pods 調度，鏡像拉取，節點健康，deployment 更新，replica set 被調用，容器被殺死

   警告：Pod 有錯誤，PV 尚未綁定

   錯誤：節點已關閉，找不到 PV，無法在云提供商中創建負載均衡器等。

您可以使用 REST API、API 客戶端或 event recorder 直接發布您自己的事件。

最重要的 Kubernetes 事件

Kubernetes 有非常廣泛的事件，這里有一些需要重點考慮的事件：

• CrashLoopBackOff，當 Pod 啟動、崩潰、再次啟動、然后再次崩潰時發生
• ImagePullBackOff，當節點無法拉取鏡像時發生
• 驅逐事件，當節點確定需要驅逐或終止 pod 以釋放一些資源（CPU、內存等）時，可能會發生這種情況。發生這種情況時，K8s 應該在另一個節點上重新調度 pod。
• FailedMount / FailedAttachVolume，當 pod 需要持久卷或存儲時，如果存儲不可訪問，此事件會阻止它們啟動。
• FailedSchedulingEvents，當調度程序無法找到運行您的 pod 的節點時。
• NodeNotReady，當節點由于潛在問題而無法運行 pod 時。
• Rebooted
• HostPort 沖突

檢索 Kubernetes 事件的解決方案

有多種解決方案可用于檢索 Kubernetes 事件。讓我們看看現成可用的項目。

Eventrouter

正如 Eventrouter 項目的 GitHub 頁面所述：“事件路由器充當 Kubernetes 系統中事件資源的活動觀察者，它接收這些事件并將它們推送到用戶指定的接收器。這對于許多不同的目的很有用，但最值得注意的是對在 Kubernetes 集群上運行的工作負載的長期行為分析?！?

詳細信息請看 eventrouter[1] GitHub

Kubewatch

Kubewatch 是一個 K8s 事件監視工具，用于跟蹤 Kubewatch 中的每個資源更改。它支持通知，它將能夠在 Slack、Hipchat、Webhook、Flock、SMTP 等中發布通知。

詳細信息請看 kubewatch[2] GitHub

Sloop

Sloop 監控 Kubernetes，記錄事件和資源狀態變化的歷史，并提供可視化來幫助調試過去的事件。

詳細信息請看 sloop[3] GitHub

kubernetes-event-exporter

事件導出器允許將經常錯過的 Kubernetes 事件導出到各種輸出，以便它們可用于可觀察性或警報目的。

事件導出器實現起來很簡單，但功能非常強大。一旦事件被記錄，它利用 Prometheus 客戶端以 Prometheus 格式計數和報告事件。

詳細信息請看 kubernetes-event-exporter[4] GitHub

Kspan

Kspan 是 Weaveworks 創建的一個項目，它將 Kubernetes 事件轉換為 OpenTelemetry Spans，通過因果關系將它們連接起來，并將它們組合成 traces。

Kspan 將與 Kubernetes API 交互以收集各種事件并將生成的跟蹤轉發到 OpenTelemetry 收集器。

詳細信息請看 kspan[5] GitHub

Kubernetes 事件教程

現在我們已經大致了解了 Kubernetes 事件是什么以及如何利用它們，您可以在 YouTube 和 GitHub 上找到更詳細教程：

• YouTube：強大的 Kubernetes events[6]
• GitHub：Kspan 和 event exporter[7]