Plan auswählen
Beim Anlegen eines Node Pools wählen Sie einen Instance-Typ aus der Reihe C0 bis C8. Der Instance-Typ bestimmt vCPU, Arbeitsspeicher und NVMe-Speicher pro Node – und damit sowohl die Leistung als auch die Kosten Ihres Clusters.
Ein zu groß dimensionierter Pool lässt Ressourcen ungenutzt und verursacht unnötige Kosten. Ein zu klein dimensionierter Pool führt bei voller CPU- oder Speicherauslastung zu verschlechterter Leistung, nicht schedulebaren Pods oder Fehlern.
Verfügbare Instance-Typen
Eine vollständige Übersicht mit Preisen finden Sie unter Pricing & Limits.
| Typ | vCPU | RAM | NVMe |
|---|---|---|---|
| C0 | 1 | 1 GB | 25 GB |
| C1 | 1 | 2 GB | 50 GB |
| C2 | 2 | 2 GB | 60 GB |
| C3 | 2 | 4 GB | 80 GB |
| C4 | 2 | 8 GB | 100 GB |
| C5 | 4 | 8 GB | 160 GB |
| C6 | 4 | 16 GB | 200 GB |
| C7 | 8 | 16 GB | 320 GB |
| C8 | 8 | 32 GB | 400 GB |
Node-Größe und Node-Anzahl
Zwei Stellschrauben bestimmen die Kapazität Ihres Clusters:
- Node-Größe (Instance-Typ): Bestimmt, wie viel Arbeitsspeicher einem einzelnen Pod maximal zugewiesen werden kann. Ein Pod kann niemals größer sein als der Node, auf dem er läuft. Planen Sie ein, dass ein Teil der Node-Ressourcen für Systemkomponenten wie kubelet und die Container-Runtime reserviert ist.
- Node-Anzahl: Bestimmt CPU, RAM und Speicher des Clusters insgesamt. Mehr Nodes bedeuten mehr Spielraum bei der Lastverteilung und mehr Ausfallsicherheit.
Für Produktionscluster werden mindestens 2 Nodes je Node Pool empfohlen. So bleibt Ihre Anwendung während Upgrades und Wartungsarbeiten erreichbar, wenn Nodes nacheinander neu gestartet werden.
Breit oder hoch skalieren
Bei gleicher Gesamtkapazität haben Sie meist die Wahl zwischen vielen kleinen und wenigen großen Nodes:
- Viele kleine Nodes verteilen die Last feiner, verkraften den Ausfall eines einzelnen Nodes besser und eignen sich für viele kleine, zustandslose Pods. Der Overhead für Systemkomponenten fällt jedoch je Node erneut an.
- Wenige große Nodes sind sinnvoll, wenn einzelne Pods viel Arbeitsspeicher benötigen oder Workloads von lokaler Nähe zueinander profitieren. Der Ausfall eines Nodes trifft hier aber einen größeren Anteil des Clusters.
Mehrere Node Pools nutzen
Ein Cluster kann mehrere Node Pools mit unterschiedlichen Instance-Typen enthalten. Das ist sinnvoll, wenn sich Ihre Workloads deutlich unterscheiden – etwa ein Pool mit kleinen Nodes für zustandslose Web-Dienste und ein Pool mit großen Nodes für speicherintensive Verarbeitungsjobs.
Siehe Node Pools hinzufügen.
Datenbasiert entscheiden
- Benchmarking und Lasttests: Testen Sie Ihre Arbeitslast nach der Cluster-Erstellung unter simulierter Last, statt die Dimensionierung nur zu schätzen.
- Ressourcennutzung analysieren: Beobachten Sie CPU- und Speicherauslastung im Tab Analytics und passen Sie die Node-Größe an die tatsächlichen Anforderungen an.
- CPU-Spitzen einplanen: Die CPU-Auslastung eines Kubernetes-Clusters schwankt typischerweise stark, während der Arbeitsspeicherbedarf konstanter bleibt. Dimensionieren Sie die CPU so, dass sie Lastspitzen abfängt.
Was sich nachträglich ändern lässt
| Eigenschaft | Nachträglich änderbar |
|---|---|
| Anzahl der Nodes im Pool | Ja |
| Autoscaling je Node Pool | Ja |
| Zusätzliche Node Pools | Ja |
| Instance-Typ eines bestehenden Pools | Über einen neuen Pool und Migration der Workloads |
| Pod- und Service-Netzwerke | Nein – nur bei der Cluster-Erstellung |
| High Availability Control Plane | Nachträglich aktivierbar, aber nicht mehr entfernbar |
Da Sie die Node-Anzahl jederzeit anpassen und weitere Pools ergänzen können, ist es sinnvoll, eher klein zu starten und anhand echter Messwerte zu wachsen. Die Netzwerkdimensionierung sollten Sie dagegen von Anfang an großzügig planen.