pi2 tournait à load average ~45 (sur 4 cœurs) pendant qu'un docker push vers le registre timeoutait. Gitea et Postgres tournent en docker compose nu sur pi2, hors k3s — donc invisibles du scheduler k8s et sans aucune limite (docker inspect mesurait NanoCPUs=0, Memory=0 pour les deux). Rien ne les empêchait de se battre à armes égales avec tout le reste du nœud (k3s, Longhorn instance-manager, ArgoCD…).
Changement
Postgres → 1 CPU / 1024M
Gitea → 1.5 CPU / 1536M
Via deploy.resources.limits (Compose v2 l'honore 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. À réajuster si un gros push ou une grosse requête se fait throttle/tuer.
Déployé et vérifié en direct
ansible-playbook playbooks/setup/postgres.yml puis playbooks/setup/gitea.yml, scopés (pas le 02_setup.yml complet) — failed=0, unreachable=0 sur les deux.
docker inspect sur pi2 confirme les deux conteneurs recréés avec les nouvelles limites.
PostGIS survit au recreate de Postgres (déjà géré par ce playbook, vérifié : 3.4 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 sur kadans).
Gitea sert web (200) et registre (401 attendu, anonyme) normalement après coup.
Load average pi2 redescendu (45 → ~10 en 1 min) — une partie de la baisse vient probablement aussi du rebuild Longhorn résolu séparément aujourd'hui, donc pas 100 % attribuable à ce changement seul.
Hors périmètre
Le levier complémentaire — kubelet --system-reserved/--kube-reserved sur pi2, pour que le scheduler k8s sache que cette place est déjà prise — touche system_k3s.yml (tout le cluster, k3s server + agents). Plus gros risque, pas dans cette PR.
## Contexte
pi2 tournait à load average ~45 (sur 4 cœurs) pendant qu'un `docker push` vers le registre timeoutait. Gitea et Postgres tournent en `docker compose` nu sur pi2, hors k3s — donc invisibles du scheduler k8s **et** sans aucune limite (`docker inspect` mesurait `NanoCPUs=0, Memory=0` pour les deux). Rien ne les empêchait de se battre à armes égales avec tout le reste du nœud (k3s, Longhorn instance-manager, ArgoCD…).
## Changement
- Postgres → `1 CPU / 1024M`
- Gitea → `1.5 CPU / 1536M`
Via `deploy.resources.limits` (Compose v2 l'honore 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. À réajuster si un gros push ou une grosse requête se fait throttle/tuer.
## Déployé et vérifié en direct
- `ansible-playbook playbooks/setup/postgres.yml` puis `playbooks/setup/gitea.yml`, scopés (pas le `02_setup.yml` complet) — `failed=0`, `unreachable=0` sur les deux.
- `docker inspect` sur pi2 confirme les deux conteneurs recréés avec les nouvelles limites.
- PostGIS survit au recreate de Postgres (déjà géré par ce playbook, vérifié : `3.4 USE_GEOS=1 USE_PROJ=1 USE_STATS=1` sur `kadans`).
- Gitea sert web (200) et registre (401 attendu, anonyme) normalement après coup.
- Load average pi2 redescendu (45 → ~10 en 1 min) — une partie de la baisse vient probablement aussi du rebuild Longhorn résolu séparément aujourd'hui, donc pas 100 % attribuable à ce changement seul.
## Hors périmètre
Le levier complémentaire — kubelet `--system-reserved`/`--kube-reserved` sur pi2, pour que le **scheduler** k8s sache que cette place est déjà prise — touche `system_k3s.yml` (tout le cluster, k3s server + agents). Plus gros risque, pas dans cette PR.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Contexte
pi2 tournait à load average ~45 (sur 4 cœurs) pendant qu'un
docker pushvers le registre timeoutait. Gitea et Postgres tournent endocker composenu sur pi2, hors k3s — donc invisibles du scheduler k8s et sans aucune limite (docker inspectmesuraitNanoCPUs=0, Memory=0pour les deux). Rien ne les empêchait de se battre à armes égales avec tout le reste du nœud (k3s, Longhorn instance-manager, ArgoCD…).Changement
1 CPU / 1024M1.5 CPU / 1536MVia
deploy.resources.limits(Compose v2 l'honore 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. À réajuster si un gros push ou une grosse requête se fait throttle/tuer.Déployé et vérifié en direct
ansible-playbook playbooks/setup/postgres.ymlpuisplaybooks/setup/gitea.yml, scopés (pas le02_setup.ymlcomplet) —failed=0,unreachable=0sur les deux.docker inspectsur pi2 confirme les deux conteneurs recréés avec les nouvelles limites.3.4 USE_GEOS=1 USE_PROJ=1 USE_STATS=1surkadans).Hors périmètre
Le levier complémentaire — kubelet
--system-reserved/--kube-reservedsur pi2, pour que le scheduler k8s sache que cette place est déjà prise — touchesystem_k3s.yml(tout le cluster, k3s server + agents). Plus gros risque, pas dans cette PR.🤖 Generated with Claude Code