prometheus-adapter原理分析

原理分析

prometheus+prometheus-adapter的工作原理

prometheus通过聚合层扩展kubenetes API原理

聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。 要注册 API，用户必须添加一个 APIService 对象，用它来“申领” Kubernetes API 中的 URL 路径。 自此以后，聚合层将会把发给该 API 路径的所有内容 转发到已注册的 APIService。

总结原理如下：

• aggregatorServer 通过 APIServices 对象关联到某个 Service 来进行请求的转发，其关联的 Service 类型进一步决定了请求转发的形式。aggregatorServer 包括一个 GenericAPIServer 和维护自身状态的 Controller。其中 GenericAPIServer 主要处理 apiregistration.k8s.io 组下的 APIService 资源请求，而Controller包括：

• • apiserviceRegistrationController：负责根据 APIService 定义的 aggregated server service 构建代理，将CR的请求转发给后端的 aggregated server
  • availableConditionController：维护 APIServices 的可用状态，包括其引用 Service 是否可用等

• • autoRegistrationController：用于保持 API 中存在的一组特定的 APIServices
  • crdRegistrationController：负责将 CRD GroupVersions 自动注册到 APIServices 中

• • openAPIAggregationController：将 APIServices 资源的变化同步至提供的 OpenAPI 文档

• apiserviceRegistrationController 负责根据 APIService 定义的 aggregated server service 构建代理，将CR的请求转发给后端的 aggregated server。apiService 有两种类型：Local(Service为空)以及Service(Service非空)。apiserviceRegistrationController 负责对这两种类型 apiService 设置代理：Local 类型会直接路由给 kube-apiserver 进行处理；而Service类型则会设置代理并将请求转化为对 aggregated Service 的请求(proxyPath := "/apis/" + apiService.Spec.Group + "/" + apiService.Spec.Version)，而请求的负载均衡策略则是优先本地访问 kube-apiserver(如果service为kubernetes default apiserver service:443) =>通过 service ClusterIP:Port 访问(默认)或者通过随机选择 service endpoint backend 进行访问：

画图说明aggregator

prometheus-adapter源码分析

代码地址：ht