Kubernetes: 401 fugaces en CronJobs

Hay fallos que se ven dramaticos en Slack y luego desaparecen antes de que abras el dashboard. Los 401 intermitentes en un CronJob entran justo en esa categoria. El job corre bien casi toda la semana, pero a las 3:00 o 4:00 AM falla una vez, reintenta, y despues todo queda verde. En guardia esto confunde bastante, porque parece un problema de red cuando muchas veces es autenticacion, reloj o contexto de ejecucion.

Cuando me toca revisar algo asi, intento no empezar por el proveedor externo. Primero reviso el contrato basico del job: identidad, token, tiempo y configuracion efectiva. Ese runbook pequeno evita dar vueltas medio tontas.

Por que un 401 aparece solo de madrugada

El patron mas comun no es "la API amanecio rota". Suelo ver una de estas causas:

1. El pod toma un token distinto al esperado o uno ya casi vencido.
2. El job arranca con variables viejas despues de una rotacion de secretos.
3. Hay skew de reloj entre nodo, workload y servicio remoto.
4. El endpoint remoto aplica ventanas de validacion mas estrictas en ciertos flujos.

En Kubernetes, varios detalles de CronJob ya invitan a mirar tiempo y scheduling. La documentacion oficial recuerda que el controlador de CronJob revisa el schedule cada 10 segundos, asi que ventanas muy chicas pueden producir comportamientos sorprendentes en la ejecucion programada: CronJob limitations. No explica un 401 por si solo, claro, pero si te obliga a revisar el momento exacto en que el job nacio y con que contexto salio.

El runbook corto que uso primero

Si estoy ayudando a otra persona de guardia, le pido estos cuatro datos antes de discutir teorias:

1. kubectl describe job <job> y kubectl describe pod <pod>
2. logs del intento fallido y del siguiente intento exitoso
3. manifiesto real del CronJob con env, serviceAccountName y volumenes proyectados
4. hora UTC del 401 y hora UTC del ultimo cambio de secreto o despliegue

Con eso ya puedes armar un diff util. El error no siempre esta en el mensaje HTTP; a veces esta en el contexto que cambió cinco minutos antes y nadie lo relacionó. Tener un par de runbooks pequenos que si escalan ayuda mucho porque fuerza a capturar evidencia y no intuiciones.

Este checklist minimo tambien me gusta:

1. Confirmar si el 401 ocurre antes o despues del primer retry.
2. Ver si el pod usa serviceAccountName correcto.
3. Revisar expiracion de token, no solo presencia de token.
4. Comparar headers o claims entre intento bueno y malo.
5. Mirar si el secreto montado cambió pero el cliente conserva cache interna.

Parece obvio, pero en incidentes reales la mitad del tiempo se pierde porque alguien valida solo que "la variable existe". Y existir no alcanza; tiene que ser la credencial correcta, fresca y legible por el proceso. Es una diferencia chica, pero importantisima.

Donde suele estar la causa real

En clusters modernos, yo revisaria muy pronto los tokens proyectados de ServiceAccount. Kubernetes explica que estos tokens tienen expiracion y se rotan automaticamente, lo que mejora seguridad pero tambien deja expuestos a clientes que leen el token una vez y nunca lo refrescan: ServiceAccount token projection. Si tu binario cachea el token al inicio y el job vive mas de lo previsto, ya tienes una pista bastante fuerte.

La segunda causa repetida es una rotacion de secretos mal sincronizada. El secreto nuevo existe, el workload nuevo aun no corre, y el CronJob dispara justo en esa franja rara. El 401 aparece una sola vez, luego el siguiente pod arranca con la version correcta y parece "magia". No lo es, solo fue timing feo.

Tambien miraria endpoints que firman peticiones con timestamp. Cuando el nodo o la imagen base trae hora desalineada, el servicio remoto rechaza la firma aunque la llave sea buena. No es lo mas comun, pero cuando pasa se siente bastante injusto, la verda.

Un detalle mas: si el job toca sistemas de prueba, vas a encontrar rastros raros en payloads y notas operativas, cosas como temp mailid o dummy e mail pegadas en fixtures o variables locales. No son la causa del 401, pero sirven como señal de que el flujo mezcla trafico de QA con operacion real y eso enturbia el analisis.

En esa parte me ayuda pensar en contratos operativos faciles de auditar: que credencial espero, donde se monta, cuanto dura, que claim valida el remoto y que evidencia dejo si falla. Cuando ese contrato no existe, el incidente se alarga por puro desorden.

Que dejar automatizado para la siguiente guardia

Si ya encontraste la causa, no cierres el caso sin dejar una mejora chica. Mis favoritas:

1. Loggear issuer, audience y expiracion del token sin imprimir secretos.
2. Emitir una metrica por causa de 401 clasificada en cliente, credencial o remoto.
3. Guardar hash de version de secreto o config usada por cada job.
4. Fallar rapido cuando falte serviceAccountName esperado.
5. Añadir una prueba que levante el job con credenciales rotadas.

No hace falta un sistema enorme. Con dos o tres señales bien elegidas, el siguiente incidente cae mucho mas rapido. Y eso para SRE vale oro, sobre todo en turnos donde el cerebro aun no desperto del todo.

Preguntas frecuentes

Conviene reintentar automaticamente un 401?

Solo si sabes distinguir entre credencial vencida y permiso realmente denegado. Reintentar a ciegas puede esconder el problema y llenar de ruido los logs.

Que comparo entre un intento bueno y uno malo?

Hora de inicio, service account, claims del token, version del secreto y destino exacto. Si comparas solo el body del error, casi nunca alcanza.

Esto pasa solo en jobs largos?

No. Tambien aparece en jobs cortos que arrancan durante una ventana de cambio de secretos, de rollout o de permisos. A veces dura segundos, pero rompe igual.

Si un CronJob tuyo falla con 401 solo de madrugada, yo no empezaria por culpar a la API externa. Empezaria por identidad, tiempo y evidencia del pod. Casi siempre ahi esta el hilo del que tirar, aunque al principio se vea pequeñito.