GKE-Standardknotengrößen planen

Standard

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 der Mangelnder Ressourcen-Beendigung zu reduzieren. Diese Planung ist in GKE Autopilot nicht erforderlich, da Google die Knoten für Sie verwaltet.

Vorteile von Knoten in der richtigen Größe

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 Ihrer Arbeitslasten ordnungsgemäß 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.