Anleitungen

Skalierung und RAM

Legen Sie den RAM eines Projekts in Schritten von 256 MB fest, sehen Sie, welcher Schritt Ihre Rechnung ändert, und skalieren Sie die zustandslosen Schichten horizontal.

RAM ist der eine Regler. Sie legen den RAM eines Projekts in Schritten von 256 MB fest, die CPU-Grenze folgt daraus. Eine eigene CPU-Einstellung gibt es nicht.

RAM skalieren

Ihr Agent liest und setzt den Wert über MCP:

Zustand lesen. nyx_project_state <project> liefert allocatedMb, reservedMb, floorMb und remainingPoolMb: was zugeteilt ist, was laufende Pods belegen und was im Kontingent des Kontos frei ist.
Aus dem Repo dimensionieren, nicht schätzen. Framework, Sidecars und ML-Bibliotheken zeigen, was die Last braucht.
Wert setzen. nyx_project mit action: ram und mb: <needed> rundet auf den nächsten 256-MB-Schritt auf. Die CPU-Grenze steigt mit.

Die CPU-Grenze ergibt sich aus dem RAM als allocatedMb * 500 / 1024 Millicores, summiert über alle Pods des Projekts:

RAM	CPU-Grenze
256 MB	125m
512 MB	250m
1024 MB	500m

Hat das Kontingent des Kontos keinen Platz mehr, verkleinern Sie ein anderes Projekt, oder eine Person bucht RAM-Pakete in der Console. Rollen Sie nie einen Deploy halb aus, dem RAM fehlt.

Jedes Projekt und jede App zeigt Arbeitsspeicher und CPU live im Verhältnis zur Zuteilung. So dimensionieren Sie nach dem, was tatsächlich läuft:

Arbeitsspeicher · 24 h3,4 GB belegt · 4 GB zugeteilt

Tatsächlich belegter Arbeitsspeicher Dem Projekt zugeteilt

Was die Rechnung ändert

Drei Zahlen werden leicht verwechselt. Nur die erste kostet Geld über Ihren Tarif hinaus:

Beispiel: ein Starter-Konto mit 8 GB Grundkontingent und zwei gebuchten RAM-Paketen. Eine niedrigere Zuteilung schafft Platz im Kontingent, nur das Zurückgeben eines Pakets senkt die Rechnung.

Ihre Tarifgebühr deckt das Grundkontingent ab (8 GB bei Starter, 48 GB bei Business).
RAM-Pakete erweitern das Kontingent des Kontos um je 1 GB für 5 € pro Monat, tageweise abgerechnet, solange Sie sie halten (mindestens ein Tag). Eine Person bucht sie und gibt sie zurück, in der Console unter Settings › Subscription, innerhalb der Kostenobergrenze, die Sie dort festlegen. Ihr Agent kann das Kontingent lesen (nyx_project_list), aber keine Pakete buchen.
Zuteilungen pro Projekt und die Nutzung der Pods teilen das Kontingent nur auf. Senken Sie eine Zuteilung mit nyx_project (action: ram), wird im Kontingent Platz für andere Projekte frei. kubectl scale oder das Löschen einer App schafft Platz innerhalb des Projekts. Beides ändert die Rechnung nicht.

Um nach einer Lastspitze Geld zu sparen, senken Sie zuerst die Zuteilungen der Projekte mit nyx_project (action: ram) und geben dann die Pakete zurück, die Sie nicht mehr brauchen. Die Console lehnt die Rückgabe ab, solange Zuteilungen diese Kapazität noch benötigen.

Horizontal skalieren: mehr als ein Replikat

Vertikale Skalierung deckt die meisten Lasten ab. So betreiben Sie mehrere Replikate hinter einem Service:

Zustandslose Schichten skalieren frei. Kein lokaler Zustand zwischen Anfragen (kein SQLite auf der Platte, keine lokalen Uploads, keine Sessions im Prozess) und kein PVC oder nur ein emptyDir. Setzen Sie replicas so hoch, wie der RAM des Projekts es erlaubt.
Zustandsbehaftete Schichten bleiben bei einem Replikat oder werden zum StatefulSet. App-PVCs sind ReadWriteOnce und an einen Knoten gebunden. Ein zweites Replikat auf einem anderen Knoten kann das Volume deshalb nicht einhängen und bleibt in ContainerCreating hängen. Datenbanken, Caches und Queues laufen mit replicas: 1. Echte Hochverfügbarkeit ist ein StatefulSet mit einem PVC pro Pod plus Replikation auf App-Ebene. Der Zugriffsmodus wird beim Bereitstellen des Volumes festgelegt, eine Änderung am Deployment kann ihn nicht erweitern.

Faustregel: die zustandslose Schicht horizontal skalieren, die zustandsbehaftete vertikal. Gemeinsamer Speicher mit Lese- und Schreibzugriff über mehrere Replikate wird Apps derzeit nicht angeboten.

Pod dimensionieren

Dimensionieren Sie kleine Web-Pods mit etwa 50 bis 100m CPU. Übernehmen Sie kein pauschales "1" oder "200m" von anderswo. Jeder Container braucht requests und limits für CPU und Arbeitsspeicher:

Mit nyx_deploy_manifests ausgerollt, bekommt ein Container ohne diese Werte kleine Standardwerte (requests 50m / 64Mi, limits 100m / 128Mi), und das Tool weist darauf hin. Betrachten Sie das als Untergrenze und setzen Sie echte Werte.
Auf anderem Weg angewendet (zum Beispiel mit kubectl apply), lehnt das Kontingent des Projekts einen Container ohne Limits ab.
limits.cpu über der Grenze schlägt mit exceeded quota: limits.cpu (FailedCreate) fehl. Es wird kein Pod erstellt.

Hinweis: Wenn Sie den RAM eines Projekts unter das senken, was seine laufenden Pods reservieren, schlägt das mit 409 (below_reserved) fehl und liefert requestedMb, reservedMb und floorMb zurück. Löschen Sie zuerst eine App oder wählen Sie einen mb-Wert ab floorMb.

Grenzen außerhalb des Reglers

Die Zahl der Pods pro Projekt ist je nach Tarif begrenzt.
Speicher kommt aus einem eigenen Kontingent: dem Speicher Ihres Tarifs plus Speicherpaketen (je 100 GB), nicht aus dem RAM.
Services vom Typ LoadBalancer / NodePort sind immer 0. Der Ingress ist der einzige Weg von außen hinein.

Wie Workspaces, Projekte und das Kontingent zusammenhängen, lesen Sie unter Projekte und Konten.