如何更有效地利用和監測K8s資源
【編者的話】為了在Kubernetes叢集中更好的視覺化資源的利用率，作者開發了Kube Eagle普羅米修斯exporter，通過使用適當的機器型別和調整應用程式的資源約束，它們能夠更好地適應不同的工作負載。
我建立了一個名為Kube Eagle的普羅米修斯exporter（ exporter 是一組程式，它們分別被用來採集物理機、中介軟體的資訊。有prometheus官方實現的，還有更多第三方實現的），它被證明是一個很好的工具，可以在中小型叢集中獲得更多叢集資源的可見性。最終它幫助我節省了數百美元，通過使用適當的機器型別和調整應用程式的資源約束，使它們更好地適應我的工作負載。
在深入瞭解Kube Eagle的優點和特性之前，讓我先解釋一下用例，以及為什麼我們需要更好的監控。
我負責管理多個叢集，每個叢集有4到50個節點。叢集中有多大200個不同的為服務和應用程式，為了更有效地利用可用的硬體資源，這些部署中的大多數配置了可瞬間擴充套件的RAM和CPU資源。這樣，如果pods確實需要可用的資源，它們可能會佔用這些資源，但它們不會阻止其他應用程式在該節點上進行排程。聽起來很棒，不是嗎？
儘管我們的整個叢集CPU（8%）和RAM使用率（40%）相對較低，但我們經常面臨逐出pods的問題。這些pods被逐出，因為它們試圖分配比節點上可用的RAM更多的記憶體。當時，我們只有一個儀表板來監視Kubernetes資源，看起來如下所示:
只有使用cAdvisor指標的Grafana儀表板
使用這樣的儀表板，可以很容易地找到具有較高RAM和CPU使用率的節點，這樣我就可以快速識別過度使用的節點。無論如何，真正的鬥爭開始於你試圖尋找這一問題的根因並解決它。避免pods被驅逐的一種選項是為所有pods設定有保障的資源（請求和限制資源是平等的）。缺點是，這會導致更糟糕的硬體利用率。在叢集範圍內，我們有數百GB的記憶體可用，但一些節點顯然耗盡了RAM，而另一些節點仍然有4-10GB的空閒RAM。
顯然，Kubernetes排程程式沒有排程我們的工作負載，因此它們在我們的可用資源中都是平均分配的。Kubernetes排程程式必須尊重各種配置，比如親和規則、汙染（taints）和容忍、可能限制可用節點集合的節點選擇器。不過，在我的用例中，這些配置沒有到位。如果是這樣，則根據每個節點上請求的資源來排程pods。
選擇具有最無保留資源並能滿足所請求資源條件的節點來執行pods。對於我們的用例，這意味著我們節點上請求的資源與實際使用不一致，這就是Kube Eagle來拯救的地方，因為它為此目的提供了更好的資源監視。
我使用的大多數Kubernetes叢集只執行 node exporter 和 Kube State Metrics 來監視叢集。當node exporter報告有關磁碟使用情況、IO統計資訊、CPU和RAM使用情況的指標時，Kube State Metrics會公開有關Kubernetes物件的指標，例如請求並限制CPU/RAM資源。
我們需要將使用度量與Grafana中的資源請求和限制度量結合起來，以獲得解決問題的真正有價值的資訊。不幸的是，使用給定的兩個工具比聽起來要麻煩得多，因為標籤的名稱不同，而且一些度量標準缺少元資料標籤來輕鬆地組合和聚合它們。Kube Eagle為你做了這件事，這是基於它的度量建立的建議儀表板:
Kube Eagle儀表板( https://grafana.com/dashboards/9871 )
我們能夠用我們的資源識別和解決多個問題，這最終是我們節省了大量的硬體資源：
- 1、部署微服務的開發人員不知道他們的服務實際需要多少資源（或者根本不在乎）。我們沒有進行監視，以便很容易地識別配置錯誤的資源請求，因為這需要檢視資源請求和限制的使用情況。他們現在可以使用新提供的普羅米修斯度量來監視實際使用情況，並採用他們的資源請求和限制。
- 2、JVM應用程式需要儘可能多的RAM。垃圾收集器只在使用記憶體超過75%的情況下釋放記憶體。因為大多數服務在RAM中都是可儲存的，所以JVM總是使用它。因此，我們在所有這些Java服務上的RAM使用量比預期的要高得多。
- 3、有些應用程式的RAM請求太大，導致Kubernetes排程程式跳過所有其他應用程式的這些節點，儘管實際使用率低於其他所有節點。大型RAM請求是由開發人員意外導致的，開發人員以位元組指定資源請求，並意外地添加了另一個數字。20GB記憶體而不是2GB記憶體已經被請求，沒有人注意到它。應用程式有3個副本，因此有3個不同的節點受到過度分配的影響。
- 4、在採用了資源約束並用適當的請求重新安排了pods之後，我們在所有節點之間實現了相當均衡的硬體利用率。我們注意到我們可以因此關閉幾個節點，然後我們注意到我們使用的是錯誤的機器型別（CPU優化而不是高記憶體機器）。在改變機器型別後，我們可以再次排除和刪除更多的節點。
小結
叢集中的可擴充套件資源配置提供了更有效地利用可用硬體的好處，但它也可能早成麻煩，因為Kubernetes排程程式是根據資源請求進行pods排程的。為了在不遇到問題的情況下實現更好的容器利用率，你需要一個體面的監控解決方案。Kube Eagle（普羅米修斯exporter和它的Grafana儀表板）是為此目的而建立的，可以幫助你應對這一挑戰。
：：Mr.lzc，軟體工程師、DoD深圳核心組織者，目前供職於華為，從事雲端儲存工作，以Cloud Native方式構建雲檔案系統服務，專注於K8s、微服務領域。