我創建了 Kube Eagle - 一個 Prometheus 導出器。 事實證明這是一件很酷的事情，有助於更好地了解中小型集群的資源。 最終，我節省了數百美元，因為我選擇了正確的機器類型並為工作負載配置了應用程式資源限制。
我會告訴你好處 ，但首先我將解釋是什麼引起了大驚小怪以及為什麼需要高品質的監控。
我管理了多個 4-50 個節點的叢集。 每個集群最多包含 200 個微服務和應用程式。 為了更好地利用現有硬件，大多數部署都配置了可突發的 RAM 和 CPU 資源。 這樣，Pod 可以在必要時取得可用資源，同時不會幹擾該節點上的其他應用程式。 嗯，不是很好嗎？
儘管叢集消耗的 CPU (8%) 和 RAM (40%) 相對較少，但當 Pod 嘗試分配比節點上可用的記憶體更多的記憶體時，我們經常會遇到被搶佔的問題。 當時我們只有一個儀表板來監控 Kubernetes 資源。 像這樣：
僅包含 cAdvisor 指標的 Grafana 儀表板
有了這樣的面板，看到消耗大量記憶體和CPU的節點都不是問題。 問題是要弄清楚原因是什麼。 為了保持 Pod 就位，當然可以在所有 Pod 上設定保證的資源（請求的資源等於限制）。 但這並不是硬體最明智的使用方式。 該叢集擁有數百 GB 的內存，而一些節點的內存不足，而其他節點則有 4-10 GB 的預留空間。
事實證明，Kubernetes 調度程式在可用資源上不均勻地分配工作負載。 Kubernetes 排程器考慮了不同的配置：關聯性、污點和容忍規則、可以限制可用節點的節點選擇器。 但就我而言，沒有這樣的情況，而 Pod 是根據每個節點上請求的資源來規劃的。
為 Pod 選擇空閒資源最多且符合請求條件的節點。 我們發現節點上請求的資源與實際使用情況不符，這就是 Kube Eagle 及其資源監控功能可以解決的問題。
我僅使用以下命令監控幾乎所有 Kubernetes 集群 и 。 Node Exporter 提供 I/O 和磁碟、CPU 和 RAM 使用情況的統計信息，而 Kube State Metrics 顯示 Kubernetes 物件指標，例如請求以及 CPU 和記憶體資源限制。
我們需要將使用指標與 Grafana 中的請求和限制指標結合起來，然後我們將獲得有關問題的所有資訊。 這聽起來很簡單，但是這兩個工具實際上對標籤的命名不同，而且某些指標根本沒有任何元資料標籤。 Kube Eagle 會自行完成所有操作，面板如下所示：
我們設法利用資源並節省設備解決了許多問題：
- 有些開發人員不知道微服務需要多少資源（或根本不關心）。 我們無法找到錯誤的資源請求 - 為此我們需要了解消耗情況以及請求和限制。 現在，他們可以查看 Prometheus 指標、監控實際使用情況並調整請求和限制。
- JVM 應用程式佔用它們能夠處理的盡可能多的 RAM。 垃圾收集器僅在使用超過 75% 時釋放記憶體。 而且由於大多數服務都有可突發的內存，因此它總是被 JVM 佔用。 因此，所有這些 Java 服務消耗的 RAM 都比預期多得多。
- 一些應用程式請求了太多內存，並且 Kubernetes 調度程序沒有將這些節點提供給其他應用程序，儘管實際上它們比其他節點更空閒。 一位開發人員不小心在請求中添加了一個額外的數字，並佔用了一大塊 RAM：20 GB，而不是 2。沒有人注意到。 該應用程式有 3 個副本，因此多達 3 個節點受到影響。
- 我們引入了資源限制，根據正確的要求重新安排 Pod，並在所有節點之間實現了硬體使用的理想平衡。 幾個節點可能已經完全關閉。 然後我們發現我們使用了錯誤的機器（面向 CPU，而不是面向記憶體）。 我們更改了類型並刪除了更多節點。
結果
透過叢集中的可突發資源，您可以更有效地使用可用硬件，但 Kubernetes 調度程式會根據資源請求來調度 Pod，這令人擔憂。 一舉兩得：為了避免問題並充分利用資源，需要良好的監控。 這就是為什麼它會很有用 （Prometheus 導出器和 Grafana 儀表板）。
來源： www.habr.com