【云原生 • Prometheus】云原生kubernetes服务发现原理图解
云原生kubernetes服务发现原理图解
概述
上节分析了Prometheus服务发现核心流程（如下图），Discoverer基于不同协议发现采集点，通过channel通知到updater协程，然后更新到discoveryManager结构体trargets字段中，最终由sender协程将discoveryManager的targets字段数据发送给scrape采集模块。
Discoverer定义的接口类型，不同的服务发现协议基于该接口进行实现：
(资料图片)
type Discoverer interface { // Run hands a channel to the discovery provider (Consul, DNS, etc.) through which // it can send updated target groups. It must return when the context is canceled. // It should not close the update channel on returning. Run(ctx context.Context, up chan<- []*targetgroup.Group)}k8s协议配置
Prometheus本身就是作为云原生监控出现的，所以对云原生服务发现支持具有天然优势。kubernetes_sd_configs服务发现协议核心原理就是利用API Server提供的Rest接口获取到云原生集群中的POD、Service、Node、Endpoints、Endpointslice、Ingress等对象的元数据，并基于这些信息生成Prometheus采集点，并且可以随着云原生集群状态变更进行动态实时刷新。
❝
kubernetes云原生集群的POD、Service、Node、Ingress等对象元数据信息都被存储到etcd数据库中，并通过API Server组件暴露的Rest接口方式提供访问或操作这些对象数据信息。 ❞
「kubernetes_sd_configs配置示例：」
- job_name: kubernetes-pod kubernetes_sd_configs: - role: pod namespaces: names: - "test01" api_server: https://apiserver.simon:6443 bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt配置说明：
api_server指定API Server地址，出于安全考虑，这些接口是带有安全认证的，bearer_token_file和ca_file则指定访问API Server使用到的认证信息；role指定基于云原生集群中哪种对象类型做服务发现，支持POD、Service、Node、Endpoints、Endpointslice、Ingress六种类型；namespaces指定作用于哪个云原生命名空间下的对象，不配置则对所有的云原生命名空间生效；「为什么没有配置api server信息也可以正常进行服务发现？」
很多时候我们并不需要配置api server相关信息也可以进行服务发现，如我们将上面示例简化如下写法：
- job_name: kubernetes-pod kubernetes_sd_configs: - role: pod namespaces: names: - "test01"一般Prometheus部署在监控云原生集群上，从 Pod使用 Kubernetes API官方客户端库(client-go)提供了更为简便的方法：rest.InClusterConfig()。 API Server地址是从POD的环境变量KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT构建出来， token以及 ca信息从POD固定的文件中获取，因此这种场景下kubernetes_sd_configs中api_server和ca_file是不需要配置的。
❝
client-go是kubernetes官方提供的go语言的客户端库，go应用使用该库可以访问kubernetes的API Server，这样我们就能通过编程来对kubernetes资源进行增删改查操作。 ❞
Informer机制
从之前分析的服务发现协议接口设计得知，了解k8s服务发现协议入口在discovery/kubernetes.go的Run方法：
Run方法中switch罗列出不同role的处理逻辑，刚好和配置示例中role支持的六种云原生对象类型对应，只是基于不同的对象进行服务发现，基本原理都是一致的。
云原生服务发现基本原理是访问API Server获取到云原生集群资源对象，Prometheus与API Server进行交互这里使用到的是client-go官方客户端里的Informer核心工具包。Informer底层使用ListWatch机制，在Informer首次启动时，会调用List API获取所有最新版本的资源对象，缓存在内存中，然后再通过Watch API来监听这些对象的变化，去维护这份缓存，降低API Server的负载。除了ListWatch，Informer还可以注册自定义事件处理逻辑，之后如果监听到事件变化就会调用对应的用户自定义事件处理逻辑，这样就实现了用户业务逻辑扩展。
Informer机制工作流程如下图：
Informer机制本身比较复杂，这里先暂时不太具体说明，只需要理解Prometheus使用Informer机制获取和监听云原生资源对象，即上图中只有「绿色框部分是自定义业务逻辑」，其它都是client-go框架informer工具包提供的功能。
这其中的关键就是注册自定义AddFunc、DeleteFunc和UpdateFunc三种事件处理器，分别对应增、删、改操作，当触发对应操作后，事件处理器就会被回调感知到。比如云原生集群新增一个POD资源对象，则会触发AddFunc处理器，该处理器并不做复杂的业务处理，只是将该对象的key放入到Workqueue队列中，然后Process Item组件作为消费端，不停从Workqueue中提取数据获取到新增POD的key，然后交由Handle Object组件，该组件通过Indexer组件提供的GetByKey()查询到该新增POD的所有元数据信息，然后基于该POD元数据就可以构建采集点信息，这样就实现kubernetes服务发现。
「为什么需要Workqueue队列？」
Resource Event Handlers组件注册自定义事件处理器，获取到事件时只是把对象key放入到Workerqueue中这种简单操作，而没有直接调用Handle Object进行事件处理，这里主要是避免阻塞影响整个informer框架运行。如果Handle Object比较耗时放到Resource Event Handlers组件中直接处理，可能就会影响到④⑤功能，所以这里引入Workqueue类似于MQ功能实现解耦。
源码分析
熟悉了上面Informer机制，下面以role=POD为例结合Prometheus源码梳理下上面流程。
1、创建和API Server交互底层使用的ListWatch工具；
2、基于ListWatch创建Informer；
3、注册资源事件，分别对应资源创建、资源删除和资源更新事件处理；
❝ 这里的
podAddCount、podDeleteCount和podUpdateCount分别对应下面三个指标序列，指标含义也比较明显：prometheus_sd_kubernetes_events_total(role="pod", event="add")prometheus_sd_kubernetes_events_total(role="pod", event="delete")prometheus_sd_kubernetes_events_total(role="pod", event="update")role标识资源类型，包括："endpointslice", "endpoints", "node", "pod", "service", "ingress"五种类型；event标识事件类型，包括："add", "delete", "update"三种类型。 ❞
4、事件处理，AddFunc、DeleteFunc和UpdateFunc注册的事件处理逻辑一样，处理逻辑也比较简单：就是获取资源对象key，并将其写入到Workqueue中；
❝ 对于
POD资源，这里的key就是：namespace/pod_name格式，比如key=test01/nginx-deployment-5ffc5bf56c-n2pl8。 ❞
5、给Workqueue注册一个无限循环处理逻辑，就能持续从Workqueue中取出key进行处理；
❝ 针对
Pod里的每个Container上的每个port，都会生成一个对应采集点target，其中__address__就是PodIP+port组合。 ❞
6、最后启动Informer，让整个流程运转起来；
