métricas del estado de kube
v2.14.0
kube-state-metrics (KSM) es un servicio simple que escucha el servidor API de Kubernetes y genera métricas sobre el estado de los objetos. (Consulte los ejemplos en la sección Métricas a continuación). No se centra en el estado de los componentes individuales de Kubernetes, sino en el estado de los diversos objetos internos, como implementaciones, nodos y pods.
kube-state-metrics consiste en generar métricas a partir de objetos API de Kubernetes sin modificaciones. Esto garantiza que las funciones proporcionadas por kube-state-metrics tengan el mismo grado de estabilidad que los propios objetos API de Kubernetes. A su vez, esto significa que kube-state-metrics en ciertas situaciones puede no mostrar exactamente los mismos valores que kubectl, ya que kubectl aplica ciertas heurísticas para mostrar mensajes comprensibles. kube-state-metrics expone datos sin procesar sin modificar de la API de Kubernetes, de esta manera los usuarios tienen todos los datos que necesitan y realizan heurísticas como mejor les parezca.
Las métricas se exportan en el punto final HTTP /metrics en el puerto de escucha (8080 predeterminado). Se sirven como texto sin formato. Están diseñados para ser consumidos por el propio Prometheus o por un raspador que sea compatible con el raspado de un punto final de cliente de Prometheus. También puede abrir /metrics en un navegador para ver las métricas sin procesar. Tenga en cuenta que las métricas expuestas en el punto final /metrics reflejan el estado actual del clúster de Kubernetes. Cuando se eliminan objetos de Kubernetes, ya no son visibles en el punto final /metrics .
Nota
Este README se genera a partir de una plantilla. Realice los cambios allí y ejecute make generate-template .
Versionado
Versión Kubernetes
Matriz de compatibilidad
Compatibilidad de versiones del grupo de recursos
Imagen del contenedor
Documentación de métricas
Resolución de conflictos en nombres de etiquetas
Autométricas de Kube-state-metrics
Recomendación de recursos
Estado latente
Una nota sobre los costos
kube-state-metrics frente a servidor de métricas
Escalado de métricas de estado de kube
fragmentación automatizada
Recomendación de recursos
fragmentación horizontal
Fragmentación de Daemonset para métricas de pod
Configuración
Construyendo el contenedor Docker
Uso
Implementación de Kubernetes
Entorno de privilegios limitados
Carta de timón
Desarrollo
Contribuciones de los desarrolladores
Comunidad
kube-state-metrics utiliza client-go para comunicarse con los clústeres de Kubernetes. La versión del clúster de Kubernetes admitida la determina client-go . La matriz de compatibilidad para client-go y el clúster de Kubernetes se puede encontrar aquí. Toda compatibilidad adicional es solo el mejor esfuerzo, o resulta que todavía o ya es compatible.
A continuación se registrarán como máximo 5 kube-state-metrics y 5 lanzamientos de kubernetes. Generalmente, se recomienda utilizar la última versión de kube-state-metrics. Si ejecuta una versión muy reciente de Kubernetes, es posible que desee utilizar una versión inédita para tener toda la gama de recursos compatibles. Si ejecuta una versión anterior de Kubernetes, es posible que necesite ejecutar una versión anterior para tener soporte completo para todos los recursos. Tenga en cuenta que los encargados de mantenimiento solo admitirán la última versión. Es posible que los usuarios interesados de la comunidad admitan versiones anteriores.
| kube-estado-métricas | Versión cliente-go de Kubernetes |
|---|---|
| v2.10.1 | v1.27 |
| v2.11.0 | v1.28 |
| v2.12.0 | v1.29 |
| v2.13.0 | v1.30 |
| v2.14.0 | v1.31 |
| principal | v1.31 |
Los recursos en Kubernetes pueden evolucionar, es decir, la versión grupal de un recurso puede cambiar de alfa a beta y finalmente a GA en diferentes versiones de Kubernetes. Por ahora, kube-state-metrics solo utilizará la API más antigua disponible en la última versión.
La imagen del contenedor más reciente se puede encontrar en:
registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.14.0 (arco: amd64 , arm , arm64 , ppc64le y s390x )
Vea todas las imágenes de múltiples arquitecturas aquí
Todos los recursos y métricas basados en las API alfa de Kubernetes están excluidos de cualquier garantía de estabilidad, que puede modificarse en cualquier versión determinada.
Consulte el directorio docs para obtener más información sobre las métricas expuestas.
La familia de métricas *_labels expone las etiquetas de Kubernetes como etiquetas de Prometheus. Como Kubernetes es más liberal que Prometheus en términos de caracteres permitidos en los nombres de las etiquetas, convertimos automáticamente los caracteres no admitidos en guiones bajos. Por ejemplo, app.kubernetes.io/name se convierte en label_app_kubernetes_io_name .
Esta conversión puede crear conflictos cuando varias etiquetas de Kubernetes, como foo-bar y foo_bar se convierten en la misma etiqueta de Prometheus label_foo_bar .
Kube-state-metrics agrega automáticamente un sufijo _conflictN para resolver este conflicto, por lo que convierte las etiquetas anteriores en label_foo_bar_conflict1 y label_foo_bar_conflict2 .
Si desea tener más control sobre cómo se resuelve este conflicto, puede considerar abordar este problema en un nivel diferente de la pila, por ejemplo, estandarizando las etiquetas de Kubernetes mediante un Webhook de admisión que garantice que no haya posibles conflictos.
kube-state-metrics expone sus propias métricas de proceso generales en --telemetry-host y --telemetry-port (8081 predeterminado).
kube-state-metrics también expone listas y observa métricas de éxito y error. Estos se pueden utilizar para calcular la tasa de error de la lista o de los recursos de vigilancia. Si encuentra esos errores en las métricas, lo más probable es que se trate de un problema de configuración o permisos, y lo siguiente que debe investigar sería mirar los registros de kube-state-metrics.
Ejemplo de las métricas mencionadas anteriormente:
kube_state_metrics_list_total{resource="*v1.Node",result="success"} 1
kube_state_metrics_list_total{resource="*v1.Node",result="error"} 52
kube_state_metrics_watch_total{resource="*v1beta1.Ingress",result="success"} 1kube-state-metrics también expone algunas métricas de solicitudes http, ejemplos de ellas son:
http_request_duration_seconds_bucket{handler="metrics",method="get",le="2.5"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="5"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="10"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="+Inf"} 30
http_request_duration_seconds_sum{handler="metrics",method="get"} 0.021113919999999998
http_request_duration_seconds_count{handler="metrics",method="get"} 30kube-state-metrics también expone métricas de compilación y configuración:
kube_state_metrics_build_info{branch="main",goversion="go1.15.3",revision="6c9d775d",version="v2.0.0-beta"} 1
kube_state_metrics_shard_ordinal{shard_ordinal="0"} 0
kube_state_metrics_total_shards 1 kube_state_metrics_build_info se utiliza para exponer la versión y otra información de compilación. Para obtener más información sobre el patrón de información, consulte la publicación del blog aquí. Las métricas de fragmentación exponen los indicadores --shard y --total-shards y se pueden usar para validar la configuración en tiempo de ejecución; consulte /examples/prometheus-alerting-rules .
kube-state-metrics también expone métricas sobre su archivo de configuración y el archivo de configuración de estado de recurso personalizado:
kube_state_metrics_config_hash{filename="crs.yml",type="customresourceconfig"} 2.38272279311849e+14
kube_state_metrics_config_hash{filename="config.yml",type="config"} 2.65285922340846e+14
kube_state_metrics_last_config_reload_success_timestamp_seconds{filename="crs.yml",type="customresourceconfig"} 1.6704882592037103e+09
kube_state_metrics_last_config_reload_success_timestamp_seconds{filename="config.yml",type="config"} 1.6704882592035313e+09
kube_state_metrics_last_config_reload_successful{filename="crs.yml",type="customresourceconfig"} 1
kube_state_metrics_last_config_reload_successful{filename="config.yml",type="config"} 1El uso de recursos para kube-state-metrics cambia con el tamaño de los objetos de Kubernetes (Pods/Nodos/Implementaciones/Secretos, etc.) del clúster. Hasta cierto punto, los objetos de Kubernetes en un clúster son directamente proporcionales al número de nodo del clúster.
Como regla general, conviene asignar:
Memoria de 250MiB
0,1 núcleos
Tenga en cuenta que si los límites de CPU se establecen demasiado bajos, las colas internas de kube-state-metrics no podrán eliminarse con la suficiente rapidez, lo que provocará un mayor consumo de memoria a medida que crezca la longitud de la cola. Si experimenta problemas resultantes de una alta asignación de memoria o de una aceleración de la CPU, intente aumentar los límites de la CPU.
En una prueba de escalado de clúster de 100 nodos, los números de latencia fueron los siguientes:
"Perc50": 259615384 ns, "Perc90": 475000000 ns, "Perc99": 906666666 ns.
De forma predeterminada, kube-state-metrics expone varias métricas para eventos en su clúster. Si tiene una gran cantidad de recursos que se actualizan con frecuencia en su clúster, es posible que se ingieran una gran cantidad de datos en estas métricas. Esto puede generar altos costos para algunos proveedores de nube. Tómese un momento para configurar las métricas que desea exponer y consulte la documentación de su entorno de Kubernetes para evitar costos inesperadamente altos.
El servidor de métricas es un proyecto inspirado en Heapster y se implementa para cumplir los objetivos de las canalizaciones de métricas centrales en la arquitectura de monitoreo de Kubernetes. Es un componente a nivel de clúster que periódicamente extrae métricas de todos los nodos de Kubernetes atendidos por Kubelet a través de Metrics API. Las métricas se agregan, se almacenan en la memoria y se entregan en formato API de métricas. El servidor de métricas almacena únicamente los valores más recientes y no es responsable de reenviar métricas a destinos de terceros.
kube-state-metrics se centra en generar métricas completamente nuevas a partir del estado de los objetos de Kubernetes (por ejemplo, métricas basadas en implementaciones, conjuntos de réplicas, etc.). Mantiene una instantánea completa del estado de Kubernetes en la memoria y genera continuamente nuevas métricas basadas en ella. Y al igual que el servidor de métricas, tampoco es responsable de exportar sus métricas a ninguna parte.
Tener kube-state-metrics como un proyecto separado también permite el acceso a estas métricas desde sistemas de monitoreo como Prometheus.
Para fragmentar kube-state-metrics horizontalmente, se han implementado algunas capacidades de fragmentación automatizadas. Está configurado con las siguientes banderas:
--shard (indexado a cero)
--total-shards
La fragmentación se realiza tomando una suma md5 del UID del objeto Kubernetes y realizando una operación de módulo con el número total de fragmentos. Cada fragmento decide si el objeto es manejado por la instancia respectiva de kube-state-metrics o no. Tenga en cuenta que esto significa que todas las instancias de kube-state-metrics, incluso si están fragmentadas, tendrán el tráfico de red y el consumo de recursos para desclasificar objetos para todos los objetos, no solo para aquellos de los que son responsables. Para optimizar esto aún más, la API de Kubernetes debería admitir capacidades de lista/vigilancia fragmentada. En el caso óptimo, el consumo de memoria para cada fragmento será 1/n en comparación con una configuración no fragmentada. Por lo general, kube-state-metrics necesita optimizar la memoria y la latencia para que pueda devolver sus métricas con bastante rapidez a Prometheus. Una forma de reducir la latencia entre kube-state-metrics y kube-apiserver es ejecutar KSM con el indicador --use-apiserver-cache . Además de reducir la latencia, esta opción también reducirá la carga en etcd.
La fragmentación se debe utilizar con cuidado y se debe configurar un monitoreo adicional para garantizar que la fragmentación esté configurada y funcione como se espera (por ejemplo, se configuran instancias para cada fragmento del total de fragmentos).
La fragmentación automática permite que cada fragmento descubra su posición nominal cuando se implementa en un StatefulSet, lo cual es útil para configurar la fragmentación automáticamente. Esta es una característica experimental y puede interrumpirse o eliminarse sin previo aviso.
Para habilitar la fragmentación automatizada, kube-state-metrics debe ejecutarse mediante un StatefulSet y el nombre del pod y el espacio de nombres deben entregarse al proceso kube-state-metrics a través de los indicadores --pod y --pod-namespace . Se pueden encontrar manifiestos de ejemplo que demuestran la funcionalidad de autosharding en /examples/autosharding .
Esta forma de implementar fragmentos es útil cuando desea administrar fragmentos de KSM a través de un único recurso de Kubernetes (un único StatefulSet en este caso) en lugar de tener una Deployment por fragmento. La ventaja puede ser especialmente significativa cuando se implementa una gran cantidad de fragmentos.
La desventaja de utilizar una configuración con fragmentación automática proviene de la estrategia de implementación respaldada por StatefulSet s. Cuando se administran mediante un StatefulSet , los pods se reemplazan uno a la vez y cada pod primero se finaliza y luego se vuelve a crear. Además de que dichas implementaciones serán más lentas, también generarán un breve tiempo de inactividad para cada fragmento. Si se produce un raspado de Prometheus durante una implementación, es posible que se pierdan algunas de las métricas exportadas por kube-state-metrics.
Para las métricas de pod, se pueden fragmentar por nodo con la siguiente marca:
--node=$(NODE_NAME)
Cada pod de kube-state-metrics utiliza FieldSelector (spec.nodeName) para observar/enumerar las métricas del pod solo en el mismo nodo.
Un ejemplo de daemonset kube-state-metrics:
apiVersion: apps/v1 kind: DaemonSet spec: template: spec: containers: - image: registry.k8s.io/kube-state-metrics/kube-state-metrics:IMAGE_TAG name: kube-state-metrics args: - --resource=pods - --node=$(NODE_NAME) env: - name: NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName
Para realizar un seguimiento de las métricas de pods no asignados, debe agregar una implementación adicional y configurar --track-unscheduled-pods , como se muestra en el siguiente ejemplo:
apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - image: registry.k8s.io/kube-state-metrics/kube-state-metrics:IMAGE_TAG name: kube-state-metrics args: - --resources=pods - --track-unscheduled-pods
Otras métricas se pueden fragmentar mediante fragmentación horizontal.
Instale este proyecto en su $GOPATH usando go get :
go get k8s.io/kube-state-metrics
Simplemente ejecute el siguiente comando en esta carpeta raíz, que creará un binario autónomo vinculado estáticamente y creará una imagen de Docker:
make container
Simplemente cree y ejecute kube-state-metrics dentro de un pod de Kubernetes que tenga un token de cuenta de servicio con acceso de solo lectura al clúster de Kubernetes.
La pila ( kube-prometheus ) instala kube-state-metrics como uno de sus componentes; no necesita instalar kube-state-metrics si está utilizando la pila kube-prometheus.
Si desea revisar la configuración predeterminada de Kube-Prometheus, por ejemplo para habilitar métricas no predeterminadas, consulte Personalización de Kube-Prometheus.
Para implementar este proyecto, simplemente puede ejecutar kubectl apply -f examples/standard y se creará un servicio y una implementación de Kubernetes. (Nota: ajuste la versión api de algún recurso si la versión de su clúster de Kubernetes no es 1.8+, consulte el archivo yaml para obtener más información).
Para que Prometheus descubra instancias de kube-state-metrics, se recomienda crear una configuración de raspado de Prometheus específica para kube-state-metrics que recoja ambos puntos finales de métricas. Se desaconseja el descubrimiento basado en anotaciones, ya que solo se podría seleccionar uno de los puntos finales, además, kube-state-metrics en la mayoría de los casos tiene requisitos especiales de autenticación y autorización, ya que esencialmente otorga acceso de lectura a través del punto final de métricas a la mayor parte de la información disponible.
Nota: Usuarios de Google Kubernetes Engine (GKE): GKE tiene permisos de roles estrictos que evitarán que se creen roles y enlaces de roles de kube-state-metrics. Para solucionar este problema, puede asignarle a su identidad de GCP la función de administrador de clúster ejecutando la siguiente frase:
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud info --format='value(config.account)')
Tenga en cuenta que su identidad de GCP distingue entre mayúsculas y minúsculas, pero gcloud info a partir del SDK 221.0.0 de Google Cloud no. Esto significa que si su miembro de IAM contiene letras mayúsculas, es posible que la frase anterior no funcione para usted. Si tiene 403 respuestas prohibidas después de ejecutar el comando anterior y kubectl apply -f examples/standard , verifique el miembro de IAM asociado con su cuenta en https://console.cloud.google.com/iam-admin/iam?project=PROJECT_ID . Si contiene letras mayúsculas, es posible que deba configurar el indicador --user en el comando anterior en la función que distingue entre mayúsculas y minúsculas que figura en https://console.cloud.google.com/iam-admin/iam?project=PROJECT_ID.
Después de ejecutar lo anterior, si ve Clusterrolebinding "cluster-admin-binding" created , entonces podrá continuar con la configuración de este servicio.
Están disponibles los siguientes puntos finales de comprobación de estado ( self se refiere al puerto de telemetría, mientras que main se refiere al puerto de exposición):
/healthz (expuesto en main ): devuelve un código de estado 200 si la aplicación se está ejecutando. Recomendamos utilizar esto para la sonda de inicio.
/livez (expuesto en main ): devuelve un código de estado 200 si la aplicación no se ve afectada por una interrupción del servidor API de Kubernetes. Recomendamos utilizar esto para la sonda de vida.
/readyz (expuesto en self ): devuelve un código de estado 200 si la aplicación está lista para aceptar solicitudes y exponer métricas. Recomendamos usar esto para la sonda de preparación.
Tenga en cuenta que no se recomienda utilizar el punto final de métricas de telemetría para cualquier sonda al realizar proxy de los datos de exposición.
Si desea ejecutar kube-state-metrics en un entorno donde no tiene la función de lector de clúster, puede:
crear una cuenta de servicio
apiVersion: v1kind: ServiceAccountmetadata: nombre: kube-state-metrics espacio de nombres: su-espacio-de-nombres-donde-se-implementarán-las-métricas-de-estado-de-kube
asígnele privilegios view en espacios de nombres específicos (usando roleBinding) ( nota: puede agregar este roleBinding a todos los NS a los que desea que acceda su cuenta de servicio )
apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: nombre: kube-state-metrics espacio de nombres: proyecto1roleRef: apiGroup: rbac.authorization.k8s.io tipo: ClusterRole nombre: vistastemas: - tipo: nombre de cuenta de servicio: espacio de nombres de métricas de estado de kube: su espacio de nombres donde se implementarán las métricas de estado de kube
luego especifique un conjunto de espacios de nombres (usando la opción --namespaces ) y un conjunto de objetos de Kubernetes (usando --resources ) a los que su cuenta de servicio tiene acceso en la configuración de implementación kube-state-metrics
especificación: plantilla: especificación: contenedores:
- nombre: kube-state-metricsargs:
- '--recursos=pods' - '--espacios de nombres=proyecto1'Para obtener la lista completa de argumentos disponibles, consulte la documentación en docs/developer/cli-arguments.md
A partir del gráfico kube-state-metrics v2.13.3 (imagen kube-state-metrics v1.9.8 ), el gráfico oficial de Helm se mantiene en prometheus-community/helm-charts. A partir de kube-state-metrics chart v3.0.0 solo se admiten imágenes de kube-state-metrics de v2.0.0 + .
Al desarrollar, pruebe un volcado de métricas en su clúster de Kubernetes local ejecutando:
Los usuarios pueden anular la dirección de apiserver en el archivo KUBE-CONFIG con la línea de comando
--apiserver.
go install kube-state-metrics --port=8080 --telemetry-port=8081 --kubeconfig=--apiserver=
Luego curva el punto final de las métricas.
curl localhost:8080/metrics
Para ejecutar las pruebas e2e localmente, consulte la documentación en tests/README.md.
Al desarrollar, existen ciertos patrones de código a seguir para mejorar su experiencia de contribución y la probabilidad de aprobar e2e y otras pruebas de ci. Para obtener más información sobre ellos, consulte la documentación en docs/developer/guide.md.
Este proyecto está patrocinado por SIG Instrumentation.
También hay un canal para #kube-state-metrics en Slack de Kubernetes.
También puede unirse a la lista de correo de SIG Instrumentation. Por lo general, esto agregará invitaciones para las siguientes reuniones a su calendario, en las que se pueden discutir temas relacionados con kube-state-metrics.
Reunión ordinaria del SIG: jueves a las 9:30 PT (hora del Pacífico) (quincenal). Convierta a su zona horaria.
Reunión regular de clasificación: jueves a las 9:30 PT (hora del Pacífico) (quincenal, alternando con la reunión regular). Convierta a su zona horaria.
