Kubernetes (Helm)
Produktionsreifes Deployment von Palveron auf Kubernetes mit Helm.
Das Palveron-Chart (oci://ghcr.io/palveron/charts/palveron) deployt das
Rust-Gateway und das Next.js-Dashboard sowie einen optionalen In-Cluster-
Redis-Cache. Es liefert bewusst kein PostgreSQL mit — bringen Sie eine
verwaltete Datenbank mit (Supabase empfohlen); das Gateway wendet seine
Schema-Migrationen beim Boot selbst an, es gibt also kein Init-SQL und
keinen Migrations-Job.
1. Secret anlegen
Das Chart rendert niemals Secret-Werte. Legen Sie ein Kubernetes-Secret an und referenzieren Sie es — diese Keys sind Pflicht (ohne die drei Verschlüsselungs-Keys verweigert das Gateway in Produktion den Start, das ist Absicht):
kubectl create namespace palveron
kubectl create secret generic palveron-secrets -n palveron \
--from-literal=DATABASE_URL='postgresql://<user>:<password>@<host>:5432/<db>' \
--from-literal=PLATFORM_DATABASE_URL='postgresql://<separate-pooler-verbindung>' \
--from-literal=TRACE_ENCRYPTION_ROOT_KEY="$(openssl rand -base64 32)" \
--from-literal=FLARE_ENCRYPTION_KEY="$(openssl rand -base64 32)" \
--from-literal=DLQ_ENCRYPTION_KEY="$(openssl rand -base64 32)" \
--from-literal=PALVERON_ENCRYPTION_KEY="$(openssl rand -base64 32)" \
--from-literal=INTERNAL_PROXY_SECRET="$(openssl rand -hex 32)" \
--from-literal=KINDE_CLIENT_SECRET='<ihr-kinde-client-secret>'Optionale Keys (Feature bleibt ohne sie aus): OPENAI_API_KEY,
FLARE_PRIVATE_KEY, STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET,
RESEND_API_KEY, OPERATOR_API_KEY, REDIS_URL (nur externes Redis).
Sichern Sie die drei Verschlüsselungs-Keys sofort nach dem Generieren — und
legen Sie echte Secrets nie in Git oder die Shell-History (das
openssl rand-Muster oben vermeidet beides). Ein verlorener
TRACE_ENCRYPTION_ROOT_KEY macht verschlüsselte Trace-Inhalte dauerhaft
unlesbar — das ist beabsichtigtes Crypto-Shredding, kein behebbarer Fehler.
2. Installation
Das Chart wird als OCI-Artefakt auf GHCR veröffentlicht. Melden Sie sich
zuerst an (GitHub-Token mit read:packages):
helm registry login ghcr.io -u <github-user>helm install palveron oci://ghcr.io/palveron/charts/palveron --version 1.0.0 \
--namespace palveron --create-namespace \
-f my-values.yaml3. my-values.yaml
secrets:
existingSecret: palveron-secrets
gateway:
publicUrl: https://gateway.example.com # Pflicht
replicas: 2 # zustandslos — horizontal skalierbar
platform:
publicUrl: https://app.example.com # Pflicht — Kinde-Redirects leiten sich daraus ab
kinde:
issuerUrl: https://yourorg.kinde.com # Pflicht — Ihr eigener Kinde-Tenant
clientId: <kinde-client-id> # Pflicht (das SECRET liegt im Secret)
ingress:
enabled: true
className: nginx
tls:
- secretName: palveron-tls
hosts: [app.example.com, gateway.example.com]Die wichtigsten Overrides (der vollständige, kommentierte Kontrakt steht in
der values.yaml des Charts):
| Value | Default | Hinweis |
|---|---|---|
gateway.image.tag / platform.image.tag | Chart-appVersion | Immer gepinnt — latest lehnt das values-Schema ab |
gateway.dlq.persistence.enabled | true | PVC für das verschlüsselte Trace-WAL (/data/dlq) — in Produktion anlassen |
gateway.nge.enabled | false | Lokale ONNX-Analyse; braucht ein PVC mit den Modellen (gateway.nge.existingClaim) und ~4–5 GB RAM |
redis.enabled | true | Optionaler In-Cluster-Cache; das Gateway läuft ohne Redis kontrolliert weiter |
gateway.mcpAllowPrivateUpstream | false | Sicherheit: true deaktiviert den SSRF-Schutz für MCP-Upstreams — nur für vollständig abgeschottete Netze, deren MCP-Upstreams legitim auf privaten IPs liegen |
gateway.env.rustEnv | production | Hält die Verschlüsselungs-Boot-Gates scharf — für echte Deployments nicht absenken |
Fehlende Pflicht-Values lassen das Rendering mit einer sprechenden Meldung
fehlschlagen — bricht helm install mit secrets.existingSecret is required… ab, schützt das Chart Sie vor einem Boot-Loop; das ist kein Bug.
Prüfen
kubectl -n palveron get pods
kubectl -n palveron logs deploy/palveron-gateway | grep -i migrat # Boot-Migrationen
helm test palveron -n palveron # In-Cluster-Smoke-TestDie Probes sind vorverdrahtet: Readiness des Gateways ist GET /ready
(Postgres erreichbar — die einzige harte Abhängigkeit), Liveness ist
GET /health; das Dashboard nutzt GET /api/health.
Upgrades
helm upgrade palveron oci://ghcr.io/palveron/charts/palveron --version <neu> \
-n palveron -f my-values.yamlDie Deployments nutzen Rolling Updates; das Gateway ist zustandslos (DLQ-PVC
und Ihre Datenbank tragen den Zustand) — Upgrades unterbrechen den Verkehr
mit replicas: 2+ nicht.
Bekannte Grenze — öffentliche Dashboard-URLs. Das Platform-Image backt
NEXT_PUBLIC_*-Werte zur Build-Zeit ein. Self-Hosting unter eigener Domain
erfordert einen Rebuild des Platform-Images mit Ihrer
NEXT_PUBLIC_PALVERON_CORE_URL (siehe Dockerfile.platform-Build-Args im
Platform-Repo). Server-seitige Aufrufe nutzen bereits In-Cluster-Service-DNS
und brauchen keinen Rebuild.
Für Einzelserver-Setups ohne Kubernetes siehe die Docker-Compose-Anleitung.