1. Metrics Server

如果你對 Linux 系統(tǒng)有所了解的話，也許知道有一個命令 top 能夠?qū)崟r顯示當前系統(tǒng)的 CPU 和內(nèi)存利用率，它是性能分析和調(diào)優(yōu)的基本工具，非常有用。Kubernetes 也提供了類似的命令，就是 kubectl top，不過默認情況下這個命令不會生效，必須要安裝一個插件 Metrics Server 才可以。

Metrics Server 是一個專門用來收集 Kubernetes 核心資源指標（metrics）的工具，它定時從所有節(jié)點的 kubelet 里采集信息，但是對集群的整體性能影響極小，每個節(jié)點只大約會占用 1m 的 CPU 和 2MB 的內(nèi)存，所以性價比非常高。

下面的這張圖來自 Kubernetes 官網(wǎng)，你可以對 Metrics Server的工作方式有個大概了解：它調(diào)用 kubelet 的 API 拿到節(jié)點和 Pod 的指標，再把這些信息交給 apiserver，這樣 kubectl、HPA 就可以利用 apiserver 來讀取指標了：

在 Metrics Server 的項目網(wǎng)址（ https://github.com/kubernetes-sigs/metrics-server）可以看到它的說明文檔和安裝步驟，不過如果你已經(jīng)用 kubeadm 搭建了 Kubernetes 集群，就已經(jīng)具備了全部前提條件，接下來只需要幾個簡單的操作就可以完成安裝。

Metrics Server 的所有依賴都放在了一個 YAML 描述文件里，你可以使用 wget 或者 curl 下載：

wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

但是在 kubectl apply 創(chuàng)建對象之前，我們還有兩個準備工作要做。

第一個工作，是修改 YAML 文件。你需要在 Metrics Server 的 Deployment 對象里，加上一個額外的運行參數(shù) --kubelet-insecure-tls ，也就是這樣：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: metrics-server
  namespace: kube-system
spec:
  ... ... 
  template:
    spec:
      containers:
      - args:
        - --kubelet-insecure-tls
        ... ... 

這是因為 Metrics Server 默認使用 TLS 協(xié)議，要驗證證書才能與 kubelet 實現(xiàn)安全通信，而我們的實驗環(huán)境里沒有這個必要，加上這個參數(shù)可以讓我們的部署工作簡單很多（生產(chǎn)環(huán)境里就要慎用）。

第二個工作，是預先下載 Metrics Server 的鏡像?？催@個 YAML 文件，你會發(fā)現(xiàn) Metrics Server 的鏡像倉庫用的是 gcr.io下載很困難。好在它也有國內(nèi)的鏡像網(wǎng)站，下載后再改名，然后把鏡像加載到集群里的節(jié)點上。

給出一段 Shell 腳本代碼，供你參考：

repo=registry.aliyuncs.com/google_containers

name=registry.k8s.io/metrics-server/metrics-server:v0.6.3
src_name=metrics-server:v0.6.3

docker pull $repo/$src_name

docker tag $repo/$src_name $name
docker rmi $repo/$src_name

兩個準備工作都完成之后，我們就可以使用 YAML 部署 Metrics Server 了：

kubectl apply -f components.yaml

Metrics Server 屬于名字空間 kube-system，可以用 kubectl get pod 加上 -n 參數(shù)查看它是否正常運行：

現(xiàn)在有了 Metrics Server 插件，我們就可以使用命令 kubectl top 來查看 Kubernetes 集群當前的資源狀態(tài)了。它有兩個子命令，node 查看節(jié)點的資源使用率，pod 查看 Pod 的資源使用率。

由于 Metrics Server 收集信息需要時間，我們必須等一小會兒才能執(zhí)行命令，查看集群里節(jié)點和 Pod 狀態(tài)：

kubectl top node
kubectl top pod -n kube-system

從這個截圖里你可以看到：

• 集群里兩個節(jié)點 CPU 使用率都不高，分別是 3% 和 1%，但內(nèi)存用的很多，master 節(jié)點用了差不多一半（40%），而 worker 節(jié)點用滿（27%）。
• 名字空間 kube-system里有很多 Pod，其中 apiserver 最消耗資源，使用了 25m 的 CPU 和 259MB 的內(nèi)存。

