Saltar al contenido principal

Kubernetes

La página Kubernetes registra e inspecciona cada clúster de Kubernetes que gestiona el tenant. El encabezado de la página indica "Inventario completo del clúster: pods, nodos, despliegues, statefulsets, daemonsets, jobs, servicios, ingresses, PVCs y eventos." Un botón Register cluster en la parte superior derecha abre el diálogo de registro.

Cada clúster recibe una sincronización de inventario que rellena las tablas de recursos (pods, nodos, despliegues, statefulsets, daemonsets, jobs, cronjobs, servicios, ingresses, PVCs, namespaces y eventos). La página también muestra la topología y el dashboard a nivel de pod.

La lista de clústeres es una tabla pequeña con cinco columnas: Name, API URL, Last sync, Errors, Actions. Haga clic en una fila de clúster para abrir su vista de detalle.

Registrar un Clúster​

El botón Register cluster abre un diálogo con cuatro modos de autenticación:

  • Bearer token — URL de la API y un bearer token; la opción más sencilla.
  • Kubeconfig — Pegue el YAML completo del kubeconfig; útil para clústeres con múltiples contextos de autenticación.
  • OIDC — Endpoint de token, ID de cliente, secreto de cliente, y opcionalmente nombre de usuario, contraseña, scope y audience para un inicio de sesión federado programático.
  • Azure AKS — ID de recurso de un clúster AKS; la plataforma intercambia las credenciales de Azure configuradas por un token de clúster.

Tras el registro, la primera sincronización comienza de inmediato. La fila muestra Syncing hasta que finaliza el primer ciclo de inventario; los clústeres grandes pueden tardar hasta un minuto.

Pestañas de Recursos​

Una pestaña por tipo de recurso cambia el contenido de la tabla:

  • Pods, Nodes, Deployments, StatefulSets, DaemonSets, Jobs, CronJobs
  • Services, Ingresses, PersistentVolumeClaims
  • Namespaces, Events
  • Topology — una vista en grafo de las relaciones del clúster

Las pestañas Pods, Nodes y Deployments muestran insignias de estado en línea basadas en la disponibilidad y preparación de cada recurso.

Detalle del Clúster​

Al hacer clic en una fila de clúster se navega a la vista de detalle, que se abre en un dashboard del clúster — contadores principales (total de pods en ejecución, pendientes y fallidos, nodos, nodos listos, reinicios), un gráfico Pods over time y un gráfico Container restarts sobre una ventana seleccionable — con las pestañas de recursos debajo. También incluye:

  • Un desglose por namespace
  • Una subvista de topología para el clúster seleccionado
  • Métricas con alcance de clúster (recuento de nodos, recuento de pods por fase, eventos recientes)

Dashboard de Pod​

Al hacer clic en una fila de pod se abre el dashboard dedicado por pod, dividido en tres pestañas:

  • Metrics — un panel con alcance a ese pod con una ventana de tiempo seleccionable, uso de CPU por contenedor (con la solicitud total del pod como línea discontinua), throttling de CPU, memoria e I/O de red, además de un acceso directo View topology hacia el grafo.
  • Logs — logs en vivo del pod obtenidos directamente del clúster (consulte Logs de Pod (En Vivo) más abajo).
  • Log Explorer — logs almacenados e históricos con información sobre la causa raíz (consulte Log Explorer más abajo); disponible una vez que se habilita la Ingesta de Logs para el clúster.

El dashboard se abre en la pestaña Metrics; los logs se obtienen solo cuando se abre la pestaña Logs o Log Explorer.

Logs de Pod (En Vivo)​

La pestaña Logs del dashboard de pod sigue los logs de un pod en vivo desde el servidor de API del clúster. Los logs se leen bajo demanda y no se almacenan — esta es una vista en vivo de un único pod (el tail se pierde cuando el contenedor se reinicia), por lo que es la forma más rápida de ver qué está haciendo un pod en este momento sin ninguna configuración de recolector o ingesta.

