五款強(qiáng)大的 Kubernetes Events 收集與檢索工具

2022-05-18 08:10:50

Kubernetes 可用于導(dǎo)出指標(biāo)、日志和事件以實(shí)現(xiàn)可觀察性。事件是了解服務(wù)中正在發(fā)生的事情的豐富信息來源，并且可以使用多種工具來充分利用它們。

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

事件機(jī)制
Kubernetes API 中的事件結(jié)構(gòu)
需要關(guān)注的事件類型
檢索事件的可用解決方案

在本文的最后，會(huì)鏈接到 YouTube 和 Github 上的相關(guān)教程，這樣你就可以直接學(xué)習(xí)如何收集和檢索 Kubernetes 事件。

Kubernetes 事件簡介

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

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

kubectl describe pod
kubectl get events

當(dāng)應(yīng)用程序出現(xiàn)問題時(shí)，您首先應(yīng)該查看的是它的事件和它的基礎(chǔ)設(shè)施操作。將事件保留更長的時(shí)間也很有用，因?yàn)樗鼈兛梢杂糜谑潞蠓治龌蛄私夤收鲜欠袷怯稍缙谑录鸬摹?

Kubernetes 中有多種類型的事件，因?yàn)槊總€(gè) Kubernetes 對(duì)象都會(huì)經(jīng)歷幾種狀態(tài)，直到達(dá)到所需的狀態(tài)。

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

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

讓我們看一個(gè)簡單的例子：

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

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

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

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

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

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

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

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

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

Kubernetes API 中的事件

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

與 API 交互時(shí)，您將收集：

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

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

Kubernetes 事件有哪些類型？

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

警告：Pod 有錯(cuò)誤，PV 尚未綁定

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

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

最重要的 Kubernetes 事件

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

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

檢索 Kubernetes 事件的解決方案

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

Eventrouter

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

詳細(xì)信息請(qǐng)看 eventrouter[1] GitHub