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。