GKE-Knotengröße

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 die Google Cloud 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 des Löschens wegen mangelnder Ressourcen.
  • Verbesserte Skalierbarkeit für das 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

Auf GKE-Knoten werden Systemkomponenten ausgeführt, mit denen der Knoten als Teil Ihres 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-Instanz basieren, und den Ressourcen, die für Ihre GKE-Arbeitslasten verfügbar sind. Dieser Unterschied besteht, da GKE eine vordefinierte Menge an Ressourcen für Systemfunktionalität und Knotenzuverlässigkeit reserviert. Der von GKE für Systemressourcen reservierte Speicherplatz variiert je nach dem 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 Anfragen und Limits für Ressourcen angeben. Wenn GKE die Pods auf einem Knoten platziert, fordern die Pods 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 den 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 für sitzungsspezifischen Speicher 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 auch mehr Ressourcen als entsprechende Linux-Knoten, um das Windows-Betriebssystem und die Windows Server-Komponenten auszuführen, 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.

Für Standardknotenpools mit GKE 1.37 oder höher können Sie die Menge an CPU und Arbeitsspeicher anpassen, die für Systemkomponenten reserviert ist. Weitere Informationen finden Sie unter Systemressourcen reservierungen (Vorschau).

Arbeitsspeicherreservierungen

GKE berechnet Arbeitsspeicherreservierungen auf folgende Weise, je nach GKE-Version, mit der der Knotenpool erstellt wurde:

  • Wenn der Knotenpool mit GKE Version 1.37 oder höher erstellt wurde, verwendet GKE die folgende Formel:

    MemoryReserved = Min(EarlierMemoryReservation, (15 MiB * MaxPodsPerNode) + BaseOverhead)

    GKE verwendet den niedrigeren Wert einer Berechnung, die die Pod-Dichte berücksichtigt, oder EarlierMemoryReservation, die Reservierungsberechnung für Knotenpools, die mit Version 1.36 oder früher erstellt wurden.

    In dieser Formel hängt der Wert von BaseOverhead von der Knotenkonfiguration ab:

    Zusätzlich werden 100 MiB Arbeitsspeicher für Schwellenwerte für die Pod-Bereinigung reserviert.

  • Wenn der Knotenpool mit GKE Version 1.36 oder früher erstellt wurde, verwendet GKE die folgende Formel. GKE verwendet diese Formel auch dann, wenn der Knotenpool später auf Version 1.37 oder höher aktualisiert wird:

    • 255 MiB für Maschinen 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% des Arbeitsspeichers über 128 GiB
    • Zusätzlich 100 MiB Arbeitsspeicher für Schwellenwerte für die Pod-Bereinigung
    • Wenn Image-Streaming aktiviert ist, ein zusätzlicher Puffer, wie unter Arbeitsspeicherreservierung für Image-Streaming beschrieben.

CPU-Reservierungen

Für Knotenpools, die mit GKE Version 1.37 oder höher erstellt wurden, begrenzt GKE die gesamte CPU-Reservierung auf maximal 1 vCPU (1.000 mCPU) für Standard-Compute-Instanzen ohne Teilnutzung. Systemkomponenten können bei Bedarf weiterhin über dieses Limit hinausgehen. Das Limit von 1 vCPU trägt dazu bei, dass bei Compute-Instanzen mit vielen Kernen nicht mehrere Kerne der zuweisbaren Kapazität für Systemreservierungen verloren gehen. Das Limit von 1 vCPU gilt nicht für Knotenpools, die mit GKE Version 1.36 oder früher erstellt wurden. GKE berechnet CPU-Reservierungen mit der folgenden Formel:

  • 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 über vier Kerne

Für E2-Maschinentypen mit gemeinsam genutztem Kernreserviert GKE weiterhin insgesamt 1.060 Millicore.

Lokale sitzungsspezifische Speicherreservierung

GKE stellt Knoten mit lokalem sitzungsspezifischem 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 zuweisen, um ihn für Zwecke wie Logs zu verwenden. 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 der 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

In 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. Beachten Sie, dass dies vor der Formatierung der Laufwerke berechnet wird. Die nutzbare Kapazität ist also je nach Knoten-Image-Version um einige Prozent geringer.

GKE berechnet die Systemreservierung je nach 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

  1. 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.

  2. Ü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 automatische Knotenscaling ist weniger flexibel , da mehr Pods entfernt werden müssen, damit eine Herunterskalierung erfolgen kann.
    • Eine große Anzahl kleiner Knoten eignet sich gut für hochverfügbare Arbeitslasten, die nicht ressourcenintensiv sind. Das automatische Knotenscaling ist flexibler , da weniger Pods entfernt werden müssen, damit eine Herunterskalierung erfolgen kann.

  3. Verwenden Sie den Vergleichsleitfaden für Compute Engine-Maschinenfamilien , um die Maschinenreihe und -familie zu bestimmen, die Sie für Ihre Knoten benötigen.

  4. Berücksichtigen Sie die Anforderungen an sitzungsspezifischen Speicher Ihrer Arbeitslasten. Reicht das Bootlaufwerk des Knotens aus? Benötigen Sie lokale SSDs?

  5. 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 die Kosten für die zusätzlichen Ressourcen zu vermeiden.
    • Wenn der ausgewählte Maschinentyp zu klein ist, sollten Sie eine größere Maschine in Betracht ziehen, um das Risiko von Arbeitslastunterbrechungen zu verringern.

Nächste Schritte