云原生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采集模塊。

Discoverer定義的接口類型，不同的服務(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ō)明：

• api_server指定API Server地址，出于安全考慮，這些接口是帶有安全認(rèn)證的，bearer_token_file和ca_file則指定訪問(wèn)API Server使用到的認(rèn)證信息；

• role指定基于云原生集群中哪種對(duì)象類型做服務(wù)發(fā)現(xiàn)，支持POD、Service、Node、Endpoints、Endpointslice、Ingress六種類型；

• namespaces指定作用于哪個(gè)云原生命名空間下的對(duì)象，不配置則對(duì)所有的云原生命名空間生效；

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

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

??-?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ì)象類型對(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)聽這些對(duì)象的變化，去維護(hù)這份緩存，降低API Server的負(fù)載。除了ListWatch，Informer還可以注冊(cè)自定義事件處理邏輯，之后如果監(jiān)聽到事件變化就會(huì)調(diào)用對(duì)應(yīng)的用戶自定義事件處理邏輯，這樣就實(shí)現(xiàn)了用戶業(yè)務(wù)邏輯擴(kuò)展。

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

Informer機(jī)制本身比較復(fù)雜，這里先暫時(shí)不太具體說(shuō)明，只需要理解Prometheus使用Informer機(jī)制獲取和監(jiān)聽云原生資源對(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類似于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í)資源類型，包括："endpointslice", "endpoints", "node", "pod", "service", "ingress"五種類型；

event標(biāo)識(shí)事件類型，包括："add", "delete", "update"三種類型。

?

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

「更多云原生監(jiān)控運(yùn)維知識(shí)，請(qǐng)關(guān)注公眾號(hào)：Reactor2020」