Kubernetes: depura 401 intermitentes con contexto

Los 401 intermitentes en Kubernetes son de esas alertas que desgastan mas de lo que parecen. Un pod responde bien durante media hora, luego falla dos minutos, despues vuelve a la vida, y la tentacion es reiniciar primero y pensar despues. El problema es que ese reinicio muchas veces borra la pista util.

En guardias SRE me funciona tratar este fallo como un rompecabezas pequeno: credencial, reloj, cache, permisos y dependencia externa. Casi nunca es una sola cosa, y por eso conviene entrar con un orden simple. Si no, acabas mezclando sintomas de app con sintomas de plataforma y el incidente se vuelve pegajoso.

Por que un 401 intermitente engancha tanto

Lo dificil no es el 401 en si. Lo dificil es que suele aparecer en una ruta concreta, con volumen irregular, y encima convive con metricas que se ven normales. CPU bien. Memoria bien. Latencia promedio aceptable. Pero un flujo de negocio ya esta roto.

He visto tres causas repetirse bastante:

1. Un secreto se roto bien en Kubernetes, pero la aplicacion relee tarde o nunca.
2. El token sigue vivo en unos workers y vencio en otros por diferencia de arranque.
3. La API externa responde 401 por una condicion secundaria, como reloj desfasado o audiencia incorrecta.

En ese punto, reiniciar todo aveces mejora la foto unos minutos, pero no te dice cual causa era la real. Y si el problema vuelve en la siguiente ventana de trafico, el equipo queda igual de ciego.

Que mirar antes de reiniciar

Mi regla es revisar primero cuatro piezas:

1. Si el secreto o token cambio de verdad y cuando cambio.
2. Que workloads consumen esa credencial.
3. Si el fallo ocurre en todos los pods o solo en una parte.
4. Que dice la dependencia externa sobre rechazos recientes.

Con eso ya puedes evitar media docena de hipotesis flojas. Un chequeo inicial puede ser tan simple como esto:

kubectl get secret api-credential -n billing -o yaml | head -n 20
kubectl get pods -n billing -o wide
kubectl logs deploy/billing-api -n billing --since=15m | rg "401|403|expired|audience|token"
kubectl describe pod -n billing billing-api-7d9f6d7d7b-abcde

Tambien suelo mirar si hubo algun cambio de rollout, porque a veces el problema no es "token malo" sino mezcla de replicas nuevas y viejas. Esa diferencia de estado engancha mucho. En otros equipos lo comparo con validar sin castigar cada tecla: si no separas la senal buena del ruido, terminas reaccionando a cada salto aunque el sistema no te este diciendo la verdad completa.

Un runbook corto para separar causas

Este orden me ha servido bastante bien:

1. Confirmar si el 401 viene del servicio propio o de una API aguas abajo.
2. Revisar timestamp de la ultima rotacion y hora de arranque de cada pod afectado.
3. Comparar un pod sano con uno fallando: env vars, volumenes, service account, reloj y logs.
4. Probar una llamada controlada con la misma credencial fuera del pod, si el entorno lo permite.
5. Reiniciar solo una replica o canary cuando ya tengas una hipotesis fuerte.

El punto tres parece aburrido, pero suele ahorrar mucho. Si un pod viejo funciona y uno nuevo no, ya no estas delante de un incidente "global". Estas delante de una diferencia concreta de configuracion, montaje o init flow. Eso cambia la conversacion por completo.

Cuando necesito dejar evidencia clara, anoto algo asi:

• pods afectados y pods sanos
• hora de arranque de cada uno
• version del secreto observada
• error exacto devuelto por la API
• resultado de una prueba manual corta

No hace falta un documento perfecto. Hace falta una ruta para que el siguiente operador no empiece desde cero, que pasa mas de lo que deberia.

Como valido el fix sin inventarme senales

Una vez rota la credencial o corregido el consumer, intento validar con dos capas. Primero, la llamada principal que antes devolvia 401. Segundo, una senal secundaria que use la misma ruta funcional pero no dependa solo de "parece que ya no falla".

Si tu flujo manda correos, crea jobs o dispara callbacks, una validacion secundaria ayuda. Pero hay que usarla con cuidado. Si la cola o el sistema auxiliar ya iba lento, puedes leer una conclusion falsa. Ese tipo de error se parece bastante a una validacion sin saltos ni foco roto: el objetivo no es producir mas eventos, sino confirmar el estado correcto con el menor ruido posible.

En pruebas internas he visto equipos usar buzones de descarte y nombres de referencia como temp mail so o tempmailso para no mezclar cuentas reales. Esta bien como apoyo. Lo que no conviene es convertir esa prueba en la unica evidencia del fix. Y si aparece en notas viejas algo como tepm mail com o temp mailid, lo trato como pista sucia de QA, no como verdad operativa.

Si quieres una comprobacion algo mas seria, compara:

• tasa de 401 antes y despues del cambio
• porcentaje de pods sanos por replica set
• eventos de rotacion o rollout en la misma ventana
• una prueba manual repetible contra el endpoint afectado

Cuando esas cuatro piezas se alinean, ya puedes cerrar la incidencia con bastante mas calma.

Checklist para la proxima guardia

Antes de irme, dejo este checklist pequeno:

• cual fue la credencial implicada
• si el fallo venia de Kubernetes o de una dependencia externa
• cuantos pods estaban realmente afectados
• si la app relee secretos en caliente o no
• que cambio resolvio el 401
• que evidencia confirma que el fix aguanto

Es una lista simple, pero evita que la siguiente guardia repita los mismos dos o tres intentos fallidos. Y honestamente, eso ya vale mucho.

Q&A

Debo reiniciar todo al primer 401?

No. Si reinicias sin separar causas, puede parecer que arreglaste el problema cuando solo moviste el sintoma. Mejor compara pods, secreto y dependencia primero.

Como se si el error es de reloj o de permisos?

Busca el mensaje exacto del proveedor y compara timestamps entre nodos, pods y sistema emisor. Un 401 por reloj desfasado deja pistas distintas a un token vencido o una audiencia incorrecta.

Cuanta evidencia necesito para cerrar?

La suficiente para repetir la conclusion: logs, una prueba manual corta y una caida clara en errores despues del cambio. Si solo tienes intuicion, todavia falta un poco.