本文翻譯自：https://sematext.com/blog/top-10-must-have-alerts-for-kuberne...

運行 Kubernetes 集羣，顯然不止是啓動，還需要持續監控，以確保 Kubernetes 中的服務能正常運行。

不過，您不想整天盯着一堆 Kubernetes 儀表板（即便儀表板再多麼美觀）。您希望使用適當的警報來設置 Kubernetes 警報，對嗎？

藉助 k8s 警報，您將快速發現 Kubernetes 集羣中的問題，並希望也能快速修復它們。那麼問題來了，最應該關注的警報有哪些？

1. 過高的 CPU 使用率

為什麼這很重要

當 Kubernetes Pod 超出其 CPU 限制時，將觸發此警報，表明可能存在資源爭用或資源分配效率低下。如果 CPU 限制不斷達到，則可能導致應用程序響應時間變慢和潛在的服務中斷。簡而言之，你不希望看到這種情況發生。

行動

調查受影響的 Pod，並考慮調整資源限制或優化應用程序。

使用以下命令檢查受影響 Pod 的 CPU 使用率：

kubectl top pod <pod_name> -n <namespace>

要調整 pod 的資源限制，請編輯其 YAML 配置文件：

kubectl edit pod <pod_name> -n <namespace>

在 YAML 文件中，修改“resources”部分以調整 CPU 限制：

resources:
  limits:
    cpu: <new_cpu_limit>

替換為所需的 CPU 限制值。

2. 已達到 CPU 使用限制

為什麼這很重要

與上一個警報類似，當 Pod 達到其 CPU 限制時，此警報會發出通知。

行動

分析工作負載的資源需求和擴展要求，以防止性能下降。

運行以下命令以獲取與受影響的 Pod 關聯的工作負載的 CPU 使用率指標：

kubectl top pod --selector=<selector> -n <namespace>

替換為工作負載的適當標籤選擇器，例如 app=，以聚合屬於工作負載的所有 Pod 的 CPU 使用情況。

3. Kubelet 卷管理器不可用

為什麼這很重要

kubelet 卷管理器故障可能會影響 pod 存儲，從而可能導致數據丟失。不可用的卷管理器可能會阻止掛載 Pod 卷，從而影響依賴於持久存儲的應用程序。

行動

調查 kubelet 服務和底層存儲基礎設施是否存在問題，並在必要時重新啓動受影響的組件。

運行以下命令以檢查 kubelet 服務的狀態：

kubectl get pods -n kube-system | grep kubelet

檢查 kubelet pod 的日誌，以識別與卷管理器相關的任何錯誤或警告：

kubectl logs <kubelet_pod_name> -n kube-system

檢查存儲卷和網絡連接的狀態：

kubectl get pv,pvc -n <namespace>

確保存儲卷已正確連接並由 kubelet 服務訪問。

如有必要，請重新啓動 kubelet 服務和任何相關組件。此命令強制 Kubernetes 重新創建 kubelet pod，希望能解決卷管理器的任何問題。

kubectl delete pod <kubelet_pod_name> -n kube-system

4. Kubernetes API 服務器錯誤

為什麼這很重要

監視來自 Kubernetes API 服務器的客户端錯誤 （4XX） 和服務器錯誤 （5XX），這可能表示通信問題或內部服務器問題。

行動

檢查網絡連接和 API 服務器日誌，以識別並解決根本問題。

驗證 Kubernetes API 服務器的狀態：

kubectl get pods -n kube-system | grep kube-apiserver

檢查日誌中是否存在與 API 服務器相關的錯誤或警告：

kubectl logs <kube-apiserver_pod_name> -n kube-system

檢查與 API 服務器的網絡連接：

kubectl cluster-info

5. Node Under Pressure

為什麼這很重要

當 Kubernetes 節點遇到資源壓力時發出警報，這可能會影響 Pod 調度和性能。

行動

監視 Kubernetes 節點上的資源，以確定承受壓力的部分：

kubectl describe node <node_name>

查找可能表明資源壓力過高的 CPU、內存或磁盤使用率。

查看節點上運行的工作負載，以識別資源密集的應用程序或容器：

kubectl get pods --all-namespaces -o wide

如果資源壓力持續存在，請考慮擴展 CPU、內存或存儲等資源：

kubectl scale node <node_name> --cpu=<new_cpu_capacity> --memory=<new_memory_capacity>

根據工作負載要求和可用節點容量調整資源限制。

將工作負載分佈在多個節點上，以緩解資源壓力：

kubectl drain <node_name> --ignore-daemonsets

6. 異常節點 CPU/內存 容量

為什麼這很重要

檢測 Kubernetes 節點何時使用比平時更多的 CPU 或內存，這可能意味着它們耗盡了資源或無法有效工作。

