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

(資料圖片)

概述

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

Discoverer定義的接口類型，不同的服務(wù)發(fā)現(xiàn)協(xié)議基于該接口進行實現(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)}

復(fù)制

k8s協(xié)議配置

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

? kubernetes云原生集群的POD、Service、Node、Ingress等對象元數(shù)據(jù)信息都被存儲到etcd數(shù)據(jù)庫中，并通過API Server組件暴露的Rest接口方式提供訪問或操作這些對象數(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

復(fù)制

配置說明：

api_server指定API Server地址，出于安全考慮，這些接口是帶有安全認證的，bearer_token_file和ca_file則指定訪問API Server使用到的認證信息；role指定基于云原生集群中哪種對象類型做服務(wù)發(fā)現(xiàn)，支持POD、Service、Node、Endpoints、Endpointslice、Ingress六種類型；namespaces指定作用于哪個云原生命名空間下的對象，不配置則對所有的云原生命名空間生效；

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

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

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

復(fù)制

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

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

Informer機制

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

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

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

Informer機制工作流程如下圖：

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

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

「為什么需要Workqueue隊列？」

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

源碼分析

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

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

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

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

? 這里的 podAddCount、podDeleteCount和podUpdateCount分別對應(yīng)下面三個指標(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)識資源類型，包括："endpointslice", "endpoints", "node", "pod", "service", "ingress"五種類型； event標(biāo)識事件類型，包括："add", "delete", "update"三種類型。 ?

4、事件處理，AddFunc、DeleteFunc和UpdateFunc注冊的事件處理邏輯一樣，處理邏輯也比較簡單：就是獲取資源對象key，并將其寫入到Workqueue中；

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

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

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

6、最后啟動Informer，讓整個流程運轉(zhuǎn)起來；