一 资源监控
要扩展应用程序并提供可靠的服务，你需要了解应用程序在部署时的行为。 你可以通过检测容器检查 Kubernetes 集群中的应用程序性能， Pods, 服务 和整个集群的特征。 Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。 此信息使你可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。
在 Kubernetes 中，应用程序监控不依赖单个监控解决方案。 在新集群上，你可以使用资源度量或 完整度量管道来收集监视统计信息。
二 资源度量管道
资源指标管道提供了一组与集群组件，例如 Horizontal Pod Autoscaler 控制器以及 kubectl top 实用程序相关的有限度量。 这些指标是由轻量级的、短期、内存存储的 metrics-server 收集的， 通过 metrics.k8s.io 公开。
度量服务器发现集群中的所有节点，并且查询每个节点的 kubelet 以获取 CPU 和内存使用情况。 Kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。 kubelet 将每个 Pod 转换为其组成的容器，并在容器运行时通过容器运行时接口 获取各个容器使用情况统计信息。 kubelet 从集成的 cAdvisor 获取此信息，以进行旧式 Docker 集成。 然后，它通过 metrics-server Resource Metrics API 公开聚合的 pod 资源使用情况统计信息。 该 API 在 kubelet 的经过身份验证和只读的端口上的 /metrics/resource/v1beta1 中提供。
三 Metrics-Server部署
Metrics-Server是集群核心监控数据的聚合器，用来替换之前的heapster。
容器相关的 Metrics 主要来自于 kubelet 内置的 cAdvisor 服务，有了Metrics-Server之后，用户就可以通过标准的 Kubernetes API 来访问到这些监控数据。
Metrics API 只可以查询当前的度量数据，并不保存历史数据。
Metrics API URI 为 /apis/metrics.k8s.io/，在 k8s.io/metrics 维护。
必须部署 metrics-server 才能使用该 API，metrics-server 通过调用 Kubelet Summary API 获取数据。
Metrics Server 并不是 kube-apiserver 的一部分，而是通过 Aggregator 这种插件机制，在独立部署的情况下同 kube-apiserver 一起统一对外服务的。
kube-aggregator 其实就是一个根据 URL 选择具体的 API 后端的代理服务器。
1 镜像导入，上传
[root@server1 ~]# docker load -i metrics-server.tar
3fa01eaf81a5: Loading layer 70.8MB/70.8MB
eade1f59b7c7: Loading layer 6.656kB/6.656kB
f42d4f3f41f7: Loading layer 18.55MB/18.55MB
e7ad03a7fd89: Loading layer 47.26MB/47.26MB
b17c160cf0a8: Loading layer 2.048kB/2.048kB
0369974182df: Loading layer 47.26MB/47.26MB
Loaded image: reg.westos.org/library/metrics-server:v0.5.0
[root@server1 ~]# docker tag reg.westos.org/library/metrics-server:v0.5.0 reg.westos.org/library/metrics-server:v0.5.0
[root@server1 ~]# docker push reg.westos.org/library/metrics-server:v0.5.0
The push refers to repository [reg.westos.org/library/metrics-server]
0369974182df: Pushed
b17c160cf0a8: Pushed
e7ad03a7fd89: Pushed
f42d4f3f41f7: Pushed
eade1f59b7c7: Pushed
3fa01eaf81a5: Pushed
v0.5.0: digest: sha256:423a707ad740b4966e14c5d66cbc9960874212cacc438a01469e59a6b48074e6 size: 1578
2 Metrics-server部署
[root@server2 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
3 处理报错
3.1 部署后查看Metrics-server的Pod日志：
错误1：dial tcp: lookup server2 on 10.96.0.10:53: no such host
这是因为没有内网的DNS服务器，所以metrics-server无法解析节点名字。可以直接修改coredns的configmap，讲各个节点的主机名加入到hosts中，这样所有Pod都可以从CoreDNS中解析各个节点的名字。加入解析
3.2 报错2：x509: certificate signed by unknown authority
Metric Server 支持一个参数 --kubelet-insecure-tls，可以跳过这一检查，然而官方也明确说了，这种方式不推荐生产使用。
启用TLS Bootstrap 证书签发
在所有节点签发证书
[root@server2 metrics-server]# vim /var/lib/kubelet/config.yaml
[root@server2 metrics-server]# systemctl restart kubelet.service
[root@server2 metrics-server]# kubectl certificate approve csr-7t9q8
certificatesigningrequest.certificates.k8s.io/csr-7t9q8 approved
[root@server2 metrics-server]# kubectl certificate approve csr-rvgc4
certificatesigningrequest.certificates.k8s.io/csr-rvgc4 approved
[root@server2 metrics-server]# kubectl certificate approve csr-qgdn8
certificatesigningrequest.certificates.k8s.io/csr-qgdn8 approved
[root@server2 metrics-server]# kubectl certificate approve csr-t4p9j csr-tp6hm csr-tsmfw csr-v6wg6
certificatesigningrequest.certificates.k8s.io/csr-t4p9j approved
certificatesigningrequest.certificates.k8s.io/csr-tp6hm approved
certificatesigningrequest.certificates.k8s.io/csr-tsmfw approved
certificatesigningrequest.certificates.k8s.io/csr-v6wg6 approved
4 查看状态
[root@server2 metrics-server]# kubectl -n kube-system get pod
NAME READY STATUS RESTARTS AGE
coredns-7777df944c-fjqpt 1/1 Running 1 2d7h
coredns-7777df944c-hkr6d 1/1 Running 1 2d7h
etcd-server2 1/1 Running 1 2d7h
kube-apiserver-server2 1/1 Running 1 2d7h
kube-controller-manager-server2 1/1 Running 1 2d7h
kube-flannel-ds-c8rh9 1/1 Running 1 2d3h
kube-flannel-ds-dkrqb 1/1 Running 1 2d3h
kube-flannel-ds-plvgj 1/1 Running 1 2d3h
kube-proxy-2kx7v 1/1 Running 1 2d3h
kube-proxy-8n2dh 1/1 Running 1 2d7h
kube-proxy-vsxxj 1/1 Running 1 2d3h
kube-scheduler-server2 1/1 Running 1 2d7h
metrics-server-5567648887-42hjf 1/1 Running 0 17m
[root@server2 metrics-server]# kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes/server2"
{"kind":"NodeMetrics","apiVersion":"metrics.k8s.io/v1beta1","metadata":{"name":"server2","creationTimestamp":"2021-08-03T10:50:44Z","labels":{"beta.kubernetes.io/arch":"amd64","beta.kubernetes.io/os":"linux","kubernetes.io/arch":"amd64","kubernetes.io/hostname":"server2","kubernetes.io/os":"linux","node-role.kubernetes.io/control-plane":"","node-role.kubernetes.io/master":"","node.kubernetes.io/exclude-from-external-load-balancers":""}},"timestamp":"2021-08-03T10:50:03Z","window":"1m0s","usage":{"cpu":"195602383n","memory":"1101112Ki"}}
[root@server2 metrics-server]# kubectl top node
W0803 06:51:10.886728 3789 top_node.go:119] Using json format to get metrics. Next release will switch to protocol-buffers, switch early by passing --use-protocol-buffers flag
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
server2 186m 9% 1075Mi 61%
server3 44m 2% 511Mi 29%
server4 54m 2% 562Mi 32%