Controles​

  • Container — seleccione los logs de qué contenedor mostrar; por defecto es el primer contenedor y es obligatorio para pods con múltiples contenedores.
  • Lines — cuántas líneas finales se van a obtener (100 / 500 / 1000 / 5000).
  • Since — restringe a una ventana de retroceso (All / 5m / 15m / 1h / 6h / 24h).
  • Previous (crashed) instance — muestra los logs del último contenedor terminado en lugar del que está en ejecución. Úselo para clasificar pods en CrashLoopBackOff y OOMKilled, cuyos logs de otro modo habrían desaparecido.
  • Auto-refresh (10s) — vuelve a obtener el tail cada diez segundos.
  • Refresh — vuelve a obtener bajo demanda.
  • Search within results — filtra las líneas obtenidas por subcadena.

Los niveles de log (ERROR, WARN, INFO, …) están codificados por color, y un histograma de volumen sobre el cuerpo del log muestra el rendimiento durante la ventana obtenida — pase el cursor sobre una barra para ver su rango de tiempo y recuento de líneas.

Descarga​

El menú Download en la parte inferior derecha del panel de logs escribe los logs en un archivo .txt:

  • Visible logs — exactamente lo que se muestra en pantalla, respetando el contenedor, las líneas, la ventana y los filtros de búsqueda actuales.
  • All logs — el log completo retenido para el contenedor seleccionado, ignorando los filtros de líneas y tiempo (limitado por un tamaño máximo por seguridad).

Requisitos​

Nota: La credencial de clúster almacenada debe tener permiso para leer los logs de pod — get en el subrecurso pods/log. Si no lo tiene, la pestaña Logs muestra un mensaje claro de "lacks the 'pods/log' permission" en lugar de los logs; conceda ese verbo al rol de la credencial y vuelva a intentarlo.

Los logs en vivo son efímeros y tienen alcance a un único pod. Para logs almacenados, históricos, entre reinicios y consultables, habilite la Ingesta de Logs y use el Log Explorer.

Log Explorer (Logs Almacenados)​

Una vez que la Ingesta de Logs está habilitada para un clúster, el Log Explorer busca en sus logs almacenados — históricos, entre reinicios y consultables — en lugar de un tail en vivo. Aparece en dos lugares:

  • Detalle del clúster → pestaña Log Explorer — en todos los pods y namespaces del clúster.
  • Dashboard de pod → pestaña Log Explorer — con alcance previo a ese pod.

Información sobre la causa raíz​

Sobre la tabla de logs, una franja de insights resume la ventana para responder "qué falló y por qué":

  • Recuentos de errores y advertencias para la ventana seleccionada.
  • Errores recurrentes principales — los mensajes similares se agrupan (los IDs, marcas de tiempo y números se normalizan) y se clasifican por recuento de ocurrencias. Haga clic en una firma para filtrar la tabla a solo esas ocurrencias y ver en qué pod y en qué momento ocurrió cada una.
  • Correlación de fallos (con alcance a pod) — cuando el estado propio del pod muestra CrashLoopBackOff, OOMKilled o Failed, un banner vincula ese fallo con los errores a continuación.
  • Rango de tiempo ajustable estándar (presets desde 5 minutos más un rango personalizado).
  • Codificación de color por nivel, búsqueda de texto completo y expansión de fila al hacer clic para ver los detalles (pod, namespace, nodo, contenedor y atributos brutos).
  • Vista de clúster: el nombre del pod en cada fila enlaza al dashboard de ese pod (métricas + logs). Un pod que no está en el inventario sincronizado actual del clúster se muestra sin enlace (su dashboard de métricas no está disponible).

Ingesta de Logs​

La ingesta de logs envía los logs de pod de un clúster a Beak para que puedan almacenarse y explorarse. Es una configuración propiedad de la plataforma, exclusiva para superadministradores — emite una credencial de ingesta y establece controles de costos de almacenamiento, por lo que está regida por el acuerdo de servicio en lugar de ser modificada por usuarios finales. La pestaña Log Ingestion aparece en la página de detalle del clúster solo para los usuarios que tienen el permiso de administrador de ingesta de logs.