2. HorizontalPodAutoscaler

有了 Metrics Server，我們就可以輕松地查看集群的資源使用狀況了，不過它另外一個更重要的功能是輔助實現(xiàn)應用的“水平自動伸縮”。

之前我們提到有一個命令 kubectl scale，可以任意增減 Deployment 部署的 Pod 數(shù)量，也就是水平方向的“擴容”和“縮容”。但是手動調(diào)整應用實例數(shù)量還是比較麻煩的，需要人工參與，也很難準確把握時機，難以及時應對生產(chǎn)環(huán)境中突發(fā)的大流量，所以最好能把這個“擴容”“縮容”也變成自動化的操作。

Kubernetes 為此就定義了一個新的 API 對象，叫做 HorizontalPodAutoscaler，簡稱是 hpa。顧名思義，它是專門用來自動伸縮 Pod 數(shù)量的對象，適用于 Deployment 和 StatefulSet，但不能用于 DaemonSet（原因很明顯吧）。

HorizontalPodAutoscaler 的能力完全基于 Metrics Server，它從 Metrics Server 獲取當前應用的運行指標，主要是 CPU 使用率，再依據(jù)預定的策略增加或者減少 Pod 的數(shù)量。

下面我們就來看看該怎么使用 HorizontalPodAutoscaler，首先要定義 Deployment 和 Service，創(chuàng)建一個 Nginx 應用，作為自動伸縮的目標對象：

# ngx-hpa-dep.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ngx-hpa-dep

spec:
  replicas: 1
  selector:
    matchLabels:
      app: ngx-hpa-dep

  template:
    metadata:
      labels:
        app: ngx-hpa-dep
    spec:
      containers:
      - image: nginx:alpine
        name: nginx
        ports:
        - containerPort: 80

        resources:
          requests:
            cpu: 50m
            memory: 10Mi
          limits:
            cpu: 100m
            memory: 20Mi
---

apiVersion: v1
kind: Service
metadata:
  name: ngx-hpa-svc
spec:
  ports:
  - port: 80	
    protocol: TCP
    targetPort: 80
  selector:
    app: ngx-hpa-dep

在這個 YAML 里只部署了一個 Nginx 實例，名字是 ngx-hpa-dep。

注意在它的 spec 里一定要用 resources 字段寫清楚資源配額，否則 HorizontalPodAutoscaler 會無法獲取 Pod 的指標，也就無法實現(xiàn)自動化擴縮容。

kubectl apply  -f ngx-hpa-dep.yml

接下來我們要用命令 kubectl autoscale 創(chuàng)建一個 HorizontalPodAutoscaler 的樣板 YAML 文件，它有三個參數(shù)：

• min：Pod 數(shù)量的最小值，也就是縮容的下限。
• max：Pod 數(shù)量的最大值，也就是擴容的上限。
• cpu-percent：CPU 使用率指標，當大于這個值時擴容，小于這個值時縮容。

好，現(xiàn)在我們就來為剛才的 Nginx 應用創(chuàng)建 HorizontalPodAutoscaler，指定 Pod 數(shù)量最少 2 個，最多 10 個，CPU 使用率指標設置的小一點，5%，方便我們觀察擴容現(xiàn)象：

export out="--dry-run=client -o yaml"              # 定義Shell變量
kubectl autoscale deploy ngx-hpa-dep --min=2 --max=10 --cpu-percent=5 $out

得到的 YAML 描述文件就是這樣：

# ngx-hpa.yml

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: ngx-hpa

spec:
  maxReplicas: 10
  minReplicas: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ngx-hpa-dep
  targetCPUUtilizationPercentage: 5

我們再使用命令 kubectl apply 創(chuàng)建這個 HorizontalPodAutoscaler 后，它會發(fā)現(xiàn) Deployment 里的實例只有 1 個，不符合 min 定義的下限的要求，就先擴容到 2 個：

