k8s 中对资源的监控 -- 资源指标、Prometheus、弹性伸缩器 HPA

关于 Kubernetes 系列其他文章的传送门

一、k8s 扩展¶

如果内键的资源无法满足需求时，可以使用内键的 CRD 类型的资源创建出一个自定义资源类型，来扩展 k8s 的资源类型。然后使用自建的 CRD 就可以创建 CR 资源了。

CRD 示例：

-> # vim users-crd.yaml 

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: users.auth.ilinux.io
spec:
  group: auth.ilinux.io
  version: v1beta1
  names:
    kind: User
    plural: users
    singular: user
    shortNames:
    - u
  scope: Namespaced

二、k8s 资源指标¶

指标¶

核心指标：CPU、Memory、Disk，… 这些核心指标使用 Metrics-Server 组件就可以采集，比较轻量化；
自定义指标：除核心指标外，自定义的指标，由 Prometheus 实现。

关于 cAdvisor¶

在 kubelet 内部内键了一个指标采集接口组件 cAdvisor，专用于采集各种指标数据。

这个组件监听在 4194，只不过为了安全问题而默认关闭了。

可以在每个 Node 中部署一个 Pod，这个 Pod 负责从每个节点的 cAdvisor 接口去周期性的采集数据，并由这个 Pod 对外提供一个 API 接口，然后使用 kubectl top 命令可以向这个 API 发起查询请求，从而获得数据。

这个 Pod 的 API 分组默认是没有部署在 apiServer 中的，需要用户在 apiServer 中自行创建对应的 API service，从而使对这个 Pod 发起的 API 调用，经由 apiServer 内部的路由器调度至此 Pod。

关于 Prometheus¶

Prometheus 是个高性能的数据存储系统，可以原生监控 Kubernetes、节点和 Prometheus 本身，属于 CNCF 中的项目。

结合 Grafana 之后可以进行漂亮的展示，并内键了一个强大的查询接口 PromQL。

Prometheus 还能在每个 Node 上部署一个名为 nodeExporter 的组件，来专门实现节点级的更为完善的系统级采集，并能通过使用一个专用的 nodeExporter 来实现对一个复杂应用的数据采集，这些功能对于 cAdvisor 来说是无法完成的。

部署 Metrics-Server¶

项目官方地址

内部包含了两个组件：

Metrics API：提供资源的定义；
Metrics Server：提供规则检查以及控制器等；

目前 Metrics 版本：v0.3.6，支持 k8s v1.8 版本以上的，

部署清单：https://github.com/kubernetes-sigs/metrics-server/tree/master/deploy/1.8%2B

2021.01.03

项目的目录结构应该是变化了，部署清单的路径已经变为

部署清单：https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.6/components.yaml

而且部署方式应该是变化成了这样，还未实践：
1
>-> # kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.6/components.yaml

部署方式¶

-> # git clone https://github.com/kubernetes-sigs/metrics-server.git
-> # cd metrics-server        
-> # kubectl apply -f deploy/1.8+ 
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created
serviceaccount/metrics-server created
deployment.apps/metrics-server created
service/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created

查看对应资源是否被创建：

 # 针对这个 api 的访问，会被调度至。。。
-> # kubectl api-versions | grep metrics
metrics.k8s.io/v1beta1

 # 会被调度至这个 Service，而从这个 Service 关联到。。。
-> # kubectl get svc -n kube-system | grep metrics
metrics-server   ClusterIP   10.102.185.66   <none>        443/TCP                  2m7s

 # Service 关联到此 Pod
-> # kubectl get pods -n kube-system | grep metrics
metrics-server-795b774c76-d24ct              1/1     Running   0          3m25s

排错¶

