kubernetes_sd_config
從Kubernetes的REST API上，Kubernets SD配置檢索和獲取目標，並且始終保持與集群狀態同步。
下面是role類型中的任何一個都能在發現目標上配置：
節點node
這個node角色發現帶有地址的每一個集群節點一個目標，都指向Kublelet的HTTP端口。這個目標地址默認為Kubernetes節點對象的第一個現有地址，地址類型為NodeInernalIP, NodeExternalIP, NodeLegacyHostIP和NodeHostName。
可用的meta標簽：
__meta_kubernetes_node_name: 節點對象的名稱__meta_kubernetes_node_label_<labelname>: 節點對象的每個標簽__meta_kubernetes_node_labelpresent_<labelname>: 節點對象中的每個標簽都為true。__meta_kubernetes_node_annotation_<annotationname>: 節點對象的每個注解__meta_kubernetes_node_annotationpresent_<annotationname>: 節點對象的每個注釋都為true。__meta_kubernetes_node_address_<address_type>: 如果存在，每一個節點對象類型的第一個地址
另外，對於節點的instance標簽，將會被設置成從API服務中獲取的節點名稱。
服務service
對於每個服務每個服務端口，service角色發現一個目標。對於一個服務的黑盒監控是通常有用的。這個地址被設置成這個服務的Kubernetes DNS域名, 以及各自的服務端口。
可用的meta標簽：
__meta_kubernetes_namespace: 服務對象的命名空間__meta_kubernetes_service_annotation_<annotationname>: 服務對象的注釋__meta_kubernetes_service_annotationpresent_<annotationname>: 服務對象的每個注解為“true”。__meta_kubernetes_service_cluster_ip: 服務的群集IP地址。（不適用於ExternalName類型的服務）__meta_kubernetes_service_external_name: 服務的DNS名稱。（適用於ExternalName類型的服務）__meta_kubernetes_service_label_<labelname>: 服務對象的標簽。__meta_kubernetes_service_labelpresent_<labelname>: 對於服務對象的每個標簽為true。__meta_kubernetes_service_name: 服務對象的名稱__meta_kubernetes_service_port_name: 目標服務端口的名稱__meta_kubernetes_service_port_protocol: 目標服務端口的協議__meta_kubernetes_service_type: 服務的類型__meta_kubernetes_service_port_number: 目標服務端口的數量（棄用?）
pod
pod角色會察覺所有的pod，並將它們的容器作為目標暴露出來。對於容器的每個聲明的端口，都會生成一個目標。如果一個容器沒有指定的端口，則會為每個容器創建一個無端口的目標，以便通過重新標注來手動添加端口。
可用的meta標簽：
__meta_kubernetes_namespace: pod對象的命名空間__meta_kubernetes_pod_name: pod對象的名稱__meta_kubernetes_pod_ip: pod對象的IP地址__meta_kubernetes_pod_label_<labelname>: pod對象的標簽__meta_kubernetes_pod_labelpresent_<labelname>: 對來自pod對象的每個標簽都是true。__meta_kubernetes_pod_annotation_<annotationname>: pod對象的注釋__meta_kubernetes_pod_annotationpresent_<annotationname>: 對於來自pod對象的每個注解都是true。__meta_kubernetes_pod_container_init: 如果容器是 InitContainer，則為 true。__meta_kubernetes_pod_container_name: 目標地址的容器名稱__meta_kubernetes_pod_container_port_name: 容器端口名稱__meta_kubernetes_pod_container_port_number: 容器端口的數量__meta_kubernetes_pod_container_port_protocol: 容器端口的協議__meta_kubernetes_pod_ready: 設置pod ready狀態為true或者false__meta_kubernetes_pod_phase: 在生命周期中設置Pending,Running,Succeeded,Failed或Unknown__meta_kubernetes_pod_node_name: pod調度的node名稱__meta_kubernetes_pod_host_ip: 節點對象的主機IP__meta_kubernetes_pod_uid: pod對象的UID。__meta_kubernetes_pod_controller_kind: pod控制器的kind對象.__meta_kubernetes_pod_controller_name: pod控制器的名稱.
endpoints（端點）
endpoints角色發現來自於一個服務的列表端點目標。對於每一個終端地址，一個目標被一個port發現。如果這個端點被寫入到pod中，這個節點的所有其他容器端口，未綁定到端點的端口，也會被目標發現。
可用的meta標簽：
__meta_kubernetes_namespace: 端點對象的命名空間__meta_kubernetes_endpoints_name: 端點對象的名稱- 對於直接從端點列表中獲取的所有目標，下面的標簽將會被附加上。
__meta_kubernetes_endpoint_hostname: 端點的Hostname__meta_kubernetes_endpoint_node_name: 端點所在節點的名稱。__meta_kubernetes_endpoint_ready: endpoint ready狀態設置為true或者false。__meta_kubernetes_endpoint_port_name: 端點的端口名稱__meta_kubernetes_endpoint_port_protocol: 端點的端口協議__meta_kubernetes_endpoint_address_target_kind: 端點地址目標的kind。__meta_kubernetes_endpoint_address_target_name: 端點地址目標的名稱。
- 如果端點屬於一個服務，這個角色的所有標簽：服務發現被附加上。
- 對於在pod中的所有目標，這個角色的所有表掐你：pod發現被附加上
ingress角色為每個ingress的每個路徑發現一個目標。這通常對黑盒監控一個ingress很有用。地址將被設置為 ingress 規范中指定的主機。
可用的meta標簽：
__meta_kubernetes_namespace: ingress對象的命名空間__meta_kubernetes_ingress_name: ingress對象的名稱__meta_kubernetes_ingress_label_<labelname>: ingress對象的每個label。__meta_kubernetes_ingress_labelpresent_<labelname>: ingress對象的每個label都為true。__meta_kubernetes_ingress_annotation_<annotationname>: ingress對象的每個注釋.__meta_kubernetes_ingress_annotationpresent_<annotationname>: 每個ingress對象的注解都是true。__meta_kubernetes_ingress_scheme: 協議方案，如果設置了TLS配置，則為https。默認為http。__meta_kubernetes_ingress_path: ingree spec的路徑。默認為/。
對於Kuberntes發現，看看下面的配置選項：
作者：半獸人 鏈接：https://www.orchome.com/9884 來源：OrcHome 著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。 # 訪問Kubernetes API的信息。 # API服務器地址。如果留空，則假設Prometheus在集群內部運行，並將自動發現API服務器， # 並使用/var/run/secrets/kubernetes.io/serviceaccount/的pod的CA證書和不記名標記文件。 [ api_server: <host> ] # The Kubernetes role of entities that should be discovered. # endpoints, service, pod, node 或 ingress 之一。 role: <string> # Optional authentication information used to authenticate to the API server. # Note that `basic_auth`, `bearer_token` and `bearer_token_file` options are # mutually exclusive. # password and password_file are mutually exclusive. # Optional HTTP basic authentication information. basic_auth: [ username: <string> ] [ password: <secret> ] [ password_file: <string> ] # Optional bearer token authentication information. [ bearer_token: <secret> ] # Optional bearer token file authentication information. [ bearer_token_file: <filename> ] # 可選代理URL. [ proxy_url: <string> ] # TLS配置 tls_config: [ <tls_config> ] # Optional namespace discovery. If omitted, all namespaces are used. namespaces: names: [ - <string> ] # Optional label and field selectors to limit the discovery process to a subset of available resources. # See https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ # and https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ to learn more about the possible # filters that can be used. Endpoints role supports pod, service and endpoints selectors, other roles # only support selectors matching the role itself (e.g. node role can only contain node selectors). # Note: When making decision about using field/label selector make sure that this # is the best approach - it will prevent Prometheus from reusing single list/watch # for all scrape configs. This might result in a bigger load on the Kubernetes API, # because per each selector combination there will be additional LIST/WATCH. On the other hand, # if you just want to monitor small subset of pods in large cluster it's recommended to use selectors. # Decision, if selectors should be used or not depends on the particular situation. [ selectors: [ - role: <string> [ label: <string> ] [ field: <string> ] ]]
<role>必須是endpoints, service, pod或者node。