Skip to content
🟡In Arbeit58%
Vollständigkeit:
70%
Korrektheit:
75%
⏳ Noch nicht geprüft

VM-Sizing und Host-Ressourcen für CIVITAS/CORE

Zielplattform

CIVITAS/CORE wird auf einem dedizierten lokalen Proxmox-Knoten ("civitas") betrieben. Der Knoten steht exklusiv für diesen Zweck zur Verfügung und ist nicht öffentlich erreichbar.

Verfügbare Hardware (Proxmox-Knoten "civitas")

KomponenteWert
CPUAMD Ryzen 7 H 255, 8 Kerne / 16 Threads
RAM physisch64 GiB
RAM verfügbar~56 GiB (Proxmox-Host belegt ~3,7 GiB)
Storage raw2 × 476 GiB NVMe
ZFS-Pool rpool~455 GiB verfügbar
Swapkeiner konfiguriert

Systemanforderungen CIVITAS/CORE

V2 (aktuell)

Quelle: https://docs.core.civitasconnect.digital/docs_v2/next/Deployment/prerequisites/

AnforderungMinimumEmpfohlen
Kubernetes≥ 1.32, x86_64
vCPU48+
RAM16 GiB32+ GiB
Storage ClassRWO (ReadWriteOnce)
Ingress Controllernginx oder traefik
cert-managermit Cluster Issuer
DNSidm.<domain>, portal.<domain>
SMTPzwingend für Keycloak

V1.5 (Sizing-Referenz für Einzel-Node-Betrieb)

Quelle: https://docs.core.civitasconnect.digital/docs/1.5.0/Deployment/Deployment-Requirements/

SzenariovCPURAMStorage
Sandbox (1 Node)8–1032 GiB600 GiB SSD
Minimum (3 Nodes)8–10 je Node32 GiB je Node300 GiB je Node
Standard (3 Nodes)12 je Node64 GiB je Node300 GiB je Node

Für den vorliegenden Einzel-Node-Betrieb gilt das Sandbox-Szenario als maßgebliche Referenz.

Ressourcenzuordnung nach Komponente

Die folgenden Angaben orientieren sich an den tatsächlichen Laufzeitanforderungen der CIVITAS/CORE-Komponenten laut Deployment-Doku:

KomponenteRessourcenbedarfBegründung
Keycloak (idm)2–4 GiB RAM, 1–2 vCPUIdentity-Management, SMTP-Anbindung, Startup-intensiv
CIVITAS Portal2–4 GiB RAM, 1–2 vCPUFrontend-Serving, Ingress-Endpunkt
Kubernetes Control Plane (k3s/k0s)1–2 GiB RAM, 1 vCPUOverhead für Single-Node-Cluster
Datenbank-Backend (PostgreSQL o.ä.)4–8 GiB RAM, 2 vCPUPersistenz, je nach Datenlast
Weiterer Plattform-Overhead4–8 GiB RAM, 2 vCPUOperator, Cert-Manager, Ingress, Monitoring
Reserve / Burst4 GiB RAM, 2 vCPUPeaks, Updates, Neustarts
Summe VM~20–30 GiB RAM, 10–12 vCPUArbeitswert für initiales Sizing

Abgleich: Anforderungen vs. verfügbare Ressourcen

RessourceCIVITAS/CORE Sandbox-MinimumVerfügbar auf civitasVerfügbar für VMBewertung
vCPU8–1016 Threads12 (4 Reserve Host)ausreichend
RAM32 GiB56 GiB verfügbar40 GiB (16 GiB Reserve)ausreichend
Storage600 GiB455 GiB frei in rpool300 GiB ZFS-Volumeknapp – Begründung unten
Swapempfohlennicht konfiguriertRisiko

Empfohlenes VM-Sizing (erste Ausbaustufe)

ParameterWertBegründung
vCPU1275 % der verfügbaren Threads; 4 verbleiben für Proxmox-Host
RAM40 GiBentspricht ~70 % des verfügbaren RAM; 16 GiB Reserve für Host
Disk300 GiB (ZFS thin-provisioned)deckt Sandbox-Anforderungen; rpool-Reserve bleibt erhalten
Gastbetriebssystemoffen (→ Folgespezifikation Kubernetes-Laufzeit)Debian 12 oder Ubuntu 24.04 empfohlen
Netzwerkinternes VLAN im SOHO-Clusterkein öffentlicher Zugang

Risiken und Einschränkungen

  • Kein Swap: Kubernetes empfiehlt zwar deaktivierten Swap, der Proxmox-Host selbst hat keinen Swap konfiguriert. Bei RAM-Druck des Hosts gibt es keinen Puffer — Risiko bei parallelen VMs.
  • Storage knapp: 300 GiB decken das Sandbox-Minimum, liegen aber unter der Empfehlung von 600 GiB. Persistente Volumes, Snapshots und Log-Wachstum können schnell zu Engpässen führen.
  • ZFS-Mirror (rpool): Beide NVMe-Platten sind als ZFS-Mirror konfiguriert. Einzelplatten-Ausfall ist tolerierbar.
  • Single-Node, kein HA: Jeder Ausfall des Knotens ist gleichzeitig Ausfall der gesamten Plattform. Kein automatisches Failover möglich. Knoten ist in Backup über Proxmox eingebunden und wird täglich gesichert

Offene Punkte (→ Folgespezifikationen)

  • Gastbetriebssystem und Kubernetes-Distribution (→ kubernetes-laufzeit.md)
  • DNS-Setup für idm.<domain> und portal.<domain> (→ netzwerk-dns-tls.md)
  • Backup-Strategie für VM und persistente Volumes (→ persistenz-storage-backup.md)
  • Swap-Entscheidung auf Proxmox-Host-Ebene