Kubernetes核心指標監控——Metrics Server

1、概述

從Kubernetes v1.8 開始，資源使用情況的監控可以通過 Metrics API的形式獲取，例如容器CPU和內存使用率。這些度量可以由用戶直接訪問（例如，通過使用kubectl top命令），或者由集群中的控制器（例如，Horizontal Pod Autoscaler）使用來進行決策，具體的組件為Metrics Server，用來替換之前的heapster，heapster從1.11開始逐漸被廢棄。

Metrics-Server是集群核心監控數據的聚合器。通俗地說，它存儲了集群中各節點的監控數據，並且提供了API以供分析和使用。Metrics-Server作為一個 Deployment對象默認部署在Kubernetes集群中。不過准確地說，它是Deployment，Service，ClusterRole，ClusterRoleBinding，APIService，RoleBinding等資源對象的綜合體。

項目地址：https://github.com/kubernetes-sigs/metrics-server ,目前穩定版本是v0.5.2。

metric-server主要用來通過aggregate api向其它組件（kube-scheduler、HorizontalPodAutoscaler、Kubernetes集群客戶端等）提供集群中的pod和node的cpu和memory的監控指標，彈性伸縮中的podautoscaler就是通過調用這個接口來查看pod的當前資源使用量來進行pod的擴縮容的。

需要注意的是：

• metric-server提供的是實時的指標（實際是最近一次采集的數據，保存在內存中），並沒有數據庫來存儲
• 這些數據指標並非由metric-server本身采集，而是由每個節點上的cadvisor采集，metric-server只是發請求給cadvisor並將metric格式的數據轉換成aggregate api
• 由於需要通過aggregate api來提供接口，需要集群中的kube-apiserver開啟該功能（開啟方法可以參考官方社區的文檔）

2、部署Metrics Server

2.1 下載並部署Metrics Server

下載部署清單：

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

修改部署清單內容：

[root@master1 metrics-server]# cat components.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: system:aggregated-metrics-reader
rules:
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  - nodes/stats
  - namespaces
  - configmaps
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    k8s-app: metrics-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --kubelet-insecure-tls
        image: k8s.gcr.io/metrics-server/metrics-server:v0.5.2
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /livez
            port: https
            scheme: HTTPS
          periodSeconds: 10
        name: metrics-server
        ports:
        - containerPort: 4443
          name: https
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readyz
            port: https
            scheme: HTTPS
          periodSeconds: 10
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
        volumeMounts:
        - mountPath: /tmp
          name: tmp-dir
      nodeSelector:
        kubernetes.io/os: linux
      priorityClassName: system-cluster-critical
      serviceAccountName: metrics-server
      volumes:
      - emptyDir: {}
        name: tmp-dir
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  labels:
    k8s-app: metrics-server
  name: v1beta1.metrics.k8s.io
spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: metrics-server
    namespace: kube-system
  version: v1beta1
  versionPriority: 100

在deploy中，spec.template.containers.args字段中加上--kubelet-insecure-tls選項，表示不驗證客戶端證書；上述清單主要用deploy控制器將metrics server運行為一個pod，然后授權metrics-server用戶能夠對pod/node資源進行只讀權限；然后把metrics.k8s.io/v1beta1注冊到原生apiserver上，讓其客戶端訪問metrics.k8s.io下的資源能夠被路由至metrics-server這個服務上進行響應；

應用資源清單：

[root@master1 metrics-server]# kubectl apply -f components.yaml
serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

2.2 驗證Metrics Server組件部署成功

（1）查看原生apiserver是否有metrics.k8s.io/v1beta1

[root@master1 metrics-server]# kubectl api-versions|grep metrics
metrics.k8s.io/v1beta1

可以看到metrics.k8s.io/v1beta1群組已經注冊到原生apiserver上。

（2）查看metrics server pod是否運行正常

[root@master1 ~]# kubectl get pods -n=kube-system |grep metrics
metrics-server-855cc6b9d-g6xsf    1/1     Running   0          18h

可以看到對應pod已經正常運行，接着查看pod日志，只要metrics server pod沒有出現錯誤日志，或者無法注冊等信息，就表示pod里的容器運行正常。

