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. 官方称此为单用户模式.