Sobre el proyecto
kube-state-metrics (KSM) es un servicio que escucha al servidor de API de Kubernetes y genera métricas sobre el estado de los objetos del clúster, como deployments, nodos y pods. En lugar de monitorear la salud de componentes individuales de Kubernetes, informa sobre los objetos dentro del clúster. Las métricas se exponen en texto plano en el endpoint HTTP /metrics (puerto predeterminado 8080) y están destinadas a Prometheus o scrapers compatibles; el endpoint refleja el estado actual del clúster, por lo que los objetos eliminados desaparecen de él.
Filosofía de diseño: KSM genera métricas a partir de objetos de la API de Kubernetes sin modificarlos, por lo que sus características comparten el grado de estabilidad de los objetos de API subyacentes. Expone datos sin procesar y sin modificar en lugar de aplicar heurísticas al estilo de kubectl, dejando la interpretación a los usuarios. Las métricas basadas en API alfa quedan excluidas de las garantías de estabilidad.
Capacidades clave descritas en el README:
- Documentación de métricas en el directorio docs, además de métricas de estado de recursos personalizados (característica congelada en favor de resource-state-metrics).
- Manejo de etiquetas: los nombres de etiquetas de Kubernetes se convierten a nombres compatibles con Prometheus (por ejemplo, app.kubernetes.io/name se convierte en label_app_kubernetes_io_name), con sufijos automáticos _conflictN cuando las conversiones colisionan.
- Las listas de permitidos/denegados admiten expresiones regulares de ECMAScript, incluidas lookarounds, con evaluación limitada a un minuto.
- Métricas propias en un host/puerto de telemetría separado (predeterminado 8081), incluidos contadores de éxito y error de list/watch, histogramas de duración de solicitudes HTTP, información de compilación, ordinal de shard/total de shards, y hash del archivo de configuración y estado de recarga.
- Guía de escalado: aproximadamente 250MiB de memoria y 0.1 cores como regla general; límites bajos de CPU pueden causar acumulación en la cola y mayor uso de memoria. Se dan cifras de latencia de una prueba de escalado con 100 nodos (Perc50 ~260ms, Perc90 ~475ms, Perc99 ~907ms).
- Sharding horizontal mediante --shard y --total-shards, usando un md5 del UID del objeto módulo el total de shards; sharding automatizado en un StatefulSet usando --pod y --pod-namespace (experimental); sharding basado en deployment con índices de shard explícitos; y sharding con daemonset para métricas de pods mediante --node, con --track-unscheduled-pods para pods no asignados.
- Filtrado de recursos en /metrics usando los parámetros de consulta resources y exclude_resources, con precedencia de exclude.
- Endpoints de salud: /healthz y /livez en el puerto principal, /readyz en el puerto de telemetría.
Configuración y uso: instalar mediante go get k8s.io/kube-state-metrics/v2, construir un contenedor con make container y desplegar con kubectl apply -f examples/standard. La pila kube-prometheus ya incluye KSM como componente. Los usuarios de GKE pueden necesitar un binding de cluster-admin debido a permisos de rol estrictos. El README también compara KSM con metrics-server: metrics-server sirve métricas de recursos agregadas desde Kubelet a través de la Metrics API, mientras que KSM genera nuevas métricas a partir del estado de los objetos y mantiene una instantánea en memoria. Ninguno exporta métricas a destinos de terceros por sí mismo.
Comments
0 Rating appears after 10 ratings
Sign in to join the discussion.