本文翻譯自：https://sematext.com/blog/top-10-must-have-alerts-for-kubernetes/
執行 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/。