问题 1：我们可以发现 Pod 中出现了一些错误信息：xxx: no such host，我们看到这个错误信息一般就可以确定是 DNS 解析不了造成的，我们可以看到 metrics-server 会通过 kubelet 的 10250 端口获取信息，使用的是 hostname，我们部署集群的时候在节点的 /etc/hosts 里面添加了节点的 hostname 和 ip 的映射，但是在我们的 metrics-server 的 Pod 内部并没有这个 hosts 信息，当然也就不识别 hostname 了。
问题 2：因为部署集群的时候，CA 证书并没有把各个节点的 IP 签上去，所以这里 metrics-server 通过 IP 去请求时，提示签的证书没有对应的 IP（错误：x509: cannot validate certificate for 192.168.33.11 because it doesn’t contain any IP SANs）。
解决方法：
- 问题 1：就是在 metrics-server 的启动参数中修改 kubelet-preferred-address-types 的参数；
- 问题 2：我们可以通过添加一个 --kubelet-insecure-tls 参数跳过证书校验，来解决问题。

更改配置文件：vim deploy/1.8+/metrics-server-deployment.yaml

2021.01.03

项目的目录结构应该是变化了，现在应该是：

先下载配置文件再更改：https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.6/components.yaml

...
...
- name: metrics-server
  image: k8s.gcr.io/metrics-server-amd64:v0.3.6
  args:
    - --cert-dir=/tmp
    - --secure-port=4443   # 在 args 参数中添加以下两行（不算此行）
    - --kubelet-preferred-address-types=InternalIP     # 解决问题 1
    - --kubelet-insecure-tls                           # 解决问题 2
...
...

重新 apply 一下：

1	-> # kubectl apply -f deploy/1.8+

使用 top 命令就能获取到 Nodes 和 Pods 的核心监控数据了：

-> # kubectl top nodes
NAME                 CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
master.monster.com   113m         5%     1123Mi          59%       
node1.monster.com    64m          1%     406Mi           17%       
node2.monster.com    67m          1%     417Mi           17%       
node3.monster.com    68m          1%     453Mi           19%       

-> # kubectl top pods -n kube-system
NAME                                         CPU(cores)   MEMORY(bytes)   
canal-87pq6                                  16m          53Mi            
canal-gx8tg                                  17m          52Mi            
canal-qz29q                                  19m          50Mi            
canal-r8hfn                                  18m          56Mi            
coredns-5644d7b6d9-8jrrg                     2m           14Mi            
coredns-5644d7b6d9-sh7gv                     2m           25Mi            
etcd-master.monster.com                      10m          78Mi            
kube-apiserver-master.monster.com            24m          356Mi           
kube-controller-manager-master.monster.com   9m           83Mi            
kube-flannel-ds-amd64-9xrsm                  2m           13Mi            
kube-flannel-ds-amd64-ddqhs                  2m           19Mi            
kube-flannel-ds-amd64-dzb8p                  2m           16Mi            
kube-flannel-ds-amd64-f6587                  2m           17Mi            
kube-proxy-fx5nt                             1m           23Mi            
kube-proxy-hmdmp                             1m           23Mi            
kube-proxy-ls99m                             4m           31Mi            
kube-proxy-n8r7f                             6m           22Mi            
kube-scheduler-master.monster.com            1m           35Mi            
metrics-server-6bc549fbb7-q2lqn              1m           13Mi

参考：https://www.qikqiak.com/post/install-metrics-server/

Metrics-Server 的工作方式¶

Metrics-Server 是作为一个 Pod 运行的，这个 Pod 自身通过一个 Service 向前端提供一个固定的访问入口，这个 Service 的名字就叫 Metrics-Server，那这个入口如做什么用的呢？

在 k8s 中，所有的请求都交给 apiServer 来接收并处理，而在 apiServer 内部，有一个叫做 kube-aggragator 的代理组件，当用户的请求到达 kube-aggragator 后，如果请求的 API 地址没有被注册为一个 api-service 的话，则会被通通代理至内部默认的核心 API Server，使用 kubeadm 部署的 k8s 会将 API Server 运行为一个 Pod。

而 Metrics-Server 是一个第三方的 API Server，也是以 Pod 的方式运行。如果想对这个 Pod 发起 apiServer 请求，需要在 kube-aggragetor 中额外注册一个 api-service 资源，并把请求自己 API 的流量，代理至后端运行的 Service 上，而后转给 Pod。

Prometheus 部署¶

Prometheus 的特点¶

