Metrics Server本身是以deployment方式部署,只需要配置多副本集到不同节点即可满足高可用,了解下Metrics Server背景和工作流程。
一、Metrics Server背景
kubernetesv1.11以后不再支持通过heaspter采集监控数据,支持新的监控数据采集组件metrics-server,比heaspter轻量很多,也不做数据的持久化存储,提供实时的监控数据查询还是很好用的。
1)metrics-server 通过 kube-apiserver 发现所有节点,然后调用 kubelet APIs(通过 https 接口)获得各节点(Node)和 Pod 的 CPU、Memory 等资源使用情况。从v1.8开始,资源使用情况的监控可以通过Metrics API的形式获取,具体的组件为Metrics-Server,用来替换之前的heapster,从 Kubernetes 1.12 开始,kubernetes 的安装脚本移除了 Heapster,从 1.13 开始完全移除了对 Heapster 的支持,Heapster 不再被维护。
2)Metrics-Server是集群核心监控数据的聚合器,从Kubernetes1.8开始,它作为一个Deployment对象默认部署在由kube-up.sh脚本创建的集群中;
3)kubernetes的新监控体系中,metrics-server属于Core metrics(核心指标),提供API-metrics.k8s.io
,主要作用为kube-scheduler,HorizontalPodAutoscaler等k8s核心组件,以及kubectl top命令和Dashboard等UI组件提供数据来源。
二、Metrics-Server在k8s监控体系中的位置
1)Metrics server定时从Kubelet的Summary API(类似/ap1/v1/nodes/nodename/stats/summary)采集指标信息,这些聚合过的数据将存储在内存中,且以metric-api的形式暴露出去;即metrics-server通过调用Kubelet Summary API获取采集核心指标数据,给k8s集群内的kubectl,hpa,scheduler等组件使用;
2)Metrics server复用了api-server的库来实现自己的功能,比如鉴权、版本等,为了实现将数据存放在内存中,去掉了默认的etcd存储,引入了内存存储(即实现Storage interface)。因为存放在内存中,因此监控数据是没有持久化的,可以通过第三方存储来拓展,这个和heapster是一致的;Metrics-server负责采集的核心指标数据,虽然是放在内存中但也是需要缓存的,所以使用emptyDIr存储卷,当然也可以使用持久存储卷;
3)如上图,Metrics server出现后,新的Kubernetes 监控架构将变成上图的样子:
(1)核心流程(黑色部分):这是Kubernetes正常工作所需要的核心度量,从Kubelet、cAdvisor等获取度量数据,再由metrics-server提供Dashboard、HPA控制器等使用;
(2)监控流程(蓝色部分):基于核心度量构建的监控流程,比如Prometheus可以从metrics-server获取核心度量,从其他数据源(如Node_Exporter等)获取非核心度量,再基于它们构建监控告警系统;
(3)Metric-Server属于kubenetes处于孵化的项目;它有两个组件:
Metrics API #提供resource定义,即自定义apiserver
Metrics server #定义背后resource资源定义是否合法
三、Metrics API的概念:
1)Metrics API相比于之前的监控采集方式(hepaster)是一种新的思路,官方希望核心指标的监控应该是稳定的,版本可控的,且可以直接被用户访问(例如通过使用 kubectl top 命令),或由集群中的控制器使用(如HPA),和其他的Kubernetes APIs一样;
2)官方废弃heapster项目,就是为了将核心资源监控作为一等公民对待,即像pod、service那样直接通过api-server或者client直接访问,不再是安装一个hepater来汇聚且由heapster单独管理;
3)假设每个pod和node我们收集10个指标,最新版本k8s官方文档描述中提到支持5000+节点,假设每个节点30个pod,假设采集粒度为1分钟一次,则:10 x 5000 x 30 / 60 = 25000 平均每分钟2万多个采集指标;
4)因为k8s的api-server将所有的数据持久化到了etcd中,k8s本身不能处理这种频率的采集,而且这种监控数据变化快且都是临时数据,因此需要有一个组件单独处理他们,k8s只存放部分在内存中,于是metric-server的概念诞生了;
5)其实hepaster已经有暴露了api,但是用户和Kubernetes的其他组件必须通过master proxy的方式才能访问到,且heapster的接口不像api-server一样,有完整的鉴权以及client集成;
6)有了Metrics Server组件,也采集到了该有的数据,也暴露了api,但因为api要统一,如何将请求到api-server的/apis/metrics请求转发给Metrics-Server呢,解决方案就是:kube-aggregator
,在k8s的1.7中已经完成,之前Metrics-Server一直没有面世,就是耽误在了kube-aggregator这一步(目前线上 1.14和1.15版本k8s集群部署了metrics-server组件);
kube-aggregator(聚合api)主要提供:
(1)Provide an API for registering API servers.
(2)Summarize discovery information from all the servers.
(3)Proxy client requests to individual servers.
7)metrics api的使用:
(1)Metrics API只可以查询当前的度量数据,并不保存历史数据
(2)Metrics API URI为/apis/metrics.k8s.io/
,在k8s.io/metrics维护
(3)必须部署metrics-server才能使用该 API,metrics-server通过调用Kubelet Summary API获取数据;
例如:
http://127.0.0.1:8080/apis/metrics.k8s.io/v1beta1/nodes
http://127.0.0.1:8080/apis/metrics.k8s.io/v1beta1/nodes/<node-name>
http://127.0.0.1:8080/apis/metrics.k8s.io/v1beta1/namespace/<namespace-name>/pods/<pod-name>
再结合kube-aggregator看下整体数据流转
使用kubectl top nodes
命令查看node节点cpu、memory资源使用情况时底层会请求apiserver的/apis/metric.k8s.io/v1beta1/
这个metrics-server提供的metric uri,这个uri时候会被aggregator聚合层proxy到 metrics-server 的endpoint。
在metrics-server官方部署参考中,metrics-sever以deployment形式部署,作为metrics-server svc的endpoint存在,对外以clusterip提供服务。所以metrics-server服务的高可用,保证集群内metrics-server多副本分散在不同节点部署即可。
如下图:
四、部署关键点
- 开启 API Aggregation
前面已经了解到要想使用metric api的调用会经过聚合层kube-aggregator的proxy所以在部署 metrics-server 之前,需要在 kube-apiserver 中开启 API Aggregation,即增加以下配置:
1 | --proxy-client-cert-file=/etc/kubernetes/certs/proxy.crt |
-
部署 metrics-server
Metrics-Server在Kubernetes集群中表现为一个Deployment对象。不过准确地说,它是Deployment,Service,ClusterRole,ClusterRoleBinding,APIService,RoleBinding资源对象的综合体
部署过程待补充 -
验证
- 检查metrics api是否正常
对
v1beta1.metrics.k8s.io
metrics api的请求会转发到kube-system/metrics-server
- 检查metrics-server deployment
1 | 注意:这里对应的node节点需要启动kube-proxy否则pod会一直crash |
这里会看到pod里面有两个容器,解释下两个容器作用:
1)metrcis-server:访问node10250端口获取node 和 pod cpu、memory使用情况
2) pod_nanny:Metrics Server的资源占用量会随着集群中的Pod数量的不断增长而不断上升,因此需要addon-resizer垂直扩缩这个容器。addon-resizer依据集群中节点的数量线性地扩展Metrics Server,以保证其能够有能力提供完整的metrics API服务,具体参考。
-
kubectl top验证
-
kubectl 访问metric api验证
-
node节点需要启动kebe-proxy,kube-proxy会监测svc变化动态更新iptables规则保证clusterip和pod的通信正常
分析节点iptables
1 | Generated by iptables-save v1.4.21 on Thu Dec 19 19:51:02 2019 |
这里面主要是对访问clusterip的数据包打标记做dnat和snat,因为我们网络模式是ospf的bridge,podip可以直通bondip,所以从metric-server pod出向数据包不需要snat,默认直接可以和master地址通信,简化后iptables:
1 | -A PREROUTING -d 192.168.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j DNAT --to-destination 10.96.101.31:6443 |
如果metric-server pod ip可固定的话,就不需要启动kube-proxy动态更新iptables。
- 查看metric-server组成
(1) metrics-server二进制程序
(2) 启动程序时候会生成访自签名证书用来访问节点summary/stats
(3) --kubelet-preferred-address-types=InternalIP 指定连接node节点时候使用nodeip连
这些启动参数在metrics-server yaml里面可以适当修改和适配
思考todo:
- 依据官方metrics-sever镜像重构加入ssh等工具包
- host网络模式部署metric-server
参考:
Resource Metrics API设计文档
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/resource-metrics-api.md
kube-aggregator 聚合层api设计文档:
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md
k8s监控体系设计文档:
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md
metrics-server设计文档:
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md
metric-server部署:
https://github.com/kubernetes-sigs/metrics-server#flags