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 commit 22ae5d7 (15-abr) fijó estos tags EN GIT pero nunca se aplicó al
cluster: estos namespaces no están en ArgoCD, así que un cambio en git no llega
solo. Tres meses después git decía 1.25.5 y gitea corría 1.27.0, subido en algún
reinicio sin que nadie lo decidiera. Ahora se fija a los dos lados.
gitea gitea/gitea:latest -> gitea/gitea:1.27.0
gitea (init) busybox -> busybox:1.38.0
gitea-runner gitea/act_runner:latest -> gitea/act_runner:0.6.1
gitea-runner docker:24-dind -> docker:24.0.9-dind
authentik-redis redis:alpine -> redis:8.8.0-alpine
uptime-kuma louislam/uptime-kuma:1 -> louislam/uptime-kuma:1.23.17
homarr homarr:latest -> homarr@sha256:80ee593c...
Los seis primeros se fijan a la MISMA imagen que ya corría: verificado
comparando el repoDigest del tag flotante con el del tag candidato, así que el
reinicio no cambió de versión. Homarr va por digest porque su "latest" es una
build de la rama main (org.opencontainers.image.version=main): no existe un tag
de release que describa lo que corre. Moverlo a una release es otra decisión.
Trampa que casi me come, anotada para la próxima: el imageID de un pod NO
siempre es el digest del registro. Si viene como "repo@sha256:..." lo es; si es
un "sha256:..." pelado es el id local de containerd y NO se puede descargar.
Fijar uptime-kuma a ese id dio ImagePullBackOff; el pod viejo aguantó sirviendo
(maxUnavailable 0 para 1 réplica) y se revirtió sin corte. La comparación buena
es repoDigest contra repoDigest.
De paso, al regenerar gitea-runner desde lo vivo quedan documentados el volumen
buildkitd-config y su montaje, que existían en el cluster y no en git.
Verificado tras cada cambio: rollout completo, versión de la app dentro del pod,
y los cinco servicios respondiendo desde fuera (git 200, home 200, status/auth/
grafana 302 por Authentik). El runner se ha vuelto a registrar en Gitea. Sigue
sin haber pods fuera de Running y las 18 apps de ArgoCD Synced+Healthy.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deploy registry:2 as Docker Hub pull-through cache on chemavx-k8 (hostPort 5000,
ClusterIP 10.43.163.56:5000). Configures dind runner to use local mirror via
daemon.json to eliminate Docker Hub rate limit failures in CI/CD.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
chemavxandClaude Opus 5