用Metrics Server對Kubernetes叢集實現全面資源監控

不知您是否使用過Prometheus、Azure Monitor、AWS Container Insight之類的可觀察性工具，或者是諸如Logic Monitor之類的商業產品，來監控Kubernetes叢集，並在儀表板上顯示CPU和記憶體等方面的資源指標?其實，Kubernetes具有一套內建的Metrics API和一個簡單的命令列查詢介面--kubectl top，可用於獲取某個Kubernetes物件的CPU和記憶體消耗狀況的快照。

可用於從叢集的Kubelets處收集資源使用資料的Kubernetes Metrics API，是一種依賴於Metrics Server叢集的插件。而Metrics API的主要使用者(consumer)是Horizontal Pod Autoscaler(HPA，)。它使用由Metrics API提供的指標，以及觀察到的資源狀態值，來縮放Pod的數量。除Metrics API之外，HPA還可從運行在群集上的應用程式(自定義的指標)和群集外的服務(外部指標)中，根據各項設定指標，以實現Pod的自動擴展。通常，外部應用會向HPA提供一些典型示例，包括：基於開源事件的、自動可伸縮性KEDA的服務，以及Logic Monitor。與HPA相似，依賴於Metrics Server的Vertical Pod Autoscaler(VPA，)也可以自動調整Pod中容器的CPU和記憶體的相關限制。

可見，自動縮放和監控是Metrics API和Metrics Server的兩個主要用例。要深入研究Kubernetes監控，我們勢必在叢集上部署Metrics Server。如果您正在運行AWS EKS叢集，那麼請參照EKS Metrics Server指南中的相關說明，在叢集上安裝Kubernetes Metrics Server。具體而言，您可以在終端上使用如下命令，來實現輕鬆的安裝：

Shell kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

在預設情況下，Azure AKS群集已經包括了Metrics Server的部署。因此，若要創建準系統(barebone)的AKS叢集，請在終端上執行如下AZ命令：

Shell az group create --name --location australiaeast az aks create -n --node-count 1 --node-vm-size Standard_B2s --load-balancer-sku basic --node-osdisk-size 32 --resource-group --generate-ssh-keys az aks get-credentials --resource-group --name

若要驗證Metrics Server部署的運行狀況，請執行如下命令：

Shell  kubectl get deployment metrics-server -n kube-system

我們需要在叢集上運行一個應用程式，以測試由Metrics Server實現的Metrics API的功效。為此，我們將Azure Voting App部署到該群集中。這是一個由Redis作為後端，以Python為前端的簡單應用。它的每個後端上都運行著一個Pod。我們可以通過執行如下終端命令，將該應用部署到目標叢集中：

Shell  kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/azure-voting-app-redis/master/azure-vote-all-in-one-redis.yaml

若要獲取應用程式前端的外部IP地址，請執行如下命令。值得注意的是，雲端環境可能需要等待一段時間，才能為您的服務分配一個外部IP地址：

Shell  kubectl describe services azure-vote-front | grep 'LoadBalancer Ingress'

現在，讓我們在叢集上運行一個功能齊全的應用。通過由上述命令獲得的IP地址，瀏覽器可以導航至應用程式的前端介面(如下圖所示)。

接下來，讓我們開始監控叢集中的各種物件，及其狀態指標。

監控節點

該端點的Metrics API是：/apis/metrics.k8s.io/。若要訪問該API，您可以：

• 通過使用如下命令實現埠轉發：

Shell  kubectl port-forward -n kube-system svc/metrics-server :443

• 使用kubectl的相關命令：

Shell  kubectl get --raw "/apis/metrics.k8s.io/v1beta1/" | jq '.'

下面，讓我們通過向/apis/metrics.k8s.io/v1beta1/端點發送GET請求(如下圖所示)，來檢查可用於通過API查詢的資源：

若要檢視叢集所有節點的各項指標的快照，請執行如下命令：

Shell kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes | jq '.'

下圖展示了終端上的命令輸出：

為了將請求的範圍縮小到單個節點上，我們可以向/apis/metrics.k8s.io/v1beta1/nodes/

