gitea
abc0f98034
Wszystkie cztery usługi biegły na koncie `default` z AUTOMATYCZNIE montowanym tokenem API Kubernetesa. Żadna z nich nie rozmawia z API klastra — sekrety dostają przez `secretKeyRef`, który wstrzykuje kubelet, nie pod. Token był więc zbędny, a leżał w każdym kontenerze jako gotowy punkt wyjścia do klastra dla kogoś, kto przejmie proces (np. przez lukę w zależności). `automountServiceAccountToken: false` w szablonie poda data/logic/presentation/ render. Zweryfikowane `kubectl kustomize` — pole trafia do `.spec.template.spec`, nie do specu Deploymentu (tam byłoby ciche i bez efektu). Zero wpływu na działanie: nic w kodzie nie woła API Kubernetesa. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
83 lines
3.7 KiB
YAML
83 lines
3.7 KiB
YAML
apiVersion: apps/v1
|
|
kind: Deployment
|
|
metadata:
|
|
name: logic
|
|
namespace: astrololo
|
|
spec:
|
|
replicas: 1
|
|
selector: { matchLabels: { app: logic } }
|
|
template:
|
|
metadata: { labels: { app: logic } }
|
|
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.
|
|
automountServiceAccountToken: false
|
|
imagePullSecrets: [{ name: gitea-registry }]
|
|
containers:
|
|
- name: logic
|
|
image: gitea.czernobog.pl/gitea/astrololo-logic:9323803c
|
|
ports: [{ containerPort: 8001 }]
|
|
env:
|
|
- name: DATA_URL
|
|
value: "http://data:8002" # discovery po nazwie Service
|
|
- name: EPHEMERIS_ENGINE
|
|
value: "own" # silnik własny; swisseph pominięty
|
|
# ENGINE_SWISSEPH_URL celowo NIE ustawiamy — engine-swisseph nie jest wdrażany
|
|
# Token międzywarstwowy (LOG-32): logika oddaje treść baz, więc musi
|
|
# odrzucać żądania z pominięciem logowania w prezentacji. Ten sam token
|
|
# służy jej do uwierzytelnienia się w warstwie danych.
|
|
- 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_PRESENTATION_LOGIC
|
|
valueFrom:
|
|
secretKeyRef: { name: astrololo-link, key: LINK_KEY_PRESENTATION_LOGIC }
|
|
- 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"
|
|
|
|
# --- Model językowy (LOG-31) ---
|
|
# Domyślnie LOKALNY: prompt niesie oryginalne opisy z baz, więc nic nie
|
|
# opuszcza sieci. Dostawcę można przełączyć w UI przy pojedynczym żądaniu.
|
|
- name: LLM_PROVIDER
|
|
value: "local"
|
|
- name: LOCAL_BASE_URL
|
|
value: "http://ollama.ollama.svc.cluster.local:11434/v1"
|
|
- name: LOCAL_MODEL
|
|
value: "llama3.1:8b"
|
|
- name: LLM_TIMEOUT
|
|
value: "180" # dłuższe horoskopy potrafią trwać
|
|
- name: LLM_MAX_TOKENS
|
|
value: "2000"
|
|
|
|
# Klucze do chmury — OPCJONALNE (optional: true), bo to funkcja, nie
|
|
# zabezpieczenie: bez sekretu pody startują normalnie i działa model
|
|
# lokalny. Wybór chmury w UI oznacza, że treść baz OPUSZCZA naszą sieć.
|
|
- name: OPENAI_API_KEY
|
|
valueFrom:
|
|
secretKeyRef: { name: astrololo-llm, key: OPENAI_API_KEY, optional: true }
|
|
- name: ANTHROPIC_API_KEY
|
|
valueFrom:
|
|
secretKeyRef: { name: astrololo-llm, key: ANTHROPIC_API_KEY, optional: true }
|
|
resources:
|
|
requests: { cpu: "100m", memory: "128Mi" }
|
|
limits: { cpu: "500m", memory: "512Mi" }
|
|
---
|
|
apiVersion: v1
|
|
kind: Service
|
|
metadata:
|
|
name: logic
|
|
namespace: astrololo
|
|
spec:
|
|
selector: { app: logic }
|
|
ports: [{ port: 8001, targetPort: 8001 }]
|