云原生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)}
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
资源进行增删改查操作。 ❞
从之前分析的服务发现协议接口设计得知,了解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
,让整个流程运转起来;
关键词: