云原生kubernetes服務(wù)發(fā)現(xiàn)原理圖解

概述

上節(jié)分析了Prometheus服務(wù)發(fā)現(xiàn)核心流程（如下圖），Discoverer基于不同協(xié)議發(fā)現(xiàn)采集點(diǎn)，通過(guò)channel通知到updater協(xié)程，然后更新到discoveryManager結(jié)構(gòu)體trargets字段中，最終由sender協(xié)程將discoveryManager的targets字段數(shù)據(jù)發(fā)送給scrape采集模塊。

(相關(guān)資料圖)

Discoverer定義的接口類(lèi)型，不同的服務(wù)發(fā)現(xiàn)協(xié)議基于該接口進(jìn)行實(shí)現(xiàn)：

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協(xié)議配置

Prometheus本身就是作為云原生監(jiān)控出現(xiàn)的，所以對(duì)云原生服務(wù)發(fā)現(xiàn)支持具有天然優(yōu)勢(shì)。kubernetes_sd_configs服務(wù)發(fā)現(xiàn)協(xié)議核心原理就是利用API Server提供的Rest接口獲取到云原生集群中的POD、Service、Node、Endpoints、Endpointslice、Ingress等對(duì)象的元數(shù)據(jù)，并基于這些信息生成Prometheus采集點(diǎn)，并且可以隨著云原生集群狀態(tài)變更進(jìn)行動(dòng)態(tài)實(shí)時(shí)刷新。

? kubernetes云原生集群的POD、Service、Node、Ingress等對(duì)象元數(shù)據(jù)信息都被存儲(chǔ)到etcd數(shù)據(jù)庫(kù)中，并通過(guò)API Server組件暴露的Rest接口方式提供訪問(wèn)或操作這些對(duì)象數(shù)據(jù)信息。 ?

「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

配置說(shuō)明：

「為什么沒(méi)有配置api server信息也可以正常進(jìn)行服務(wù)發(fā)現(xiàn)？」

很多時(shí)候我們并不需要配置api server相關(guān)信息也可以進(jìn)行服務(wù)發(fā)現(xiàn)，如我們將上面示例簡(jiǎn)化如下寫(xiě)法：

- job_name: kubernetes-pod    kubernetes_sd_configs:    - role: pod      namespaces:        names:        - "test01"

一般Prometheus部署在監(jiān)控云原生集群上，從 Pod使用 Kubernetes API官方客戶端庫(kù)(client-go)提供了更為簡(jiǎn)便的方法：rest.InClusterConfig()。 API Server地址是從POD的環(huán)境變量KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT構(gòu)建出來(lái)， token以及 ca信息從POD固定的文件中獲取，因此這種場(chǎng)景下kubernetes_sd_configs中api_server和ca_file是不需要配置的。

? client-go是kubernetes官方提供的go語(yǔ)言的客戶端庫(kù)，go應(yīng)用使用該庫(kù)可以訪問(wèn)kubernetes的API Server，這樣我們就能通過(guò)編程來(lái)對(duì)kubernetes資源進(jìn)行增刪改查操作。 ?

Informer機(jī)制

從之前分析的服務(wù)發(fā)現(xiàn)協(xié)議接口設(shè)計(jì)得知，了解k8s服務(wù)發(fā)現(xiàn)協(xié)議入口在discovery/kubernetes.go的Run方法：

Run方法中switch羅列出不同role的處理邏輯，剛好和配置示例中role支持的六種云原生對(duì)象類(lèi)型對(duì)應(yīng)，只是基于不同的對(duì)象進(jìn)行服務(wù)發(fā)現(xiàn)，基本原理都是一致的。

云原生服務(wù)發(fā)現(xiàn)基本原理是訪問(wèn)API Server獲取到云原生集群資源對(duì)象，Prometheus與API Server進(jìn)行交互這里使用到的是client-go官方客戶端里的Informer核心工具包。Informer底層使用ListWatch機(jī)制，在Informer首次啟動(dòng)時(shí)，會(huì)調(diào)用List API獲取所有最新版本的資源對(duì)象，緩存在內(nèi)存中，然后再通過(guò)Watch API來(lái)監(jiān)聽(tīng)這些對(duì)象的變化，去維護(hù)這份緩存，降低API Server的負(fù)載。除了ListWatch，Informer還可以注冊(cè)自定義事件處理邏輯，之后如果監(jiān)聽(tīng)到事件變化就會(huì)調(diào)用對(duì)應(yīng)的用戶自定義事件處理邏輯，這樣就實(shí)現(xiàn)了用戶業(yè)務(wù)邏輯擴(kuò)展。

Informer機(jī)制工作流程如下圖：

Informer機(jī)制本身比較復(fù)雜，這里先暫時(shí)不太具體說(shuō)明，只需要理解Prometheus使用Informer機(jī)制獲取和監(jiān)聽(tīng)云原生資源對(duì)象，即上圖中只有「綠色框部分是自定義業(yè)務(wù)邏輯」，其它都是client-go框架informer工具包提供的功能。

這其中的關(guān)鍵就是注冊(cè)自定義AddFunc、DeleteFunc和UpdateFunc三種事件處理器，分別對(duì)應(yīng)增、刪、改操作，當(dāng)觸發(fā)對(duì)應(yīng)操作后，事件處理器就會(huì)被回調(diào)感知到。比如云原生集群新增一個(gè)POD資源對(duì)象，則會(huì)觸發(fā)AddFunc處理器，該處理器并不做復(fù)雜的業(yè)務(wù)處理，只是將該對(duì)象的key放入到Workqueue隊(duì)列中，然后Process Item組件作為消費(fèi)端，不停從Workqueue中提取數(shù)據(jù)獲取到新增POD的key，然后交由Handle Object組件，該組件通過(guò)Indexer組件提供的GetByKey()查詢到該新增POD的所有元數(shù)據(jù)信息，然后基于該POD元數(shù)據(jù)就可以構(gòu)建采集點(diǎn)信息，這樣就實(shí)現(xiàn)kubernetes服務(wù)發(fā)現(xiàn)。

「為什么需要Workqueue隊(duì)列？」

Resource Event Handlers組件注冊(cè)自定義事件處理器，獲取到事件時(shí)只是把對(duì)象key放入到Workerqueue中這種簡(jiǎn)單操作，而沒(méi)有直接調(diào)用Handle Object進(jìn)行事件處理，這里主要是避免阻塞影響整個(gè)informer框架運(yùn)行。如果Handle Object比較耗時(shí)放到Resource Event Handlers組件中直接處理，可能就會(huì)影響到④⑤功能，所以這里引入Workqueue類(lèi)似于MQ功能實(shí)現(xiàn)解耦。

源碼分析

熟悉了上面Informer機(jī)制，下面以role=POD為例結(jié)合Prometheus源碼梳理下上面流程。

1、創(chuàng)建和API Server交互底層使用的ListWatch工具；

2、基于ListWatch創(chuàng)建Informer；

3、注冊(cè)資源事件，分別對(duì)應(yīng)資源創(chuàng)建、資源刪除和資源更新事件處理；

? 這里的 podAddCount、podDeleteCount和podUpdateCount分別對(duì)應(yīng)下面三個(gè)指標(biāo)序列，指標(biāo)含義也比較明顯： 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標(biāo)識(shí)資源類(lèi)型，包括："endpointslice", "endpoints", "node", "pod", "service", "ingress"五種類(lèi)型； event標(biāo)識(shí)事件類(lèi)型，包括："add", "delete", "update"三種類(lèi)型。 ?

4、事件處理，AddFunc、DeleteFunc和UpdateFunc注冊(cè)的事件處理邏輯一樣，處理邏輯也比較簡(jiǎn)單：就是獲取資源對(duì)象key，并將其寫(xiě)入到Workqueue中；

? 對(duì)于POD資源，這里的key就是：namespace/pod_name格式，比如key=test01/nginx-deployment-5ffc5bf56c-n2pl8。 ?

5、給Workqueue注冊(cè)一個(gè)無(wú)限循環(huán)處理邏輯，就能持續(xù)從Workqueue中取出key進(jìn)行處理；

? 針對(duì)Pod里的每個(gè)Container上的每個(gè)port，都會(huì)生成一個(gè)對(duì)應(yīng)采集點(diǎn)target，其中__address__就是PodIP+port組合。 ?

6、最后啟動(dòng)Informer，讓整個(gè)流程運(yùn)轉(zhuǎn)起來(lái)；

關(guān)鍵詞：

責(zé)任編輯：Rex_24