data: wymagaj węzła z x86-64-v2; runbook maskowania CPU i lista czterech węzłów

data-demo wpadał w pętlę restartów na k3s-agent3:

  RuntimeError: NumPy was built with baseline optimizations:
  (X86_V2) but your machine doesn't support: (X86_V2).

DIAGNOZA — to NIE jest różnica sprzętu. Wszystkie cztery węzły to maszyny
wirtualne. Trzy widzą procesor jako „QEMU Virtual CPU 2.5+" i mają komplet
rozszerzeń x86-64-v2; agent3 widzi „Common KVM processor" (kvm64) i nie ma
popcnt, ssse3, sse4_1 ani sse4_2. Fizyczny i7-3770 pod spodem obsługuje nawet
x86-64-v3 — te flagi są MASKOWANE przez domyślny model CPU w Proxmoksie.

agent3 ma 14 dni, pozostałe 52. Został dołożony później i pominięto przy nim
krok `--cpu host`, odnotowany w pamięci projektu 2 sierpnia. Nikt tego nie
zauważył, dopóki scheduler nie postawił tam akurat warstwy danych — jedynej,
która ciągnie pandas, a przez nią NumPy.

ZABEZPIECZENIE: data i data-demo wymagają etykiety
`astrololo.czernobog.pl/cpu-x86-64-v2`. Świadomie ETYKIETA, a nie wykluczenie
agent3 po nazwie: wykluczanie po nazwie znaczyłoby, że każdy KOLEJNY źle
postawiony węzeł znów zbiera się przez awarię. Nowy węzeł jest domyślnie
nieoznaczony, więc nie dostanie tych podów, dopóki ktoś go nie sprawdzi
i nie oznaczy. Pending z czytelnym powodem bije pętlę restartów z komunikatem
o „baseline optimizations".

KOLEJNOŚĆ: węzły trzeba oznaczyć PRZED wdrożeniem tej zmiany. Dziś etykietę ma
zero węzłów, więc samo zmergowanie posłałoby data w Pending.

RUNBOOK: skrypt sprawdzający węzły, naprawa u źródła (`qm set --cpu host` plus
pełne wyłączenie i włączenie maszyny — sam restart z gościa nie wystarcza),
oraz zastrzeżenie, że `--cpu host` blokuje migrację na żywo między hostami
o różnych procesorach.

PUŁAPKA PRZY CZYTANIU FLAG, udokumentowana bo kosztowała fałszywą diagnozę:
Linux raportuje SSE3 jako „pni", nie „sse3". Pierwsza wersja kontroli wskazała
przez to trzy zdrowe węzły jako niesprawne.

Przy okazji: lista węzłów w eksportach NFS obejmuje wszystkie cztery. Runbooki
wymieniały trzy, a klaster ma cztery — ten sam mechanizm, ta sama przyczyna.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

astrololo/data.yaml

@@ -12,6 +12,26 @@ spec:
       # LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
       # serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
       # punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
+      # Ta usługa liczy na pandas, a przez nią na NumPy. Koła NumPy z PyPI są
+      # budowane z bazą x86-64-v2, więc na węźle bez tych rozszerzeń kontener
+      # NIE WSTAJE: `import numpy` kończy się RuntimeError, pod wpada w pętlę
+      # restartów, a komunikat mówi o „baseline optimizations" — czyli o niczym,
+      # po czym dałoby się poznać, że chodzi o węzeł.
+      #
+      # Wymagana ETYKIETA, a nie wykluczony konkretny węzeł. Nowy węzeł jest
+      # domyślnie NIEOZNACZONY, więc nie dostanie tu poda, dopóki ktoś go nie
+      # sprawdzi (skrypt w README) i nie oznaczy świadomie. Pending z czytelnym
+      # powodem jest lepszy niż pętla restartów z komunikatem o optymalizacjach —
+      # a wykluczanie węzłów po nazwie znaczyłoby, że każdy KOLEJNY źle
+      # postawiony węzeł znów zbiera się przez awarię.
+      affinity:
+        nodeAffinity:
+          requiredDuringSchedulingIgnoredDuringExecution:
+            nodeSelectorTerms:
+              - matchExpressions:
+                  - key: astrololo.czernobog.pl/cpu-x86-64-v2
+                    operator: In
+                    values: ["true"]
       automountServiceAccountToken: false
       imagePullSecrets: [{ name: gitea-registry }]
       containers: