k8s-metrics的实现原理以及开发指南

所有的metrics相关的服务,都是通过kubelet的api获取相关的metric数据, 然后进行相关的存储(内存存储,golang map实现),然后提供对应的api给client端掉用(通常client端是通过kubernetes的metrics.kubernetes.io/v1beta1发起掉用的,当然也可以自己掉用metrics-server api), 其中metrics-server是k8s官方提供的一个metrics server端, 通过采集数据, 存在内存存储中

Metrics-server如何整合k8s api aggregator ?

kubernetes apiserver在启动的时候会启动kuberntes-aggregator服务, 该服务默认注册了一些apiservice. 并且是开启状态. 注册的service有很多很多, 比如 k8s原生的 v1版本的api , v1beta1等等,还有metrics.k8s.io/v1beta1. 格式如下:

{

“kind”: “APIService”,

“apiVersion”: “apiregistration.k8s.io/v1”,

“metadata”: {

“name”: “v1.apps”,

“selfLink”: “/apis/apiregistration.k8s.io/v1/apiservices/v1.apps”,

“uid”: “cdbad941-1e0a-11e9-a71c-b8830348f974”,

“resourceVersion”: “33”,

“creationTimestamp”: “2019-01-22T05:58:56Z”,

“labels”: {

“kube-aggregator.kubernetes.io/automanaged”: “onstart”

}

},

“spec”: {

“service”: null,

“group”: “apps”,

“version”: “v1”,

“groupPriorityMinimum”: 17800,

“versionPriority”: 15

},

“status”: {

“conditions”: [{

“type”: “Available”,

“status”: “True”,

“lastTransitionTime”: “2019-01-22T05:58:56Z”,

“reason”: “Local”,

“message”: “Local APIServices are always available”

}]

}

}

解释

当发送 /apis/metrics.k8s.io/v1beta1 时, 会掉用proxy方法代理到 kube-system/metrics-server这个service去处理这个service会返回对应的支持的metrics provider的name, 目前只有pods和nodes, 然后在发送/apis/metrics.k8s.io/v1beta1/pods或者nodes请求时, 会掉用proxy方法代理到 kube-system/metrics-server这个service对应的API路由进行处理, 这个api路由对应的handler就是metrics-server中对应的podprovider和nodeprovier中对应的方法.

以及custom.metrics.k8s.io/v1beta1

{

“kind”: “APIService”,

“apiVersion”: “apiregistration.k8s.io/v1”,

“metadata”: {

“name”: “v1beta1.custom.metrics.k8s.io”,

“selfLink”: “/apis/apiregistration.k8s.io/v1/apiservices/v1beta1.custom.metrics.k8s.io”,

“uid”: “de3b689f-34c9-11e9-a53e-b88303485096”,

“resourceVersion”: “172976727”,

“creationTimestamp”: “2019-02-20T04:42:03Z”,

“annotations”: {

“kubectl.kubernetes.io/last-applied-configuration”: “{“apiVersion”:“apiregistration.k8s.io/v1beta1”,“kind”:“APIService”,“metadata”:{“annotations”:{},“name”:“v1beta1.custom.metrics.k8s.io”,“namespace”:”"},“spec”:{“group”:“custom.metrics.k8s.io”,“groupPriorityMinimum”:100,“insecureSkipTLSVerify”:true,“service”:{“name”:“custom-metrics-apiserver”,“namespace”:“custom-metrics”},“version”:“v1beta1”,“versionPriority”:100}}\n"

}

},

“spec”: {

“service”: {

“namespace”: “custom-metrics”,

“name”: “custom-metrics-apiserver”

},

“group”: “custom.metrics.k8s.io”,

“version”: “v1beta1”,

“insecureSkipTLSVerify”: true,

“groupPriorityMinimum”: 100,

“versionPriority”: 100

},

“status”: {

“conditions”: [{

“type”: “Available”,

“status”: “True”,

“lastTransitionTime”: “2019-03-15T04:05:10Z”,

“reason”: “Passed”,

“message”: “all checks passed”

}]

}

}

解释

当发送 /apis/custom.metrics.k8s.io/v1beta1 时, 会掉用proxy方法代理到custom-metrics/custom-metrics-apiserver这个service去处理这个service会返回对应的支持的metrics provider的name, x 然后在发送/apis/metrics.k8s.io/v1beta1/providername请求时, 会掉用proxy方法代理到 kube-system/metrics-server这个service对应的API路由进行处理, 这个api路由对应的handler就是custom-metrics-apiserver中对应的provier中对应的方法.

关于官方metrics-server

Metrics 主要组件

Adepter

通过kubelet的summary api 采集数据,然后存储在 cache storage中(golang map实现).

pods provider

提供pods相关的数据的查询等方法

nodes provider

提供nodes相关的数据的查询等方法

http-server

​将nodes provider 和 pods provider的方法注册成http-server供client端掉用

metrics service实现总结

该总结适用于所有的metrics server, 不止官方的metric-server. 以及社区扩展的custom-metric-server.

总体来说分如下几部分组成:

数据采集器:

具体实现可以通过kubelet的summary接口采集, 也可以直接通过cadvisor的接口采集. 采集的周期最好是可配置化的.

数据的存储:

可以是自己实现外部的存储, 或者内存的存储. 如果用外部存储,最好用时间序列的数据库.

api:

提供各种指标数据的api提供给client端掉用, 如果可以的话, 最好提供对应的client-sdk.

最后是metrics-server(不止是官方的metrics -server, 包括自己开发的)部署:

部署分两种方式. 一种是通过kube-apiserver自己集群的kube-aggregator服务. 官方称此为gateway模式. 比较方便. 二是自己独立的部署编译之后的kube-aggregator服务, 然后在部署自己的metrics-server. 官方称此为单用户模式.