Habilitar la ingesta​

  1. Habilite la ingesta para el clúster.
  2. Emita un token de ingesta — se muestra una sola vez; cópielo y luego cree el Kubernetes Secret del que se lee (el comando exacto de kubectl se muestra tras la emisión).
  3. Descargue el manifiesto y aplíquelo con kubectl apply. Despliega un DaemonSet de OpenTelemetry Collector que sigue los logs de contenedor, los enriquece con metadatos de Kubernetes (pod, namespace, nodo y Deployment propietario), y los envía a Beak mediante OTLP/HTTP. El token se lee desde el Secret — nunca se incluye en el archivo descargado.

Los logs aparecen en el Log Explorer en aproximadamente un minuto.

Configuración (estas opciones controlan el comportamiento en ejecución)​

  • Retention (days) — cuánto tiempo se conservan los logs ingeridos antes de su eliminación automática. Una retención más larga conlleva mayor costo de almacenamiento.
  • Volume cap (GB/day) — un límite diario por clúster; más allá de este, la ingesta se throttlea para que un clúster ruidoso no genere costos de almacenamiento ilimitados. Déjelo en blanco para no aplicar límite.
  • Noise filters — descarta solicitudes de health-check, líneas DEBUG/TRACE o namespaces completos en el origen (en el colector, antes del envío) — el lugar más económico para reducir el volumen. Cambiar estos valores regenera el manifiesto; vuelva a aplicarlo al clúster.

Nota: Rotar el token invalida el anterior de inmediato; revocarlo detiene la ingesta (los envíos posteriores son rechazados). Solo se almacena el hash del token — el texto plano nunca se persiste ni se muestra de nuevo tras la emisión.

Filtrado​

Los filtros de embudo por columna funcionan en todas las pestañas. Los parámetros de URL controlan el ID del clúster y la pestaña seleccionada, de modo que cualquier combinación clúster-pestaña puede guardarse como marcador.

Buenas Prácticas​

  • Registre un clúster por entorno (desarrollo, Preproduccion, producción) en lugar de uno por región para mantener los recuentos de recursos y las cuotas legibles.
  • El modo de autenticación Bearer token es la opción de menor fricción para integraciones efímeras; use OIDC o AKS para clústeres de producción de larga duración donde la rotación de tokens es importante.
  • Las edades de eventos y de recursos ayudan a distinguir las cargas de trabajo recién creadas de las de larga duración; ordene por Age cuando clasifique bucles de reinicio.
  • La pestaña Topology es más útil para los ingenieros que están conociendo el clúster — la clasificación en producción generalmente requiere la pestaña Pod más K8s Intelligence.
  • Cuando clasifique un crash loop, abra la pestaña Logs del pod y habilite Previous (crashed) instance para leer el contenedor que falló; luego use Download → All logs para adjuntar el log completo a un incidente.
  • Para investigaciones recurrentes o post-mortem (después de que un reinicio borre el tail en vivo), use el Log Explorer — su agrupación de errores más recurrentes y el banner de correlación de fallos apuntan a la causa raíz más rápido que desplazarse por líneas brutas. Esto requiere que la Ingesta de Logs esté habilitada; mantenga la retención y el límite de volumen ajustados al presupuesto de almacenamiento acordado.

Páginas Relacionadas​

  • Cluster Map — Mapa de salud del clúster en lenguaje sencillo
  • Workloads — Tabla de salud entre clústeres de Deployments, StatefulSets y DaemonSets
  • K8s Intelligence — Problemas de Kubernetes pasados, actuales y previstos
  • Knowledge Graph — Grafo entre capas que incluye la topología de Kubernetes
  • Containers — Vista a nivel de Docker que complementa los datos a nivel de pod