從這張截圖里你可以看到，HorizontalPodAutoscaler 會根據(jù) YAML 里的描述，找到要管理的 Deployment，把 Pod 數(shù)量調(diào)整成 2 個，再通過 Metrics Server 不斷地監(jiān)測 Pod 的 CPU 使用率。

下面我們來給 Nginx 加上壓力流量，運行一個測試 Pod，使用的鏡像是“httpd:alpine”，它里面有 HTTP 性能測試工具 ab（Apache Bench）：

kubectl run test -it --image=httpd:alpine -- sh

然后我們向 Nginx 發(fā)送一百萬個請求，持續(xù) 1 分鐘，再用 kubectl get hpa 來觀察 HorizontalPodAutoscaler 的運行狀況：

ab -c 10 -t 60 -n 1000000 'http://ngx-hpa-svc/'

因為 Metrics Server 大約每 15 秒采集一次數(shù)據(jù)，所以 HorizontalPodAutoscaler 的自動化擴容和縮容也是按照這個時間點來逐步處理的。

當它發(fā)現(xiàn)目標的 CPU 使用率超過了預定的 5% 后，就會以 2 的倍數(shù)開始擴容，一直到數(shù)量上限，然后持續(xù)監(jiān)控一段時間，如果 CPU 使用率回落，就會再縮容到最小值。

3. Prometheus

顯然，有了 Metrics Server 和 HorizontalPodAutoscaler 的幫助，我們的應用管理工作又輕松了一些。不過，Metrics Server 能夠獲取的指標還是太少了，只有 CPU 和內(nèi)存，想要監(jiān)控到更多更全面的應用運行狀況，還得請出這方面的權威項目 Prometheus。

下面的這張圖是 Prometheus 官方的架構圖，

Prometheus 系統(tǒng)的核心是它的 Server，里面有一個時序數(shù)據(jù)庫 TSDB，用來存儲監(jiān)控數(shù)據(jù)，另一個組件 Retrieval 使用拉?。?code>Pull）的方式從各個目標收集數(shù)據(jù)，再通過 HTTP Server 把這些數(shù)據(jù)交給外界使用。

在 Prometheus Server 之外還有三個重要的組件：

• Push Gateway，用來適配一些特殊的監(jiān)控目標，把默認的 Pull 模式轉變?yōu)?Push 模式。
• Alert Manager，告警中心，預先設定規(guī)則，發(fā)現(xiàn)問題時就通過郵件等方式告警。
• Grafana 是圖形化界面，可以定制大量直觀的監(jiān)控儀表盤。

由于同屬于 CNCF，所以 Prometheus 自然就是“云原生”，在 Kubernetes 里運行是順理成章的事情。不過它包含的組件實在是太多，部署起來有點麻煩，這里我選用了 kube-prometheus項目（https://github.com/prometheus-operator/kube-prometheus/），感覺操作起來比較容易些。

我們先要下載 kube-prometheus 的源碼包，當前的最新版本是 0.11：

wget https://github.com/prometheus-operator/kube-prometheus/archive/refs/tags/v0.11.0.tar.gz

解壓縮后，Prometheus 部署相關的 YAML 文件都在 manifests 目錄里，有近 100 個，你可以先大概看一下。

和 Metrics Server 一樣，我們也必須要做一些準備工作，才能夠安裝 Prometheus。

第一步，是修改 prometheus-service.yaml、grafana-service.yaml。
這兩個文件定義了 Prometheus 和 Grafana 服務對象，我們可以給它們添加 type: NodePort（參考第 20 講），這樣就可以直接通過節(jié)點的 IP 地址訪問（當然你也可以配置成 Ingress）。

第二步，是修改 kubeStateMetrics-deployment.yaml、prometheusAdapter-deployment.yaml，因為它們里面有兩個存放在 gcr.io 的鏡像，必須解決下載鏡像的問題。

但很遺憾，我沒有在國內(nèi)網(wǎng)站上找到它們的下載方式，為了能夠順利安裝，只能把它們下載后再上傳到 Docker Hub 上。所以你需要修改鏡像名字，把前綴都改成 chronolaw：