（3）使用kubectl top 命令查看pod的cpu ，內存占比，看看對應命令是否可以正常執行，如果Metrics Server服務有異常的話會報Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)錯誤。

[root@master1 ~]# kubectl top nodes
NAME      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
master1   272m         3%     4272Mi          29%       
node1     384m         5%     9265Mi          30%       
node2     421m         5%     14476Mi         48%   

可以看到kubectl top命令可以正常執行，說明metrics server 部署成功沒有問題。

3、原理

Metrics server定時從Kubelet的Summary API(類似/ap1/v1/nodes/nodename/stats/summary)采集指標信息，這些聚合過的數據將存儲在內存中，且以metric-api的形式暴露出去。

Metrics server復用了api-server的庫來實現自己的功能，比如鑒權、版本等，為了實現將數據存放在內存中嗎，去掉了默認的etcd存儲，引入了內存存儲（即實現Storage interface)。

因為存放在內存中，因此監控數據是沒有持久化的，可以通過第三方存儲來拓展。

來看下Metrics-Server的架構：

從 Kubelet、cAdvisor 等獲取度量數據，再由metrics-server提供給 Dashboard、HPA 控制器等使用。本質上metrics-server相當於做了一次數據的轉換，把cadvisor格式的數據轉換成了kubernetes的api的json格式。由此我們不難猜測，metrics-server的代碼中必然存在這種先從metric中獲取接口中的所有信息，再解析出其中的數據的過程。我們給metric-server發送請求時，metrics-server中已經定期從中cadvisor獲取好數據了，當請求發過來時直接返回緩存中的數據。

4、如何獲取監控數據

Metrics-Server通過kubelet獲取監控數據。

在1.7版本之前，k8s在每個節點都安裝了一個叫做cAdvisor的程序，負責獲取節點和容器的CPU，內存等數據；而在1.7版本及之后，k8s將cAdvisor精簡化內置於kubelet中，因此可直接從kubelet中獲取數據。

5、如何提供監控數據

Metrics-Server通過metrics API提供監控數據。

先說下API聚合機制，API聚合機制是kubernetes 1.7版本引入的特性，能將用戶擴展的API注冊至API Server上。

API Server在此之前只提供kubernetes資源對象的API，包括資源對象的增刪查改功能。有了API聚合機制之后，用戶可以發布自己的API，而Metrics-Server用到的metrics API和custom metrics API均屬於API聚合機制的應用。

用戶可通過配置APIService資源對象以使用API聚合機制(API聚合機制詳解請參考：Kubernetes APIService資源)，如下是metrics API的配置文件：

apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  service:
    name: metrics-server
    namespace: kube-system
  group: metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100

如上，APIService提供了一個名為v1beta1.metrics.k8s.io的API，並綁定至一個名為metrics-server的Service資源對象。

可以通過kubectl get apiservices命令查詢集群中的APIService。

因此，訪問Metrics-Server的方式如下：

            /apis/metrics.k8s.io/v1beta1  --->   metrics-server.kube-system.svc  --->   x.x.x.x

+---------+       +-----------+                   +------------------------+        +-----------------------------+
| 發起請求 +----->+ API Server +----------------->+ Service：metrics-server +-------->+ Pod：metrics-server-xxx-xxx |
+---------+       +-----------+                   +------------------------+        +-----------------------------+ 

有了訪問Metrics-Server的方式，HPA，kubectl top等對象就可以正常工作了。

6、總結

kubernetes的新監控體系中，metrics-server屬於Core metrics(核心指標)，提供API metrics.k8s.io，僅提供Node和Pod的CPU和內存使用情況。而其他Custom Metrics(自定義指標)由Prometheus等組件來完成，后續文章將對自定義指標進行解析。

參考：https://staight.github.io/2019/09/12/metrics-server%E6%B5%85%E8%B0%88/

參考：http://yost.top/2020/05/17/about-metric-server/

參考：https://yasongxu.gitbook.io/container-monitor/yi-.-kai-yuan-fang-an/di-1-zhang-cai-ji/metrics-server