Tras el desalojo del 2026-08-12 no quedaba nada que mirar: el emptyDir
muere con el pod, así que la causa hubo que deducirla por descarte.
Ahora el janitor mide /dind (montado en solo lectura) antes y después de
cada barrido y lo escribe en su log, cada 6h. La próxima vez habrá curva
de crecimiento medida en vez de conjeturas.
No se usa Prometheus porque no puede verlo: kubelet_volume_stats_* solo
emite series para PVCs y container_fs_usage_bytes viene vacío en k3s.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El pod fue desalojado el 2026-08-12 tras 21 días: el emptyDir de dind
superó su límite de 10Gi.
La caché de buildx no era la causa (los workflows hacen `buildx rm` al
inicio de cada run y se recicla sola, ~330M). Lo que se acumula son
imágenes sin tag: al republicar upstream catthehacker/ubuntu:act-22.04,
la anterior (1,5G) queda colgada para siempre.
Ni el GC de dockerd ni el de buildkit lo recogen porque ambos calculan
su umbral contra el disco del nodo (913G), no contra el cap del pod.
Nunca saltan antes del desalojo.
El sidecar hace `docker image prune -f` cada 6h por localhost:2375.
Sin -a: solo dangling, nunca una imagen con tag, así que la caché de
act y la de buildkit siguen intactas y los builds no se frenan.
Se descartó un CronJob externo: exigiría pods/exec o publicar el 2375
como Service, y ese puerto va sin TLS ni auth sobre un docker
privilegiado.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El worker llegó al 80,9% de disco: 223 imágenes para ~20 pods, 62 GB en
containerd. Cada build de CI publica un tag y nadie recoge los viejos —
97 tags de researchowl y 105 de polymarket-bot, decomisada en julio.
El GC de kubelet no basta: solo entra al 85% de imagefs, o sea cuando ya
no queda sitio. Un prune manual dejó el worker en 23% (54 GB) y el master
en 15% (58 GB).
Un CronJob por nodo porque un CronJob programa un solo pod; el nodo se
fija con nodeSelector. Domingos 06:30 y 07:15, el hueco entre backups.
El script hace varias pasadas a propósito: borrar snapshots satura a
containerd y las llamadas siguientes dan DeadlineExceeded. No es fallo,
es cola. Se reintenta mirando la salida, no el código de retorno, porque
crictl devuelve 0 aunque haya borrados fallidos.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Las tres secretKeyRef van optional: true: mientras no existan en Infisical
el pod arranca igual y el comando contesta 'no configurado'. Sin optional,
una clave que aún no está deja el Deployment en CreateContainerConfigError
y tira el bot entero por una función sin estrenar.
YOUTUBE_PRIVACY=private documenta el candado: los vídeos por API de un
proyecto sin auditar quedan privados los pidas como los pidas.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Renovate seguia escaneandolo 6 veces al dia y empujando ramas a un repo
muerto: renovate/uvicorn-0.x se actualizo el 2-ago, 16 dias despues del
decomiso. Misma familia que el bloque de Polymarket del Resumen Diario:
decomisar un servicio no lo saca de las cosas que lo miran.
Quedan 11 ramas renovate/* en el repo; se limpian aparte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El primer render real murio OOMKilled con el limite de 1Gi que salia de medir en
la maquina de desarrollo. El host lleva ffmpeg 4.4.2 y la imagen 7.1.5, y 7.0
reescribio la transcodificacion sobre un planificador con colas de fotogramas
decodificados entre componentes: pasarle el WAV como segunda entrada dejaba al
decodificador de video correr por delante y llenar una cola con fotogramas de
6,2 MB. Arreglado partiendo el encode en dos pasos (repo shortsmith), y aqui van
las cifras nuevas, medidas dentro del pod.
requests 768Mi (pico anon 640 MB), limits 1536Mi. El limite no es 1Gi por el
caso techo de 180 s: ahi el pico era 940 MB de 1024 y sobrevivia solo porque
quedaba cache reclamable que soltar. A 1.5Gi memory.events da max 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Renderizador determinista JSON->MP4 para Shorts. API interna sin Ingress, en
shortsmith-svc:8080; la cola es por proceso y la SQLite va en RWO, de ahí la
replica unica con estrategia Recreate.
Los recursos van medidos, no estimados, y la tabla con las cifras queda en el
propio manifiesto: el pico son 522 MB de anon y lo pone entero el encode, no el
render. Ojo al comentario sobre por que los workers salen del limite de CPU y no
del request.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un barrido hecho con cp dijo que un cambio recien escrito no estaba, media
hora despues de escribirlo. La copia no tiene los ultimos commits y no da
ningun error.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El GET de comprobacion no miraba su propio codigo HTTP. Un 403 devuelve un
objeto Status, que parsea como JSON perfectamente y luego revienta en
dep.spec.replicas ("Cannot read properties of undefined (reading 'replicas')").
El aviso resultante decia "reinicio fallido, intervencion manual necesaria"
cuando el reinicio habia ido BIEN y lo unico roto era la verificacion.
Falso negativo, mucho menos grave que el falso positivo de ayer -- pero te
levanta de la cama para nada, y estando Jose fuera eso importa.
Ahora el nodo marca verificable:false cuando no ha podido comprobar (HTTP no
2xx, cuerpo ilegible o error de red) y el aviso lo dice con esas palabras,
con el codigo de la comprobacion aparte del codigo del PATCH.
Reproducido en produccion: POST legitimo a las 08:43:22 (PATCH ok, restartedAt
cambia), permiso retirado a los 15 s, GET a los 60 s con 403. Ejecucion de
60,394 s, o sea el camino completo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anade tambien como leer por que rama fue una ejecucion cuando
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none ya la ha vaciado: por la duracion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Tres agujeros que encontro una review adversarial de Codex sobre el trabajo
de ayer. Los tres verificados contra el fichero antes de tocar nada.
1. El webhook publico fallaba en ABIERTO. Con `optional: true` y un
`if (secreto && ...)`, la ausencia del secreto equivalia a autorizacion:
cualquier POST con heartbeat.status=0 y un monitor.name del mapa reiniciaba
n8n, Gitea, ArgoCD, Vaultwarden o los blogs. El argumento para dejarlo asi
era "que un despiste no te deje sin avisos", y era falso: el aviso de caida
lo manda Kuma por su notificacion 1, directa, no por este webhook.
Ahora el secreto es obligatorio (sin `optional`) y la puerta rechaza si
falta. Secreto ausente da error ruidoso; cabecera que no casa, vacio.
2. El ClusterRole permitia patch sobre CUALQUIER deployment de 10 namespaces,
y la SA va montada en el pod entero de n8n: cualquier workflow con un nodo
Code heredaba eso. Ahora son Roles por namespace con resourceNames sobre
los 12 workloads exactos del SERVICE_MAP.
3. El flujo daba exito aunque el PATCH fallara. `restartOk` se calculaba y se
tiraba: `K8s API Check Status` construia un objeto nuevo sin el, y el IF
final solo miraba `statusOk`. Un 403 sobre un servicio ya sano mandaba
"reiniciado correctamente". Ahora hay rama de fallo tras el PATCH y el
exito exige observedGeneration >= la generation que devolvio el PATCH.
Se compara con >= porque selfHeal de ArgoCD revierte la anotacion y vuelve
a subir la generation; con == daria un fallo falso.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gitea CI
chemavxandClaude Opus 5