Kubernetes每天可以生成數百萬個新指標。監控集群運行狀況很具挑戰性的方面之一是篩選收集和關注這些指標中的哪些很重要。下面介紹應該監控并為其創建警報的12個關鍵Kubernetes健

康指標。你所在的企業可能會略有不同，但是這12個是制定企業的Kubernetes監控策略的良好起點。

崩潰循環

崩潰循環是指Pod啟動，崩潰然后繼續嘗試重新啟動但無法恢復的時間(它不斷崩潰并以循環方式重新啟動)。發生這種情況時，應用程序無法運行。這可能是由于Pod中的應用程序崩潰導致

的，也可能是由于Pod中的配置錯誤或部署過程導致的，這使得調試崩潰循環變得非常棘手。當發生崩潰循環時，需要立即知道，弄清正在發生的事情以及是否需要采取緊急措施，保持應用程

序可用。

CPU利用率

CPU利用率只是節點使用的CPU周期數。進行監控非常重要，其原因有兩個。首先，你不希望耗盡應用程序的處理資源。如果應用程序受到CPU的限制，則需要增加CPU分配或向集群添加更多節

點。其次，你不希望CPU閑置。如果CPU使用率一直很低，則可能是資源過度分配，有可能浪費支出。

磁盤壓力

根據在Kubernetes配置中設置的閾值，磁盤壓力是表明節點使用過多磁盤空間或使用磁盤空間的速度過快的情況。這對于監控非常重要，因為如果應用程序合法需要更多空間，則可能意味著

需要添加更多磁盤空間。否則可能意味著應用程序行為異常。無論哪種方式，這種情況都需要引起注意。

內存壓力

內存壓力是另一種資源狀況，表明節點內存不足。類似于CPU資源配置，不想完全消耗內存資源，但也不想過度分配內存資源并浪費成本。那么需要注意這種情況，因為這可能意味著一個應用

程序中存在內存泄漏。

PID壓力

PID壓力是一種罕見的情況，在這種情況下，pod或容器會產生過多的進程，并使節點無法獲得可用的進程ID。每個節點具有有限數量的進程ID，從而在運行中的進程之間分配;如果ID用完了

，則無法啟動其他進程。Kubernetes允許為Pod設置PID閾值來限制其執行失控的流程生成的能力，并且PID壓力條件意味著一個或多個Pod耗盡了其分配的PID，需要進行檢查。

網絡不可用

所有的節點都需要網絡連接，并且其狀態表示節點的網絡連接有問題與否。要么沒有正確設置(由于路由耗盡或配置錯誤)，要么是與硬件的網絡連接存在物理問題。

Job失敗

Job的目的是在有限的時間內運行pod，并在完成預期的功能時將其拆解。如果Job由于節點崩潰或重新引導或資源耗盡而未能成功完成，則需要知道該Job已失敗。這就是為什么需要監控Job失

敗的原因。它們通常并不意味著應用程序不可訪問，但是如果未解決，則可能會導致問題。

持久卷故障

持久卷是在集群上指定的存儲資源，可用作任何請求它的Pod的持久存儲。在它們的生命周期中，它們綁定到一個容器，然后在該容器不再需要時回收。如果回收由于某種原因而失敗，那么需

要知道持久性存儲存在問題。

暫掛Pod的延遲時間

在pod的生命周期中，如果它正在等待在節點上進行調度，則其狀態為“待處理”。如果卡在“掛起”狀態，通常意味著沒有足夠的資源來安排和部署Pod。將需要更新CPU和內存分配，刪除

pod或向集群添加更多節點。

Deployment故障

Deployment用于管理無狀態應用程序-Pod是可互換的，不需要能夠到達任何特定的單個Pod，而只需到達特定類型的Pod即可。需要密切注意部署以確保它們正確完成。最好的方法是確保觀察

到的Deployment數量與所需的Deployment數量匹配。如果不匹配，則一個或多個Deployment失敗。

StatefulSets尚未就緒

StatefulSets用于管理有狀態的應用程序，其中的Pod具有特定的角色，需要到達其他特定的Pod。而不是像Deployment那樣只需要特定類型的Pod。但是，監控是相同的，需要確保觀察到的

StatefulSet的數量與所需的StatefulSet的數量匹配。如果存在不匹配，則一個或多個StatefulSet已失敗。

DaemonSets未準備好

DaemonSets用于管理需要在集群中所有節點上運行的服務或應用程序。如果你有要在每個節點上運行的日志收集daemon或監控服務，則需要使用DaemonSet。監控與Deployment相同：需要確保

觀察到的DaemonSet數量與所需的DaemonSet數量匹配。如果不匹配，則一個或多個DaemonSet失敗。

結語

像Kubernetes的大多數方面一樣，監控Kubernetes的運行狀況可能是一個復雜而具有挑戰性的過程，不容易下手。通過了解最需要關注的高價值健康狀況，至少可以開始制定策略，能夠過濾

掉集群所產生的大量數據“噪音”，并更加自信解決對確保良好體驗最重要的問題。