Files
deploy/astrololo/data.yaml
T
gitea eff9d206ac 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>
2026-08-26 21:44:02 +02:00

111 lines
5.2 KiB
YAML

apiVersion: apps/v1
kind: Deployment
metadata:
name: data
namespace: astrololo
spec:
replicas: 1
selector: { matchLabels: { app: data } }
template:
metadata: { labels: { app: data } }
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:
- name: data
image: gitea.czernobog.pl/gitea/astrololo-data:9323803c
ports: [{ containerPort: 8002 }]
env:
- name: DATA_PROVIDER
value: "excel"
- name: EXCEL_DIR
value: "/app/data_files" # montowane z NFS (patrz volumes) — NIE z obrazu
- name: CACHE_DIR
value: "/app/.cache"
- name: INDEXED_KEYS
value: "name,id,symbol"
# Token międzywarstwowy (LOG-32). Ta warstwa oddaje SUROWE wiersze baz —
# najwrażliwszy punkt systemu. Bez tokenu dałoby się ją odpytać
# bezpośrednio, z pominięciem i logiki, i logowania w UI.
- name: INTERNAL_TOKEN
valueFrom:
secretKeyRef: { name: astrololo-auth, key: INTERNAL_TOKEN }
# Szyfrowanie łącza między warstwami (PRE-16). OSOBNY klucz na każdą
# parę rozmówców: przejęcie klucza prezentacji nie otwiera warstwy
# danych, gdzie leżą całe bazy. Sekret tworzony POZA repo — patrz README.
- name: LINK_KEY_LOGIC_DATA
valueFrom:
secretKeyRef: { name: astrololo-link, key: LINK_KEY_LOGIC_DATA }
# Bez klucza usługa ma NIE wstać, a klient ma nie wysłać niczego.
# Sam serwer broni się fail-closed, ale to za mało: klient bez klucza
# zdążyłby wypuścić zapytanie jawnym tekstem, zanim dostanie odmowę.
- name: LINK_ENCRYPTION_REQUIRED
value: "true"
# Lustro baz w SQL (DAN-28). DSN w SEKRECIE, bo niesie hasło —
# w manifeście zostałoby w historii gita na zawsze.
#
# Sam adres nie przełącza jeszcze warstwy na SQL: o tym decyduje
# DATA_PROVIDER, które celowo zostaje na `excel`, dopóki lustro nie
# jest zaimplementowane i sprawdzone. Dzięki temu Postgres można
# wdrożyć i obejrzeć BEZ ryzyka dla działającego wyszukiwania.
- name: SQL_URL
valueFrom:
secretKeyRef: { name: astrololo-postgres, key: SQL_URL }
volumeMounts:
- name: cache
mountPath: /app/.cache
# ZAPISYWALNY od DAN-27. Wcześniej read-only, bo warstwa danych tylko
# czytała bazy — teraz ekran „Pliki" pozwala je wgrywać, archiwizować
# i (dla administratora) kasować, a stan użycia jest KLIKANY, więc musi
# przetrwać restart poda.
#
# ŚWIADOMY KOSZT: znika jedna warstwa obrony w głąb. Przejęcie warstwy
# danych pozwala teraz nie tylko odczytać bazy, ale i je zmienić.
# Zostaje reszta: token międzywarstwowy, szyfrowane łącze, ograniczenie
# eksportu NFS do konkretnych hostów (DAN-25) i to, że kasować może
# wyłącznie konto administracyjne (PRE-27).
- name: excel
mountPath: /app/data_files
resources:
requests: { cpu: "100m", memory: "256Mi" }
limits: { cpu: "500m", memory: "512Mi" }
volumes:
- name: cache
emptyDir: {} # cache ulotny; odbuduje się po restarcie
- name: excel
nfs:
server: 192.168.1.34
path: /mnt/Tank1/astrololo
---
apiVersion: v1
kind: Service
metadata:
name: data
namespace: astrololo
spec:
selector: { app: data }
ports: [{ port: 8002, targetPort: 8002 }]