用Metrics Server對Kubernetes集群實現全面資源監控
譯文【51CTO.com快譯】不知您是否使用過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(https://github.com/Azure-Samples/azure-voting-app-redis)部署到該群集中。這是一個由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
用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之間的關鍵性區別。
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