image: k8s.gcr.io/kube-state-metrics/kube-state-metrics:v2.5.0
image: k8s.gcr.io/prometheus-adapter/prometheus-adapter:v0.9.1

image: chronolaw/kube-state-metrics:v2.5.0
image: chronolaw/prometheus-adapter:v0.9.1

這兩個準備工作完成之后，我們要執(zhí)行兩個 kubectl create 命令來部署 Prometheus，先是 manifests/setup 目錄，創(chuàng)建名字空間等基本對象，然后才是 manifests 目錄：

kubectl create -f manifests/setup
kubectl create -f manifests

Prometheus 的對象都在名字空間 monitoring里，創(chuàng)建之后可以用 kubectl get 來查看狀態(tài)：

確定這些 Pod 都運行正常，我們再來看看它對外的服務端口：

kubectl get svc -n monitoring

前面修改了 Grafana 和 Prometheus 的 Service 對象，所以這兩個服務就在節(jié)點上開了端口，Grafana 是“30358”，Prometheus 有兩個端口，其中“9090”對應的“30827”是 Web 端口。
在瀏覽器里輸入節(jié)點的 IP 地址（我這里是“http://192.168.10.210”），再加上端口號“30827”，我們就能看到 Prometheus 自帶的 Web 界面，：

Web 界面上有一個查詢框，可以使用 PromQL 來查詢指標，生成可視化圖表，比如在這個截圖里我就選擇了“node_memory_Active_bytes”這個指標，意思是當前正在使用的內(nèi)存容量。

Prometheus 的 Web 界面比較簡單，通常只用來調(diào)試、測試，不適合實際監(jiān)控。我們再來看 Grafana，訪問節(jié)點的端口“30358”（我這里是“http://192.168.10.210:30358”），它會要求你先登錄，默認的用戶名和密碼都是“admin”：
Grafana 內(nèi)部已經(jīng)預置了很多強大易用的儀表盤，你可以在左側菜單欄的“Dashboards - Browse”里任意挑選一個：

比如我選擇了“Kubernetes / Compute Resources / Namespace (Pods)”這個儀表盤，就會出來一個非常漂亮圖表，比 Metrics Server 的 kubectl top 命令要好看得多，各種數(shù)據(jù)一目了然：

4. 總結

1. Metrics Server 是一個 Kubernetes 插件，能夠收集系統(tǒng)的核心資源指標，相關的命令是 kubectl top。
2. Prometheus 是云原生監(jiān)控領域的“事實標準”，用 PromQL 語言來查詢數(shù)據(jù)，配合 Grafana 可以展示直觀的圖形界面，方便監(jiān)控。
3. HorizontalPodAutoscaler 實現(xiàn)了應用的自動水平伸縮功能，它從 Metrics Server 獲取應用的運行指標，再實時調(diào)整 Pod 數(shù)量，可以很好地應對突發(fā)流量。

Metrics Server 早期的數(shù)據(jù)來源是 cAdvisor，它是一個獨立的應用程序，后來被精簡集成進了 kubelet。

當前的 HorizontalPodAutoscaler 版本是 v2，除了支持 CPU 指標外也支持自定義指標，還有更多的可調(diào)節(jié)參數(shù)，但命令 kubectl autoscale 創(chuàng)建的樣板 yaml 默認用的是 v1。

通常來說運行 Grafana 要預先定于數(shù)據(jù)源，指定 Prometheus 地址，但 kube-prometheus 已經(jīng)把這些都配置好了，我們可以直接開箱即用。

Grafana 官網(wǎng)上有很多定義好的儀表盤，是一個類似 GitHub、DockerHub 的社區(qū)，可以任意下載，只需要輸入數(shù)字編號就可以把儀表盤導入到本地。文章來源地址http://www.zghlxwxcb.cn/news/detail-429794.html

到了這里，關于Kubernetes 筆記（17）— 系統(tǒng)監(jiān)控、使用Metrics Server、hpa 自動伸縮 Pod 數(shù)量、Prometheus 的使用的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！