pi2 tournait à load average ~45 (4 cœurs) pendant qu'un push docker
timeoutait vers le registre. Gitea et Postgres tournent en docker compose
nu, hors k3s — invisibles du scheduler ET sans limite (`docker inspect`
mesurait NanoCPUs=0, Memory=0 pour les deux), donc rien ne les empêchait
de se battre à armes égales avec tout le reste du nœud.
Postgres → 1 CPU / 1024M, Gitea → 1.5 CPU / 1536M (Compose v2 honore
`deploy.resources.limits` hors swarm). Valeurs dérivées d'une mesure au
repos (Postgres 3-5 %, Gitea 12 % CPU) avec de la marge pour les pics —
un filet, pas un dimensionnement pour la charge normale.
Appliqué et vérifié en direct sur pi2 : les deux conteneurs ont recréé
avec les nouvelles limites (`docker inspect` confirme), PostGIS survit
au recreate de Postgres (déjà géré par ce playbook), Gitea sert web (200)
et registre (401 attendu, anonyme) normalement après coup.
Le levier complémentaire (kubelet --system-reserved/--kube-reserved sur
pi2, pour que le SCHEDULER k8s sache que cette place est déjà prise) n'est
pas dans cette PR — plus gros, touche system_k3s.yml pour tout le cluster.
arcodange