精品久久久久久无码中文字幕漫画 ,91成人在线免费观看,宅男视频网站无需下载

云原生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中；