以下是我將要解釋的內(nèi)容的概述：

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

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

Kubernetes 事件簡介

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

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

• kubectl describe pod
• kubectl get events

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

Kubernetes 中有多種類型的事件，因為每個 Kubernetes 對象都會經(jīng)歷幾種狀態(tài)，直到達到所需的狀態(tài)。

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

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

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

部署 pod 時，調(diào)度程序會嘗試識別正確的節(jié)點來啟動 pod。同時，pod 將處于pending 狀態(tài)。一旦調(diào)度程序確定了正確的節(jié)點，pod 將處于creating 狀態(tài)。

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

拉取鏡像后，Pod 將處于running 狀態(tài)。

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

但是如果 Pod 已經(jīng)多次重啟并出現(xiàn)相同的錯誤，Pod 將進入狀態(tài)CrashLoopBackOff。

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

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

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

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

Kubernetes API 中的事件

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

與 API 交互時，您將收集：

• message
• reason
• type
• 事件中涉及的對象
• 事件發(fā)生次數(shù)
• 事件的來源

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

Kubernetes 事件有哪些類型？

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

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

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

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

最重要的 Kubernetes 事件

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

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

檢索 Kubernetes 事件的解決方案

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

Eventrouter

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

詳細信息請看 eventrouter[1] GitHub

Kubewatch

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

詳細信息請看 kubewatch[2] GitHub

Sloop

Sloop 監(jiān)控 Kubernetes，記錄事件和資源狀態(tài)變化的歷史，并提供可視化來幫助調(diào)試過去的事件。

詳細信息請看 sloop[3] GitHub

kubernetes-event-exporter

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

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

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

Kspan

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

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

詳細信息請看 kspan[5] GitHub

Kubernetes 事件教程

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

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