Entrevista general: ¿Cómo puede Kubernetes NodeLogQuery exponer los logs del sistema de forma segura?

Planteamiento y contexto

Una plataforma de operaciones necesita logs de systemd de los nodos de Kubernetes para depuración, pero no debe exponer el sistema de archivos del nodo a los inquilinos (tenants). Explique los límites de NodeLogQuery estable en Kubernetes v1.36, el control de acceso, los parámetros de consulta, la paginación, la limitación de tasa (rate limiting) y qué hacer cuando un nodo no está disponible o el resultado es demasiado grande.

Qué evalúa el entrevistador

• Distinguir NodeLogQuery de la lectura de archivos de nodos, logs de contenedores y un sistema de logging centralizado.
• Explicar enableSystemLogQuery, la autenticación y autorización de Kubelet, y el aislamiento de inquilinos.
• Considerar el rango de tiempo, la severidad, el tamaño de salida, los plazos límite (deadlines) y los límites de concurrencia.
• Proporcionar un flujo de trabajo operativo observable, auditable y reversible.

Preguntas aclaratorias para hacer

1. ¿Los objetivos son servicios del nodo, logs del kernel o stdout/stderr de los Pods? Tienen diferentes puntos de entrada.
2. ¿El solicitante es un administrador del clúster, un SRE de guardia o una plataforma de autoservicio para inquilinos?
3. ¿Se requieren consultas entre nodos, de largo alcance o seguimiento en vivo (live-follow)? Estas afectan la carga del nodo.
4. ¿Ya se encuentra disponible un sistema de recolección de logs para búsquedas históricas?

Estructura de respuesta de 30 segundos

Defina el límite primero: NodeLogQuery es una capacidad controlada de logs de nodo de Kubelet, no un acceso arbitrario a archivos. Luego presente el flujo: autenticar y autorizar al solicitante, validar el alcance del nodo y de la consulta, permitir que Kubelet invoque la interfaz de logs del nodo y devolver resultados delimitados. Finalice con barreras de protección: habilitar enableSystemLogQuery, limitar el tiempo, las líneas, los bytes, la concurrencia y los plazos límite; enviar las búsquedas históricas a logs centralizados; y auditar y alertar sobre solicitudes anormales.

Análisis detallado paso a paso

1. Definir las fuentes de logs y los límites de capacidades

NodeLogQuery se enfoca en los logs del sistema del nodo, tales como logs de systemd y del kernel. Stdout/stderr de los Pods debe utilizar el logging de contenedores o un recolector centralizado. La interfaz de consulta no debe aceptar rutas arbitrarias del sistema de archivos, leer directorios de credenciales ni eludir la autorización de Kubelet. Los inquilinos deben recibir eventos o agregados de nodos filtrados, mientras que los logs sin procesar del nodo permanecen limitados a roles de SRE controlados.

2. Autenticar, autorizar y aislar inquilinos

El endpoint HTTPS de Kubelet autentica al cliente antes de evaluar los atributos de la solicitud. El API Server o un proxy de operaciones utiliza una identidad dedicada cuyas reglas están limitadas a las capacidades de logs de nodo permitidas; los inquilinos no reciben nodes/proxy ni un acceso amplio equivalente. La plataforma también verifica la vinculación inquilino-nodo para que al cambiar un nombre o etiqueta de nodo no se pueda acceder al nodo de otro inquilino.

3. Delimitar consultas y proteger recursos

Exija un nodo explícito, unidad de servicio, rango de tiempo y severidad, con una ventana predeterminada corta. Establezca la duración máxima, los bytes devueltos, las líneas, la concurrencia y la tasa por inquilino. Cuando se alcance un límite, devuelva un token de página reanudable o un error claro. La transmisión en streaming es aceptable, pero una desconexión, plazo límite o tope debe liberar los recursos de Kubelet y del proxy.

4. Observar, manejar fallas y revertir cambios

Registre la identidad del solicitante, el nodo, el resumen de parámetros, la hora de inicio y fin, los bytes devueltos, el motivo de truncamiento y el resultado de la autorización; no copie el contenido de los logs en el flujo de auditoría. Falle rápido (fail fast) cuando un nodo no esté disponible y recomiende logs centralizados. Active un disyuntor (circuit breaker) y alerte cuando Kubelet esté sobrecargado. NodeLogQuery es estable y está habilitado de forma predeterminada en v1.36, mientras que enableSystemLogQuery sigue siendo una configuración operativa; despliegue en un nodo canary y mantenga una ruta de desactivación.

Respuesta modelo

Haría de NodeLogQuery una interfaz de diagnóstico de nodos controlada, no un explorador de archivos. Primero separaría los logs del sistema, los logs de contenedores y la búsqueda histórica centralizada. Los solicitantes se autentican y autorizan a través de Kubelet y solo pueden consultar nodos y tipos de logs aprobados. Los inquilinos no reciben acceso amplio a nodes/proxy, y la plataforma verifica la vinculación entre inquilino y nodo.

Cada consulta incluye un nodo, unidad de servicio, rango de tiempo y severidad con una ventana predeterminada corta. Aplique límites de bytes, líneas, concurrencia, tasa y plazos límite; transmita o pagine los resultados y reporte el truncamiento. Las auditorías conservan la identidad, el nodo, el resumen de parámetros, la duración, el tamaño y la decisión, nunca el cuerpo. Los nodos no disponibles y los Kubelets sobrecargados fallan rápido, activan un disyuntor y dirigen a los usuarios a logs centralizados. NodeLogQuery es estable y viene activado por defecto en v1.36, pero aplicaría canary a enableSystemLogQuery y conservaría la opción de reversión.

Errores comunes

• Tratar a NodeLogQuery como un acceso arbitrario a archivos del nodo.
• Otorgar a los inquilinos nodes/proxy e ignorar el aislamiento entre nodos e inquilinos.
• Permitir rangos de tiempo, salida o concurrencia sin límites.
• Escribir cuerpos de logs en el flujo de auditoría y provocar una segunda fuga de datos sensibles.
• Reintentar indefinidamente con nodos no disponibles y amplificar la carga del plano de control o de Kubelet.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué no enviar todas las consultas históricas a través de NodeLogQuery?

El endpoint del nodo es adecuado para diagnósticos en tiempo casi real. La recolección centralizada debe encargarse de la búsqueda histórica, la indexación, el aislamiento de inquilinos y la retención sin consumir recursos de Kubelet en lecturas prolongadas.

Pregunta de seguimiento 2: ¿Cómo demuestra que la consulta no puede cruzar los límites de un inquilino?

Registre la identidad, el nodo, el recurso y la decisión para cada solicitud. Utilice pruebas sintéticas para demostrar que un nodo permitido tiene éxito y el nodo de otro inquilino se deniega, y verifique que el proxy rechace rutas arbitrarias y parámetros de nodo indebidos.

Pregunta de seguimiento 3: ¿Qué pasa si los logs contienen credenciales?

No dependa de una redacción basada en conjeturas e irreversible en la respuesta. Reduzca el alcance de la consulta, los roles y la retención, y realice una redacción estructurada durante la recolección. Revoque el acceso afectado y rote las credenciales cuando se encuentre un campo de alto riesgo.