Dimensionierung

Die Zahlen auf dieser Seite sind die Standardwerte in der values.yaml des Charts. Sie sind Ausgangspunkte für deine eigenen Messungen, keine für eine Zahl von Personen gemessenen Werte: Wie viel eine Installation braucht, hängt davon ab, wie viele Personen sie gleichzeitig nutzen, wie viele Tool-Server sie betreiben und was sie tun. Beobachte, was die Pods unter Verwaltung → Plattform oder in deinem Monitoring brauchen, und pass an.

Die Komponenten der Plattform

Komponente	Replikas	Autoscaling (CPU 70 %)	Requests	Limits
Control API	2	2 bis 6	100m CPU, 256Mi	1 CPU, 512Mi
MCP-Gateway	2	2 bis 10	100m CPU, 256Mi	1 CPU, 512Mi
Egress-Gateway	2	2 bis 10	100m CPU, 128Mi	1 CPU, 512Mi
Controller	2 (einer führt)	–	50m CPU, 128Mi	500m CPU, 256Mi
Konsole	2	–	50m CPU, 128Mi	500m CPU, 256Mi
Classifier (aus)	1	–	2 CPU, 6Gi	4 CPU, 8Gi

Mit eingeschaltetem Autoscaling setzt der Autoscaler die Zahl der Replikas, und replicas wird nicht verwendet; er braucht einen Metrics Server.

Dienste daneben

Dienst	Replikas	Requests	Limits	Weitere Standardwerte
Postgres (CloudNativePG)	2 Instanzen	die des Operators	die des Operators	postgres.storage: 10Gi je Instanz
Garage	1 Knoten	50m CPU, 128Mi	1 CPU, 1Gi	Volumes meta 1Gi, data 20Gi
SearXNG	1	50m CPU, 256Mi	1 CPU, 512Mi
Docling	1	1 CPU, 2Gi	4 CPU, 8Gi	2 Worker mit je 4 Threads; Arbeitsplatz 2Gi
Gotenberg (aus)	1	100m CPU, 256Mi	2 CPU, 2Gi	Warteschlange 8; Arbeitsplatz 1Gi
Presidio (aus)	1	100m CPU, 768Mi	1 CPU, 1536Mi	startet in bis zu 6 Minuten

Das README des Charts vermerkt für Docling, dass OCR mit EasyOCR auf gescannten Seiten bis zu 6 GiB brauchte; jeder weitere geladen gehaltene Satz von Optionen (optionsCacheSize) braucht etwa 1 bis 2 GiB mehr.

Was der Controller startet

Diese laufen außerhalb des Plattform-Namespaces und sind durch Anzahlen und Quotas begrenzt, nicht durch Replikas:

Was	Gleichzeitig	Je Requests	Je höchstens
Build-Jobs (builds)	2 je Person, 8 insgesamt	500m CPU, 1Gi	2 CPU, 4Gi; 15 Minuten
Prüfschritte eines Builds (checks.resources)	einer je Build	100m CPU, 128Mi	1 CPU, 1Gi; 3 Minuten je Werkzeug
Code-Sandboxes (sandboxes, aus)	2 je Person, 20 insgesamt, 2 warm gehalten	100m CPU, 256Mi	1 CPU, 2Gi; Platte 2Gi; ein Lauf 120 s
Code-Umgebungen (devenvs, aus)	2 je Person, 10 insgesamt	250m CPU, 512Mi, 1Gi Platte	2 CPU, 4Gi, 12Gi Platte

Die Tool-Server der Personen laufen in einem Namespace je Person, mit instances.quota: 4 CPU, 8Gi Speicher, 20 Pods, 5 Volumes. Der Namespace einer Organisation hält jede Kopie, die ihre Personen teilen, eine je Version und Satz von Anmeldungen, und nutzt instances.orgQuota, standardmäßig dieselbe wie die einer Person. Das README des Charts empfiehlt, Organisationen mehr zu geben, zum Beispiel:

instances:
  orgQuota: { cpu: "16", memory: 32Gi, pods: "100" }

Eine Instanz ohne Aufrufe schläft nach 15 Minuten ein (Einstellung instances.idleTimeout) und gibt frei, was sie belegt hat, bis zum nächsten Aufruf.

Was womit wächst

Wächst mit	Wo	Worauf achten
Personen, die gleichzeitig arbeiten	Control API, MCP-Gateway	CPU dieser Pods; die Höchstwerte der Autoscaler.
Tool-Aufrufen nach außen	Egress-Gateway	CPU, und Speicher für API-Regeln: egress.apiBodyBudget (64 MiB) begrenzt die Request-Bodies, die eine Replika gleichzeitig zur Prüfung hält.
Personen und Organisationen mit eigenen Tool-Servern	Ihre Namespaces	Platz auf den Knoten für instances.quota je Namespace; die Quota der Organisation.
Dem Bauen von Tool-Servern	Build-Namespace	Höchstens 8 Build-Jobs, jeder bis zu 2 CPU und 4Gi.
Chats, Erinnerungen, Wiki-Seiten, Sitzungen, dem Audit-Log	Postgres	postgres.storage. Auch die Vektoren für die Suche im Gedächtnis liegen in Postgres (pgvector).
Code-Bundles der Tool-Server	Postgres	Jedes bis zu bundles.maxSize (256Mi), jede Version wird behalten.
Dateien	Garage oder S3	data standardmäßig 20Gi. Dateien gehen nach 7 Tagen, wenn niemand sie behält, eine Person darf bis zu 5 GB behalten (Einstellungen); Objekte, die keine Datei mehr nennt, bleiben storage.graceDays (90 Tage).
Gelesenen Dokumenten	Docling	Speicher je Worker, mehr mit OCR; workers.

Hochverfügbar machen

• Postgres: postgres.instances: 2 ergibt einen Primary und eine Replika. CloudNativePG schaltet zwischen ihnen um.
• Garage: Ein Knoten hält jedes Objekt einmal. storage.garage.ha.enabled: true betreibt mindestens drei Knoten, jedes Objekt auf dreien davon, nie zwei auf einem Kubernetes-Knoten. Ein Garage mit einem Knoten wird nicht einfach später zu mehreren: Starte ein HA-Garage und kopiere den Bucket hinüber.
• Die Komponenten laufen standardmäßig mit je zwei Replikas.