Auf dieser Seite wird beschrieben, wie Sie die Größe von Knoten in Standardknotenpools von Google Kubernetes Engine (GKE) planen, um das Risiko von Arbeitslastunterbrechungen und Beendigungen aufgrund fehlender Ressourcen zu reduzieren.
Diese Planung ist in GKE Autopilot nicht erforderlich, da Google Cloud die Knoten für Sie verwaltet. Dieses Dokument hilft jedoch Autopilot-Clusterbetreibern, die wissen möchten, welcher Anteil der Ressourcenkapazität eines Knotens für ihre Arbeitslasten verfügbar ist.
Vorteile richtig dimensionierter Knoten
Wenn Sie dafür sorgen, dass die Knoten richtig dimensioniert sind, um die Arbeitslasten zu bewältigen und um Aktivitätsspitzen zu bewältigen, profitieren Sie von folgenden Vorteilen:
- Bessere Arbeitslastzuverlässigkeit aufgrund eines geringeren Risikos einer Löschung wegen mangelnder Ressourcen.
- Verbesserte Skalierbarkeit zum Skalieren von Arbeitslasten in Zeiten mit hohem Traffic.
- Geringere Kosten, da die Knoten für Ihre Anforderungen nicht zu groß sind, was andernfalls zur Verschwendung von Ressourcen führen kann.
Für Knoten zuweisbare Ressourcen
GKE-Knoten führen Systemkomponenten aus, mit denen der Knoten als Teil des Clusters fungieren kann. Diese Komponenten verwenden Knotenressourcen wie CPU und Arbeitsspeicher. Sie bemerken möglicherweise einen Unterschied zwischen den Gesamtressourcen Ihres Knotens, die auf der Größe der zugrunde liegenden Compute Engine-VM basieren, und der Ressourcen, die für Ihre GKE-Arbeitslasten zum Anfragen verfügbar sind. Dieser Unterschied besteht, da GKE eine vordefinierte Menge an Ressourcen für Systemfunktionalität und Knotenzuverlässigkeit reserviert. Der Speicherplatz, den GKE für Systemressourcen reserviert, unterscheidet sich je nach Knoten-Image. Die verbleibenden Ressourcen, die für Ihre Arbeitslasten verfügbar sind, werden als zuweisbare Ressourcen bezeichnet.
Wenn Sie Pods in einem Manifest definieren, können Sie in der Pod-Spezifikation Ressourcenanforderungen und Limits angeben. Wenn GKE die Pods auf einem Knoten platziert, fordert der Pod die angegebenen Ressourcen von den zuweisbaren Ressourcen auf dem Knoten an. Bei der Planung der Knotengröße in Ihren Knotenpools sollten Sie berücksichtigen, wie viele Ressourcen Ihre Arbeitslasten benötigen, um ordnungsgemäß zu funktionieren.
Zuweisbare Ressourcen auf einem Knoten prüfen
Führen Sie folgenden Befehl aus, um die zuweisbaren Ressourcen auf einem vorhandenen Knoten zu prüfen:
kubectl get node NODE_NAME \
-o=yaml | grep -A 7 -B 7 capacity
Ersetzen Sie NODE_NAME durch den Namen des Knotens.
Die Ausgabe sieht in etwa so aus:
allocatable:
attachable-volumes-gce-pd: "127"
cpu: 3920m
ephemeral-storage: "47060071478"
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 13498416Ki
pods: "110"
capacity:
attachable-volumes-gce-pd: "127"
cpu: "4"
ephemeral-storage: 98831908Ki
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 16393264Ki
pods: "110"
In dieser Ausgabe sind die Werte im Abschnitt allocatable die zuweisbaren Ressourcen auf dem Knoten. Die Werte im Abschnitt capacity sind die Gesamtressourcen auf dem Knoten. Die Einheiten des sitzungsspezifischen Speichers sind Byte.
GKE-Ressourcenreservierungen
GKE reserviert bestimmte Mengen an Arbeitsspeicher und CPU-Ressourcen auf Knoten basierend auf der Gesamtgröße der auf dem Knoten verfügbaren Ressource. Auf größeren Maschinentypen werden mehr Container und Pods ausgeführt. Daher wird die von GKE reservierte Ressourcenmenge bei größeren Maschinen hochskaliert. Windows Server-Knoten benötigen außerdem mehr Ressourcen als entsprechende Linux-Knoten, um das Windows-Betriebssystem auszuführen und die Windows Server-Komponenten zu berücksichtigen, die nicht in Containern ausgeführt werden können.
Arbeits-Speicher- und CPU-Reservierungen
In den folgenden Abschnitten werden die standardmäßigen Arbeitsspeicher- und CPU-Reservierungen basierend auf dem Maschinentyp beschrieben.
Arbeitsspeicherreservierungen
Für Arbeitsspeicherressourcen reserviert GKE Folgendes:
- 255 MiB Arbeitsspeicher für Geräte mit weniger als 1 GiB Arbeitsspeicher
- 25% der ersten 4 GiB Arbeitsspeicher
- 20% der nächsten 4 GiB Arbeitsspeicher (bis zu 8 GiB)
- 10% der nächsten 8 GiB Arbeitsspeicher (bis zu 16 GiB)
- 6% der nächsten 112 GiB Arbeitsspeicher (bis zu 128 GiB)
- 2% sämtlichen Speichers oberhalb von 128 GiB
GKE reserviert zusätzlich 100 MiB Arbeitsspeicher auf jedem Knoten, um die Pod-Bereinigung auszuführen.
CPU-Reservierungen
Für CPU-Ressourcen reserviert GKE Folgendes:
- 6 % des ersten Kerns
- 1 % des nächsten Kerns (bis zu zwei Kerne)
- 0,5 % der nächsten zwei Kerne (bis zu vier Kerne)
- 0,25 % aller Kerne oberhalb von vier Kernen
Für E2-Maschinentypen mit gemeinsam genutztem Kern reserviert GKE insgesamt 1.060 Millicore.
Lokale sitzungsspezifische Speicherreservierung
GKE stellt Knoten mit lokalem sitzungsspezifischen Speicher bereit, der von lokal angehängten Geräten wie dem Bootlaufwerk des Knotens oder lokalen SSDs unterstützt wird. Der sitzungsspezifische Speicher bietet keine Garantie für die Verfügbarkeit. Daten im sitzungsspezifische Speicher können verloren gehen, wenn ein Knoten ausfällt und gelöscht wird.
GKE reserviert einen Teil des gesamten sitzungsspezifischen Speichers des Knotens als einzelnes Dateisystem für das Kubelet, das während der Pod-Entfernung verwendet wird, und für andere Systemkomponenten, die auf dem Knoten ausgeführt werden. Sie können den verbleibenden sitzungsspezifischen Speicher Ihren Pods für Zwecke wie Logs zuweisen. Informationen zum Angeben bzw. Festlegen von Anfragen und Limits für sitzungsspezifischen Speicher in Ihren Pods finden Sie unter Lokaler sitzungsspezifischer Speicher.
GKE berechnet die lokale sitzungsspezifische Speicherreservierung so:
EVICTION_THRESHOLD + SYSTEM_RESERVATION
Die tatsächlichen Werte variieren je nach Größe und Typ des Geräts, das den Speicher bietet.
Von Knoten-Bootlaufwerk unterstützter sitzungsspezifischer Speicher
Standardmäßig wird sitzungsspezifischer Speicher vom Bootlaufwerk des Knotens unterstützt. In diesem Fall ermittelt GKE den Wert des Schwellenwerts für die Bereinigung so:
EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY
Der Schwellenwert für die Bereinigung beträgt immer 10 % der gesamten Bootlaufwerkkapazität.
GKE ermittelt den Wert der Systemreservierung so:
SYSTEM_RESERVATION = Min(50% * BOOT_DISK_CAPACITY, 6GiB + 35% * BOOT_DISK_CAPACITY, 100 GiB)
Der Betrag für die Systemreservierung ist der niedrigste der folgenden Werte:
- 50 % der Bootlaufwerkkapazität
- 35 % der Bootlaufwerkkapazität + 6 GiB
- 100 GiB
Wenn das Bootlaufwerk beispielsweise 300 GiB hat, gelten die folgenden Werte:
- 50 % der Kapazität: 150 GiB
- 35 % der Kapazität + 6 GiB: 111 GiB
- 100 GiB
GKE würde Folgendes reservieren:
- Systemreservierung: 100 GiB (niedrigster Wert)
- Schwellenwert für die Bereinigung: 30 GiB
Der gesamte reservierte sitzungsspezifische Speicher beträgt 130 GiB. Die verbleibende Kapazität, 170 GiB, ist zuweisbarer Speicher.
Von lokalen SSDs unterstützter sitzungsspezifischer Speicher
Wenn Ihr sitzungsspezifischer Speicher von lokalen SSDs unterstützt wird, berechnet GKE den Schwellenwert für die Bereinigung so:
EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GiB
Bei dieser Berechnung ist SSD_NUMBER die Anzahl der angehängten lokalen SSDs. Alle lokalen SSDs sind 375 GiB groß, sodass der Bereinigungsschwellenwert 10 % der gesamten sitzungsspezifischen Speicherkapazität beträgt. Dieser Wert wird vor der Formatierung der Laufwerke berechnet, sodass die nutzbare Kapazität je nach Knoten-Image-Versionen um mehrere Prozent geringer ist.
GKE berechnet die Systemreservierung abhängig von der Anzahl der angehängten SSDs so:
| Anzahl der lokalen SSDs | Systemreservierung (GiB) |
|---|---|
| 1 | 50 GiB |
| 2 | 75 GiB |
| Mindestens drei | 100 GiB |
Ressourcenreservierungen zum Planen der Knotengrößen verwenden
Berücksichtigen Sie die Ressourcenanforderungen Ihrer Arbeitslasten bei der Bereitstellung und unter Last. Dazu gehören die Anfragen und geplanten Limits für die Arbeitslasten sowie der Aufwand für die Hochskalierung.
Überlegen Sie sich, ob Sie eine kleine Anzahl großer Knoten oder eine große Anzahl kleiner Knoten zum Ausführen Ihrer Arbeitslasten benötigen.
- Eine kleine Anzahl großer Knoten eignet sich gut für ressourcenintensive Arbeitslasten, die keine Hochverfügbarkeit erfordern. Das Autoscaling von Knoten ist weniger agil, da mehr Pods entfernt werden müssen, damit eine Herunterskalierung möglich ist.
- Eine große Anzahl kleiner Knoten eignet sich gut für hochverfügbare Arbeitslasten, die nicht ressourcenintensiv sind. Das Autoscaling von Knoten ist agiler, da weniger Pods entfernt werden müssen, damit eine Herunterskalierung möglich ist.
Verwenden Sie den Vergleichsleitfaden für Compute Engine-Maschinenfamilien, um die gewünschte Maschinenserie und -familie für Ihre Knoten zu ermitteln.
Berücksichtigen Sie die Anforderungen an sitzungsspezifischen Speicher Ihrer Arbeitslasten. Ist das Bootlaufwerk des Knotens ausreichend? Benötigen Sie lokale SSDs?
Berechnen Sie die zuweisbaren Ressourcen für den ausgewählten Maschinentyp anhand der Informationen in den vorherigen Abschnitten. Vergleichen Sie dies mit den benötigten Ressourcen und dem Aufwand.
- Wenn der ausgewählte Maschinentyp zu groß ist, sollten Sie eine kleinere Maschine in Betracht ziehen, um nicht für die zusätzlichen Ressourcen bezahlen zu müssen.
- Wenn der ausgewählte Maschinentyp zu klein ist, sollten Sie eine größere Maschine in Betracht ziehen, um das Risiko von Unterbrechungen der Arbeitslast zu verringern.