使用ConfigMaps管理應用配置
當使用Deployment管理和部署應用程序時，用戶可以方便了對應用進行擴容或者縮容，從而產生多個Pod實例。為了 能夠統一管理這些Pod的配置信息，在Kubernetes中可以使用ConfigMaps資源定義和管理這些配置，並且通過環境 變量或者文件系統掛載的方式讓容器使用這些配置。 這里將使用ConfigMaps管理Prometheus的配置文件，創建prometheus-config.yml文件，並寫入以下內容：
apiVersion: v1 data: prometheus.yml: |- global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: ''prometheus'' static_configs: - targets: ['localhost:9090'] kind: ConfigMap metadata: name: prometheus-config
使用kubectl命令行工具，在命名空間default創建ConfigMap資源：
kubectl create -f prometheus-config.yml configmap "prometheus-config" created
使用Deployment部署Prometheus
當ConfigMap資源創建成功后，我們就可以通過Volume掛載的方式，將Prometheus的配置文件掛載到容器中。 這 里我們通過Deployment部署Prometheus Server實例，創建prometheus-deployment.yml文件，並寫入以下 內容:
apiVersion: v1 kind: "Service" metadata: name: prometheus labels: name: prometheus spec: ports: - name: prometheus protocol: TCP port: 9090 targetPort: 9090 selector: app: prometheus type: NodePort --- apiVersion: apps/v1 kind: Deployment metadata: labels: name: prometheus name: prometheus spec: replicas: 1 selector: matchLabels: app: prometheus template: metadata: labels: app: prometheus spec: serviceAccountName: prometheus serviceAccount: prometheus containers: - name: prometheus image: prom/prometheus:v2.2.1 command: - "/bin/prometheus" args: - "--config.file=/etc/prometheus/prometheus.yml" ports: - containerPort: 9090 protocol: TCP volumeMounts: - mountPath: "/etc/prometheus" name: prometheus-config volumes: - name: prometheus-config configMap: name: prometheus-config
該文件中分別定義了Service和Deployment，Service類型為NodePort，這樣我們可以通過虛擬機IP和端口訪問 到Prometheus實例。為了能夠讓Prometheus實例使用ConfigMap中管理的配置文件，這里通過volumes聲明了一 個磁盤卷。並且通過volumeMounts將該磁盤卷掛載到了Prometheus實例的/etc/prometheus目錄下。
使用以下命令創建資源，並查看資源的創建情況：
$ kubectl create -f prometheus-deployment.yml service "prometheus" created deployment "prometheus" created $ kubectl get pods NAME READY STATUS RESTARTS AGE prometheus-7f57d48b8d-fxm9j 1/1 Running 0 8m31s $ kubectl get svc [root@k8s-01 ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.1.0.1 <none> 443/TCP 29d prometheus NodePort 10.1.67.80 <none> 9090:30880/TCP 5h1m
至此，我們可以通過虛擬機的IP地址和端口3xxxx訪問到Prometheus的服務。
Kubernetes下的服務發現
目前為止，我們已經能夠在Kubernetes下部署一個簡單的Prometheus實例，不過當前來說它並不能發揮其監控系 統的作用，除了Prometheus，暫時沒有任何的監控采集目標。在第7章中，我們介紹了Prometheus的服務發現能 力，它能夠與通過與“中間代理人“的交互，從而動態的獲取需要監控的目標實例。而在Kubernetes下Prometheus 就是需要與Kubernetes的API進行交互，從而能夠動態的發現Kubernetes中部署的所有可監控的目標資源。
Kubernetes的訪問授權
為了能夠讓Prometheus能夠訪問收到認證保護的Kubernetes API，我們首先需要做的是，對Prometheus進行訪 問授權。在Kubernetes中主要使用基於角色的訪問控制模型(Role-Based Access Control)，用於管理 Kubernetes下資源訪問權限。首先我們需要在Kubernetes下定義角色（ClusterRole），並且為該角色賦予響應 的訪問權限。同時創建Prometheus所使用的賬號（ServiceAccount），最后則是將該賬號與角色進行綁定 （ClusterRoleBinding）。這些所有的操作在Kubernetes同樣被視為是一系列的資源，可以通過YAML文件進行 描述並創建，這里創建prometheus-rbac-setup.yml文件，並寫入以下內容：
apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: prometheus rules: - apiGroups: [""] resources: - nodes - nodes/proxy - services - endpoints - pods verbs: ["get", "list", "watch"] - apiGroups: - extensions resources: - ingresses verbs: ["get", "list", "watch"] - nonResourceURLs: ["/metrics"] verbs: ["get"] --- apiVersion: v1 kind: ServiceAccount metadata: name: prometheus namespace: default --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: prometheus roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: prometheus subjects: - kind: ServiceAccount name: prometheus namespace: default
其中需要注意的是ClusterRole是全局的，不需要指定命名空間。而ServiceAccount是屬於特定命名空間的資 源。通過kubectl命令創建RBAC對應的各個資源：
$ kubectl create -f prometheus-rbac-setup.yml clusterrole "prometheus" created serviceaccount "prometheus" created clusterrolebinding "prometheus" created
在完成角色權限以及用戶的綁定之后，就可以指定Prometheus使用特定的ServiceAccount創建Pod實例。修改 prometheus-deployment.yml文件，並添加serviceAccountName和serviceAccount定義：
spec: replicas: 1 selector: matchLabels: app: prometheus template: metadata: labels: app: prometheus spec: serviceAccountName: prometheus serviceAccount: prometheus
通過kubectl apply對Deployment進行變更升級：
$ kubectl apply -f prometheus-deployment.yml service "prometheus" configured deployment "prometheus" configured $ kubectl get pods NAME READY STATUS RESTARTS AGE prometheus-7f57d48b8d-n4sns 1/1 Running 0 4m19s
指定ServiceAccount創建的Pod實例中，會自動將用於訪問Kubernetes API的CA證書以及當前賬戶對應的訪問令 牌文件掛載到Pod實例的/var/run/secrets/kubernetes.io/serviceaccount/目錄下，可以通過以下命令進 行查看：
[root@k8s-01 ~]# kubectl exec -it prometheus-7f57d48b8d-n4sns ls /var/run/secrets/kubernetes.io/serviceaccount/ ca.crt namespace token
服務發現
在Kubernetes下，Promethues通過與Kubernetes API集成目前主要支持5種服務發現模式，分別是：Node、 Service、Pod、Endpoints、Ingress。
通過kubectl命令行，可以方便的獲取到當前集群中的所有節點信息：
- job_name: 'kubernetes-nodes' tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - role: node
通過指定kubernetes_sd_config的模式為node，Prometheus會自動從Kubernetes中發現到所有的node節點並 作為當前Job監控的Target實例。如下所示，這里需要指定用於訪問Kubernetes API的ca以及token文件路徑。
對於Ingress，Service，Endpoints, Pod的使用方式也是類似的，下面給出了一個完整Prometheus配置的示 例：
apiVersion: v1 data: prometheus.yml: |- global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'kubernetes-nodes' tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - role: node - job_name: 'kubernetes-service' tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - role: service - job_name: 'kubernetes-endpoints' tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - role: endpoints - job_name: 'kubernetes-ingress' tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - role: ingress - job_name: 'kubernetes-pods' tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - role: pod - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] kind: ConfigMap metadata: name: prometheus-config
更新Prometheus配置文件，並重建Prometheus實例：
1. $ kubectl apply -f prometheus-config.yml 2. configmap "prometheus-config" configured 3. 4. $ kubectl get pods 5. prometheus-69f9ddb588-rbrs2 1/1 Running 0 4m 6. 7. $ kubectl delete pods prometheus-69f9ddb588-rbrs2 8. pod "prometheus-69f9ddb588-rbrs2" deleted 9. 10. $ kubectl get pods 11. prometheus-69f9ddb588-rbrs2 0/1 Terminating 0 4m 12. prometheus-69f9ddb588-wtlsn 1/1 Running 0 14s
Prometheus使用新的配置文件重建之后，打開Prometheus UI，通過Service Discovery頁面可以查看到當前 Prometheus通過Kubernetes發現的所有資源對象了：
同時Prometheus會自動將該資源的所有信息，並通過標簽的形式體現在Target對象上。如下所示，是Promthues 獲取到的Node節點的標簽信息：
目前為止，我們已經能夠通過Prometheus自動發現Kubernetes集群中的各類資源以及其基本信息。不過，如果現 在查看Promtheus的Target狀態頁面，結果可能會讓人不太滿意：
雖然Prometheus能夠自動發現所有的資源對象，並且將其作為Target對象進行數據采集。 但並不是所有的資源對 象都是支持Promethues的，並且不同類型資源對象的采集方式可能是不同的。因此，在實際的操作中，我們需要有 明確的監控目標，並且針對不同類型的監控目標設置不同的數據采集方式。
接下來，我們將利用Promtheus的服務發現能力，實現對Kubernetes集群的全面監控。
使用Prometheus監控Kubernetes集群
下表中，梳理了監控Kubernetes集群監控的各個維度以及策略：
從Kubelet獲取節點運行狀態
Kubelet組件運行在Kubernetes集群的各個節點中，其負責維護和管理節點上Pod的運行狀態。kubelet組件的正 常運行直接關系到該節點是否能夠正常的被Kubernetes集群正常使用。
基於Node模式，Prometheus會自動發現Kubernetes中所有Node節點的信息並作為監控的目標Target。 而這些 Target的訪問地址實際上就是Kubelet的訪問地址，並且Kubelet實際上直接內置了對Promtheus的支持。
修改prometheus.yml配置文件，並添加以下采集任務配置：
- job_name: 'kubernetes-kubelet' scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - role: node relabel_configs: - action: labelmap regex: __meta_kubernetes_node_label_(.+) - target_label: __address__ replacement: kubernetes.default.svc:443 - source_labels: [__meta_kubernetes_node_name] regex: (.+) target_label: __metrics_path__ replacement: /api/v1/nodes/${1}/proxy/metrics
通過獲取各個節點中kubelet的監控指標，用戶可以評估集群中各節點的性能表現。例如,通過指標 kubelet_pod_start_latency_microseconds可以獲得當前節點中Pod啟動時間相關的統計數據。
kubelet_pod_start_latency_microseconds{quantile="0.99"}
Pod平均啟動時間大致為42s左右（包含鏡像下載時間）：
kubelet_pod_start_latency_microseconds_sum / kubelet_pod_start_latency_microseconds_count
除此以外，監控指標kubeletdocker*還可以體現出kubelet與當前節點的docker服務的調用情況，從而可以反映 出docker本身是否會影響kubelet的性能表現等問題。
從Kubelet獲取節點容器資源使用情況
各節點的kubelet組件中除了包含自身的監控指標信息以外，kubelet組件還內置了對cAdvisor的支持。 cAdvisor能夠獲取當前節點上運行的所有容器的資源使用情況，通過訪問kubelet的/metrics/cadvisor地址可 以獲取到cadvisor的監控指標，因此和獲取kubelet監控指標類似，這里同樣通過node模式自動發現所有的 kubelet信息，並通過適當的relabel過程，修改監控采集任務的配置。 與采集kubelet自身監控指標相似：
- job_name: 'kubernetes-cadvisor' scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - role: node relabel_configs: - target_label: __address__ replacement: kubernetes.default.svc:443 - source_labels: [__meta_kubernetes_node_name] regex: (.+) target_label: __metrics_path__ replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor - action: labelmap regex: __meta_kubernetes_node_label_(.+)
使用NodeExporter監控集群資源使用情況
為了能夠采集集群中各個節點的資源使用情況，我們需要在各節點中部署一個Node Exporter實例。在本章的“部署 Prometheus”小節，我們使用了Kubernetes內置的控制器之一Deployment。Deployment能夠確保Prometheus 的Pod能夠按照預期的狀態在集群中運行，而Pod實例可能隨機運行在任意節點上。而與Prometheus的部署不同的 是，對於Node Exporter而言每個節點只需要運行一個唯一的實例，此時，就需要使用Kubernetes的另外一種控制 器Daemonset。顧名思義，Daemonset的管理方式類似於操作系統中的守護進程。Daemonset會確保在集群中所有 （也可以指定）節點上運行一個唯一的Pod實例。
創建node-exporter-daemonset.yml文件，並寫入以下內容：
apiVersion: apps/v1 kind: DaemonSet metadata: name: node-exporter spec: selector: matchLabels: app: node-exporter template: metadata: annotations: prometheus.io/scrape: 'true' prometheus.io/port: '9100' prometheus.io/path: 'metrics' labels: app: node-exporter name: node-exporter spec: containers: - image: prom/node-exporter imagePullPolicy: IfNotPresent name: node-exporter ports: - containerPort: 9100 hostPort: 9100 name: scrape hostNetwork: true hostPID: true
由於Node Exporter需要能夠訪問宿主機，因此這里指定了hostNetwork和hostPID，讓Pod實例能夠以主機網絡 以及系統進程的形式運行。同時YAML文件中也創建了NodeExporter相應的Service。這樣通過Service就可以訪 問到對應的NodeExporter實例。
$ kubectl create -f node-exporter-daemonset.yml service "node-exporter" created daemonset "node-exporter" created
查看Daemonset以及Pod的運行狀態
$ kubectl get daemonsets NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE node-exporter 1 1 1 1 1 <none> 15s $ kubectl get pods NAME READY STATUS RESTARTS AGE ... node-exporter-9h56z 1/1 Running 0 51s
由於Node Exporter是以主機網絡的形式運行，因此直接訪問虛擬機IP加上Pod的端口即可訪問當前節 點上運行的Node Exporter實例:
[root@k8s-01 ~]# curl http://k8s-02:9100/metrics |head % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0# HELP go_gc_duration_seconds A summary of the GC invocation durations. # TYPE go_gc_duration_seconds summary go_gc_duration_seconds{quantile="0"} 1.7503e-05 go_gc_duration_seconds{quantile="0.25"} 2.9973e-05 go_gc_duration_seconds{quantile="0.5"} 5.2475e-05 go_gc_duration_seconds{quantile="0.75"} 8.2703e-05 go_gc_duration_seconds{quantile="1"} 0.001951054 go_gc_duration_seconds_sum 0.067789147 go_gc_duration_seconds_count 834 # HELP go_goroutines Number of goroutines that currently exist. 100 44764 0 44764 0 0 1207k 0 --:--:-- --:--:-- --:--:-- 1248k
目前為止，通過Daemonset的形式將Node Exporter部署到了集群中的各個節點中。接下來，我們只需要通過 Prometheus的pod服務發現模式，找到當前集群中部署的Node Exporter實例即可。 需要注意的是，由於 Kubernetes中並非所有的Pod都提供了對Prometheus的支持，有些可能只是一些簡單的用戶應用，為了區分哪些 Pod實例是可以供Prometheus進行采集的，這里我們為Node Exporter添加了注解：
prometheus.io/scrape: 'true'
由於Kubernetes中Pod可能會包含多個容器，還需要用戶通過注解指定用戶提供監控指標的采集端口：
prometheus.io/port: '9100'
而有些情況下，Pod中的容器可能並沒有使用默認的/metrics作為監控采集路徑，因此還需要支持用戶指定采集路 徑：
prometheus.io/path: 'metrics'
為Prometheus創建監控采集任務kubernetes-pods，如下所示：
- job_name: 'kubernetes-pods' kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+) - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 target_label: __address__ - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - source_labels: [__meta_kubernetes_namespace] action: replace target_label: kubernetes_namespace - source_labels: [__meta_kubernetes_pod_name] action: replace target_label: kubernetes_pod_name
通過以上relabel過程實現對Pod實例的過濾，以及采集任務地址替換，從而實現對特定Pod實例監控指標的采集。需 要說明的是kubernetes-pods並不是只針對Node Exporter而言，對於用戶任意部署的Pod實例，只要其提供了對 Prometheus的支持，用戶都可以通過為Pod添加注解的形式為其添加監控指標采集的支持。
從kube-apiserver獲取集群運行監控指標
在開始正式內容之前，我們需要先了解一下Kubernetes中Service是如何實現負載均衡的，如下圖所示，一般來說 Service有兩個主要的使用場景：
代理對集群內部應用Pod實例的請求：當創建Service時如果指定了標簽選擇器，Kubernetes會監聽集群中所 有的Pod變化情況，通過Endpoints自動維護滿足標簽選擇器的Pod實例的訪問信息；
代理對集群外部服務的請求：當創建Service時如果不指定任何的標簽選擇器，此時需要用戶手動創建 Service對應的Endpoint資源。例如，一般來說，為了確保數據的安全，我們通常講數據庫服務部署到集群 外。 這是為了避免集群內的應用硬編碼數據庫的訪問信息，這是就可以通過在集群內創建Service，並指向外 部的數據庫服務實例。
kube-apiserver扮演了整個Kubernetes集群管理的入口的角色，負責對外暴露Kubernetes API。kubeapiserver組件一般是獨立部署在集群外的，為了能夠讓部署在集群內的應用（kubernetes插件或者用戶應用）能 夠與kube-apiserver交互，Kubernetes會默認在命名空間下創建一個名為kubernetes的服務，如下所示：
[root@k8s-01 ~]# kubectl get svc kubernetes -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR kubernetes ClusterIP 10.1.0.1 <none> 443/TCP 29d <none>
而該kubernetes服務代理的后端實際地址通過endpoints進行維護，如下所示：
[root@k8s-01 ~]# kubectl get endpoints kubernetes NAME ENDPOINTS AGE kubernetes 192.168.122.2:6443 29d
通過這種方式集群內的應用或者系統主機就可以通過集群內部的DNS域名kubernetes.default.svc訪問到部署外 部的kube-apiserver實例。
因此，如果我們想要監控kube-apiserver相關的指標，只需要通過endpoints資源找到kubernetes對應的所有后 端地址即可。
如下所示，創建監控任務kubernetes-apiservers，這里指定了服務發現模式為endpoints。Promtheus會查找 當前集群中所有的endpoints配置，並通過relabel進行判斷是否為apiserver對應的訪問地址：
- job_name: 'kubernetes-apiservers' kubernetes_sd_configs: - role: endpoints scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name,__meta_kubernetes_endpoint_port_name] action: keep regex: default;kubernetes;https - target_label: __address__ replacement: kubernetes.default.svc:443
在relabel_configs配置中第一步用於判斷當前endpoints是否為kube-apiserver對用的地址。第二步，替換監 控采集地址到kubernetes.default.svc:443即可。重新加載配置文件，重建Promthues實例，得到以下結果。
對Ingress和Service進行網絡探測
為了能夠對Ingress和Service進行探測，我們需要在集群部署Blackbox Exporter實例。 如下所示，創建 blackbox-exporter.yaml用於描述部署相關的內容:
apiVersion: v1 kind: Service metadata: labels: app: blackbox-exporter name: blackbox-exporter spec: ports: - name: blackbox port: 9115 protocol: TCP selector: app: blackbox-exporter type: ClusterIP --- apiVersion: apps/v1 kind: Deployment metadata: labels: app: blackbox-exporter name: blackbox-exporter spec: replicas: 1 selector: matchLabels: app: blackbox-exporter template: metadata: labels: app: blackbox-exporter spec: containers: - image: prom/blackbox-exporter imagePullPolicy: IfNotPresent name: blackbox-exporter
通過kubectl命令部署Blackbox Exporter實例，這里將部署一個Blackbox Exporter的Pod實例，同時通過服 務blackbox-exporter在集群內暴露訪問地址blackbox-exporter.default.svc.cluster.local，對於集 群內的任意服務都可以通過該內部DNS域名訪問Blackbox Exporter實例：
[root@k8s-01 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE blackbox-exporter-5574646b-4wjg5 1/1 Running 0 46m prometheus-7f57d48b8d-n4sns 1/1 Running 0 26m [root@k8s-01 ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE blackbox-exporter ClusterIP 10.1.70.11 <none> 9115/TCP 46m kubernetes ClusterIP 10.1.0.1 <none> 443/TCP 29d prometheus NodePort 10.1.67.80 <none> 9090:30880/TCP 5h30m
為了能夠讓Prometheus能夠自動的對Service進行探測，我們需要通過服務發現自動找到所有的Service信息。 如下所示，在Prometheus的配置文件中添加名為kubernetes-services的監控采集任務：
- job_name: 'kubernetes-services' metrics_path: /probe params: module: [http_2xx] kubernetes_sd_configs: - role: service relabel_configs: - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_probe] action: keep regex: true - source_labels: [__address__] target_label: __param_target - target_label: __address__ replacement: blackbox-exporter.default.svc.cluster.local:9115 - source_labels: [__param_target] target_label: instance - action: labelmap regex: __meta_kubernetes_service_label_(.+) - source_labels: [__meta_kubernetes_namespace] target_label: kubernetes_namespace - source_labels: [__meta_kubernetes_service_name] target_label: kubernetes_name
在該任務配置中，通過指定kubernetes_sd_config的role為service指定服務發現模式：
kubernetes_sd_configs:
- role: service
為了區分集群中需要進行探測的Service實例，我們通過標簽‘prometheus.io/probe: true’進行判斷，從而過 濾出需要探測的所有Service實例：
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_probe] action: keep regex: true
並且將通過服務發現獲取到的Service實例地址 __address__ 轉換為獲取監控數據的請求參數。同時 將 __address 執行Blackbox Exporter實例的訪問地址，並且重寫了標簽instance的內容：
- source_labels: [__address__] target_label: __param_target - target_label: __address__ replacement: blackbox-exporter.default.svc.cluster.local:9115 - source_labels: [__param_target] target_label: instance
最后，為監控樣本添加了額外的標簽信息：
- action: labelmap regex: __meta_kubernetes_service_label_(.+) - source_labels: [__meta_kubernetes_namespace] target_label: kubernetes_namespace - source_labels: [__meta_kubernetes_service_name] target_label: kubernetes_name
對於Ingress而言，也是一個相對類似的過程，這里給出對Ingress探測的Promthues任務配置作為參考：
- job_name: 'kubernetes-ingresses' metrics_path: /probe params: module: [http_2xx] kubernetes_sd_configs: - role: ingress relabel_configs: - source_labels: [__meta_kubernetes_ingress_annotation_prometheus_io_probe] action: keep regex: true - source_labels: [__meta_kubernetes_ingress_scheme,__address__,__meta_kubernetes_ingress_path] regex: (.+);(.+);(.+) replacement: ${1}://${2}${3} target_label: __param_target - target_label: __address__ replacement: blackbox-exporter.default.svc.cluster.local:9115 - source_labels: [__param_target] target_label: instance - action: labelmap regex: __meta_kubernetes_ingress_label_(.+) - source_labels: [__meta_kubernetes_namespace] target_label: kubernetes_namespace - source_labels: [__meta_kubernetes_ingress_name] target_label: kubernetes_name