fix(k3s) — kubelet-arg guillemeté cassait le parsing, + réservation pi2

Le scheduler k8s croyait disposer des 4 cœurs / 7,6 Gi entiers de pi2,
alors que Gitea et Postgres (docker compose nu, hors k3s, PR factory#54)
en consomment une part invisible. `--kubelet-arg="system-reserved=cpu=2,
memory=2Gi"` sur l'agent pi2 corrige ça — réservation informative, pas
d'--enforce-node-allocatable, donc pas de nouvelle éviction.

En le déployant : incident réel. `--kubelet-arg="k=v"` (guillemets
littéraux autour de key=value) ressort en `\=` littéral dans l'ExecStart
que k3s-install.sh régénère — kubelet refuse de démarrer ("unknown flag:
--container-log-max-files\"), boucle de redémarrage jusqu'à NotReady.
C'était déjà le cas pour les DEUX args pré-existants (container-log-max-
files, container-log-max-size), latent depuis des mois parce que
k3s-agent n'avait pas redémarré depuis avril — jamais régénéré par la
version actuelle du script. Mon changement a déclenché le premier
restart réel et l'a fait sortir.

pi2 a été NotReady ~3 min pendant le diagnostic puis la correction en
direct (aucun pod évincé, sous le pod-eviction-timeout par défaut de
5 min — vérifié). Les DEUX occurrences pré-existantes sont corrigées ici
aussi (extra_server_args ET extra_agent_args), pas seulement la mienne :
pi1 (le control-plane) porte le MÊME bug dans sa source, dormant parce
que son k3s.service n'a pas non plus redémarré récemment. Sans cette
PR, le prochain restart de pi1 (reboot, ou un futur run de ce playbook)
aurait cassé l'API server de la même façon.

Le format sans guillemets (`--kubelet-arg=k=v`) traverse la génération
intact — vérifié par la correction en direct sur pi2 (journal confirme
`--system-reserved=cpu=2,memory=2Gi` sans backslash, service stable,
Allocatable descendu de 4 cœurs/8Gi à 2 cœurs/5,6Gi).

ansible/arcodange/factory/inventory/hosts.yml

@@ -8,6 +8,13 @@ raspberries:
       ansible_host: pi2.home
       preferred_ip: 192.168.1.202
       ansible_ssh_extra_args: '-o StrictHostKeyChecking=no'
+      # Gitea + Postgres tournent ici en docker compose nu, hors k3s (cf.
+      # inventory/group_vars/gitea|postgres) : invisibles du scheduler k8s,
+      # qui croyait donc disposer des 4 cœurs / 7,6 Gi en entier. Réservé
+      # informatif seulement (pas d'--enforce-node-allocatable ajouté) : ça
+      # réduit l'Allocatable annoncé par le kubelet, pas d'éviction ajoutée.
+      kubelet_reserved_args: >-
+        --kubelet-arg=system-reserved=cpu=2,memory=2Gi
     pi3:
       ansible_host: pi3.home
       preferred_ip: 192.168.1.203

ansible/arcodange/factory/playbooks/system/system_k3s.yml

@@ -34,14 +34,23 @@
   # ansible.builtin.import_playbook: k3s.orchestration.reset
   vars:
     k3s_version: v1.34.3+k3s1
+    # ⚠ PAS de guillemets autour de key=value : `--kubelet-arg="k=v"` (avec
+    # guillemets) fait ressortir un `\=` littéral dans l'ExecStart généré par
+    # k3s-install.sh — kubelet refuse ensuite de démarrer ("unknown flag:
+    # --container-log-max-files\"), boucle de redémarrage jusqu'à NotReady.
+    # Mesuré le 11/08 sur pi2 : latent depuis des mois (le service n'avait pas
+    # redémarré depuis avril, donc jamais régénéré par la version actuelle du
+    # script), révélé par le premier restart forcé par ce playbook. La forme
+    # SANS guillemets (`--kubelet-arg=k=v`) traverse la génération intacte.
     extra_server_args: >-
       --docker --disable traefik
-      --kubelet-arg="container-log-max-files=5"
-      --kubelet-arg="container-log-max-size=10Mi"
+      --kubelet-arg=container-log-max-files=5
+      --kubelet-arg=container-log-max-size=10Mi
     extra_agent_args: >-
       --docker
-      --kubelet-arg="container-log-max-files=5"
-      --kubelet-arg="container-log-max-size=10Mi"
+      --kubelet-arg=container-log-max-files=5
+      --kubelet-arg=container-log-max-size=10Mi
+      {{ kubelet_reserved_args | default('') }}
     api_endpoint: "{{ hostvars[groups['server'][0]]['ansible_host'] | default(groups['server'][0]) }}"
 
 - name: how to reach k3s