高性能：内置了时序存储系统；
支持 PromQL 查询语言：给用户提供了非常强大的查询接口，从而获取到 Prometheus 内部采集到的就监控数据。
可视化：可以通过美观的第三方组件提供展示接口，比如 Grafana；
动态监控：通过服务发现机制，实现自动的添加或移除被监控模板，并结合 AlterManager 实现非常强大的报警功能；

指标分为两种：

系统级指标；
程序集指标；
业务数据。

监控方式：

需要在被监控的节点中，通过 node_exporter 进行输出，每个节点默认把监控数据推送给 PUSH Gateway，再由 Prometheus 从 PUSH Gateway 把数据给拉回去。
或者每一个被监控的节点，都自动的报告数据给 Prometheus。

采样点：

节点：部署一个 node_exporter，相当于一个 agent，采集本机的所有数据，并接收 Prometheus 的拉取操作。
cAdivisor（kubelet 的组成部分）：节点和容器及的指标数据；
apiServer：从 apiServer 获取性能数据；
etcd：认证到 etcd 直接获取数据。

Prometheus 的系统组件¶

kube-state-metrics：计数器，用于统计各自资源的数量信息；
node_exporter：从节点获取信息的 agent，需要在每个 Node 上以 DaemonSet 的方式部署；
Alertmanager：报警组件；
Prometheus-Server：主程序，通过各组件采集数据。
k8s-premetheus-adapter：自定义的指标服务器。Prometheus 的程序只提供了 PromQL 格式的接口，kubernetes 无法识别，而此组件的功能就是对 k8s 提供一个 Restful 风格的接口，然后把 k8s 的查询请求转换为 PromQL 并发给 Prometheus。而 HPAv2 就是通过自定义指标数据来获取数据的。

kube-prometheus 的 Github 站点

部署 kube-prometheus 方式¶

~]# git clone https://github.com/coreos/kube-prometheus.git
~]# kubectl create -f manifests/setup
~]# until kubectl get servicemonitors --all-namespaces ; do date; sleep 1; echo ""; done
~]# kubectl create -f manifests/

映射 Prometheus 的端口，之后可以通过 http://localhost:9090 来访问：

1	~]# kubectl --namespace monitoring port-forward svc/prometheus-k8s --address 0.0.0.0 9090:9090

映射 Grafana 的端口，之后可以通过 http://localhost:3000，使用 grafana 的默认用户名密码 admin:admin 来访问：

1	~]# kubectl --namespace monitoring port-forward svc/grafana --address 0.0.0.0 3000:3000

映射 Alert Manager 的端口，之后可以通过 http://localhost:9093：

1	~]# kubectl --namespace monitoring port-forward svc/alertmanager-main --address 0.0.0.0 9093:9093

三、指标监控的衍生应用 – HPA 水平 Pod 自动弹性伸缩器¶

HPA 是一个比 Deployment 更高级的控制器，它工作于 Deployment 之上。通过监视 Deployment 控制器，获取控制器下所有 Pod 的系统资源占用比例。

如果系统压力高于管理员定义的负载比例，会自动添加新的 Pod 进来，而当压力减小后，还能自动删除 Pod。也可以定义 Pod 数量的上下限。

HPA 分为两个版本 HPAv1 和 HPAv2，其中 v1 版依靠 Metrics-Server 只能获取到核心的监控指标 CPU 和内存，而 v2 版则从 Prometheus 获取监控数据，从而可以支持监控业务层面的指标。

HPAv1 使用的的 api 群组为 autoscaling
HPAv2 使用的的 api 群组为 autoscaling/v2beta2

HPAv1¶

创建 HPAv1 版本的 HAP 控制器时，直接在命令行使用 kubectl autoscale 命令即可创建：

--min=: 指定最少应该有几个 POD，可省略；
--max=: 最多有几个；
--cpu-percent=: CPU 利用率（百分比）为多少时开始使用扩展和缩减；

1 2	# 指定要监控的控制器类型为 deployment，名字为 myapp kubectl autoscale deployment myapp --min=2 --max=5 --cpu-percent=50

创建后使用 kubectl get hpa 可以查看。

怪兽和他的朋友们