監控Pods

如下面的命令所示，您可以通過分別向/apis/metrics.k8s.io/v1beta1/pods端點和/apis/metrics.k8s.io/v1beta1/pods/

Shell kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods | jq '.'

下圖展示了終端上有關叢集中Pod的狀況快照：

如果某個Pod由多個容器組成，那麼其API的響應將包含每個容器資源的統計資訊。您可以使用如下命令將請求定向到單個Pod上。

Shell kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/default/pods/<pod name>

Kubernetes的命令列介面：kubectl top

如果您覺得原始的Metrics API互動並不太方便，則可以使用Kubernetes命令列介面的相關命令--kubectl top(具體命令如下)，來檢視所有節點與Pod、以及特定節點與Pod的資源消耗統計資訊：

Shell kubectl top node kubectl top pods --all-namespaces

下圖展示了叢集中節點和容器的資源狀態快照：

監控容器

若要檢查某個Pod中各個容器所消耗的資源，請將參數—container新增到top命令中，如下面所示：

Shell kubectl top pods --all-namespaces --containers

提示：若要了解Kubernetes CLI命令的具體用法，請使用命令--kubectl help ，以快速獲取。例如，您可以直接輸入：kubectl help top。

用top瞭解容器內部

眾所周知，top是在Linux上廣為流行的命令，它可以方便使用者監控Linux上的不同程序、及其資源的使用情況。而且預設情況下，該命令已安裝在每一種Linux發行版上了。在此，我們可以借用該命令，來深入監控容器內部正在運行的各個程序。具體而言，我們可以將shell切入到一個正在運行的容器上，並以非互動模式運行top。請參見如下命令：

Shell kubectl exec <pod name> -- top -bn1

由於我們是在預設(default)名稱空間中，部署了應用示例Azure Vote App，因此我們將針對該應用程式中的每個pod，執行如下top命令：

Shell kubectl get pods -n default -o custom-columns=name:metadata.name --no-headers | xargs -I{} sh -c 'echo {}; kubectl exec {} -- top -bn1'

下圖展示了終端上輸出的執行結果：

具體輸出內容包括：

1. 系統時間、正常運行時間、以及使用者會話。

2. 用到的記憶體：RAM和Swap(磁碟的一部分，功能類似RAM)。

3. 在容器中運行的程序。

4. 基於各種程序花費的CPU時間，得出的CPU使用率。

5. 平均載入時間(如：1、5或15分鐘)。

6. 各項任務特徵，包括：程序ID、啟動程序的使用者、Nice值、優先順序、記憶體的消耗、程序的狀態、CPU時間、以及程序名稱。

監控Kubernetes狀態

Kube-state-metrics是一種服務，可用於偵聽Kubernetes API伺服器，並生成有關物件狀態(例如部署、節點和Pod)的狀態指標。當然，kube-state-metrics服務不會持久儲存資料，它僅通過提供一個測量端點，為所有請求物件的最新資料點提供服務。您可以使用諸如Prometheus之類的工具，來捕獲服務端點，並將資料永續性地儲存在永久性儲存中。

您可以通過GitHub上的相關文件，獲悉有關kube-state-metrics服務的背景知識，以及安裝與使用指南的更多資訊。值得注意的是，kube-state-metrics並不能替代Metrics Server。畢竟Metrics Server可以幫助使用者監控群集節點和Pod上的CPU與記憶體的使用情況。而kube-state-metrics服務則是協助使用者監控有關Pod、節點、以及其他Kubernetes物件的數量、運行狀況、以及可用性資訊等群集狀態。

小結

在本文中，我們學習瞭如何將Metrics Server安裝到叢集中，也探討了如何使用各個級別的監控命令，來獲悉Node、Pod和Container的資源使用情況。此外，我們還學習瞭如何使用Linux的top命令，來分析容器中的程序消耗資源的程度。最後，我們討論了kubernetes-state-metrics服務在監控Kubernetes物件狀態中發揮的作用，以及它與Metrics Server之間的關鍵性區別。