行動

檢查資源的使用方式隨時間推移，並在必要時更改節點容量或工作負載的分配方式。

監控 Kubernetes 節點上的 CPU 和內存使用情況：

kubectl top nodes

查看一段時間內的資源使用趨勢，以識別 CPU 和內存使用率的異常或峯值。

如果節點持續超出 CPU 或內存限制，請考慮縱向擴展節點容量：

kubectl scale node <node_name> --cpu=<new_cpu_capacity> --memory=<new_memory_capacity>

替換為受影響節點的名稱、 所需的 CPU 容量和所需的內存容量。

7. 缺少 Deployments/StatefulSet 的 Pod 副本

為什麼這很重要

當由 Deployments 或 StatefulSet 控制的 Pod 丟失時發出通知 ，指示部署失敗或 Pod 被驅逐。當缺少 Pod 時，這意味着應用程序的基本組件未按預期運行，這可能導致停機、性能不佳和數據丟失。 例如，如果您將集羣配置為具有 Pod 的 2 個副本，並且缺少其中一個副本，則您實際上正在運行 Pod 的單個實例，並且具有 SPOF（single point of failure 單點故障）並存在容錯問題。

行動

檢查 Deployment/Statefulset 配置和集羣事件，以診斷和解決部署問題。

檢查受影響的 Deployment 或 StatefulSet 的配置：

kubectl describe deployment <deployment_name> -n <namespace>

或：

kubectl describe statefulset <statefulset_name> -n <namespace>

查看所需的副本計數和當前副本計數，以確定是否存在任何差異。

查看集羣事件，以識別與丟失的 Pod 副本相關的任何事件：

kubectl get events -n <namespace>

查找指示 Pod 逐出或部署失敗的事件。

8. Pod 狀態問題

為什麼這很重要

檢查 Pod 狀態對於發現應用程序錯誤、資源不足或調度問題等問題非常重要。例如，如果 Pod 停滯在“等待”狀態，則可能表明由於缺少資源或配置問題而無法啓動。

行動

分析 Pod 日誌、事件和配置，以排查和解決影響 Pod 穩定性和性能的根本問題。

查看 Pod 的日誌以識別潛在的錯誤或問題：

kubectl logs <pod_name> -n <namespace>

檢查 Pod 事件以瞭解影響 Pod 狀態的最近更改或事件：

kubectl describe pod <pod_name> -n <namespace>

檢查容器的配置以驗證設置和資源分配：

kubectl describe pod <pod_name> -n <namespace>

9. Pod 重啓和失敗場景

為什麼這很重要

頻繁的 Pod 重啓、容器崩潰、鏡像拉取失敗或內存不足 （OOM） 錯誤可能會影響應用程序的可靠性和用户體驗，因此有效的 Kubernetes Pod 監控至關重要。想象一下，一個關鍵的微服務反覆遇到內存不足錯誤。這可能會導致停機時間延長，從而可能導致收入損失和客户不滿。沒有人想要那樣。

行動

如果 Pod 因為內存不足而不斷重啓，請查看其日誌以瞭解原因：

kubectl logs <pod_name> -n <namespace>

查找 Pod 重啓或失敗的模式，例如內存不足錯誤、容器崩潰或鏡像拉取失敗。

如果 Pod 由於資源限制而重新啓動，請考慮增加其資源限制：

kubectl edit pod <pod_name> -n <namespace>

10. ETCD leader 變化頻繁或無 leader

為什麼這很重要

監控 ETCD 集羣的運行狀況，在頻繁更換領導者或缺少領導者時發出警報，這可能會影響集羣的一致性和彈性。頻繁更換領導者或缺少領導者表明集羣通信或穩定性可能存在問題。就像在戀愛關係中一樣，Kubernetes 集羣中的良好溝通是其幸福的關鍵。😉

行動

調查 ETCD 集羣運行狀況、網絡連接和磁盤性能，以確保正常運行和穩定性。

檢查 ETCD 集羣的健康狀態並確定當前領導者：

etcdctl endpoint health --endpoints=<etcd_endpoints>

其中 <etcd_endpoints> 替換為你的 ETCD 集羣的端點。

監控 ETCD 集羣事件，瞭解領導者的頻繁變更：

etcdctl watch --prefix / --rev=<current_revision> --endpoints=<etcd_endpoints>

驗證 ETCD 節點之間的網絡連通性，並檢查 ETCD 節點上的磁盤性能，以防止 I/O 相關問題。

本文是 Flashcat 小夥伴翻譯整理，Flashcat 是一家監控/可觀測性創業公司，聯繫 Flashcat 做產品技術交流：https://flashcat.cloud/contact/。