Best Practices für ComputeClasses

Plattformtechniker können benutzerdefinierte ComputeClasses verwenden, um Knoteneinstellungen und Fallback-Prioritäten deklarativ zu konfigurieren, die Google Kubernetes Engine (GKE) zum Erstellen von Knoten während des Autoscalings verwendet. Sie können ComputeClasses basierend auf bestimmten Strategien und Arbeitslastanforderungen erstellen. In diesem Dokument finden Sie Best Practices für das Entwerfen und Implementieren von ComputeClasses in Ihren Clustern. Sie sollten bereits mit benutzerdefinierten Compute-Klassen vertraut sein. Eine konsolidierte Übersicht über alle GKE-Best Practices finden Sie unter Best Practices für GKE.

ComputeClass-Design

In den folgenden Abschnitten finden Sie Best Practices für das Entwerfen und Implementieren von ComputeClasses in Ihren Clustern, um Ziele wie die Maximierung der Flexibilität, Effizienz, Verfügbarkeit und Leistung der Rechenkapazität zu erreichen. Compute-Klassen funktionieren sowohl mit manuell erstellten als auch mit automatisch erstellten Knotenpools.

Jede ComputeClass basierend auf einer Strategie entwerfen

Entwerfen Sie jede ComputeClass so, dass sie ein bestimmtes Ziel für Ihre Arbeitslasten, Teams oder Organisation erfüllt. Nutzen Sie das Fallback-Verhalten von ComputeClasses und die Möglichkeit, sowohl manuell erstellte als auch automatisch erstellte Knotenpools auszuwählen, um bestimmte Ergebnisse zu priorisieren, z. B. die Reduzierung des manuellen Aufwands oder die Verbesserung der Planungsleistung. In den folgenden Abschnitten werden gängige Strategien beschrieben.

Ressourcenverfügbarkeit verbessern und manuellen Aufwand reduzieren

Wenn Sie die Erstellung von Knotenpools an GKE delegieren möchten, verwenden Sie in Ihrer ComputeClass nur automatisch erstellte Knotenpools. Der Autoscaler konfiguriert Knoten basierend auf der Hardwareverfügbarkeit, den Ressourcenanforderungen von Pods und der zonalen Kapazität. Mit dieser Strategie müssen Sie Knotenpools nicht mehr manuell erstellen und optimieren. Außerdem können Sie die Kosten für ungenutzte Knotenkapazität im Leerlauf senken.

Planungsleistung verbessern und Knoten optimieren

Um Ihre Knoten mit der höchsten Priorität zu optimieren und die Planungslatenz zu verringern, verwenden Sie in Ihrer ComputeClass eine Mischung aus manuell erstellten und automatisch erstellten Knotenpools. Diese Hybridstrategie reduziert, wie oft Pods darauf warten, dass GKE neue Knotenpools erstellt. Da Ihre Knotenpools mit der höchsten Priorität manuell erstellt werden, können Sie die Hardware genau an die Anforderungen Ihrer Pods anpassen.

Die Hybridstrategie umfasst die folgenden Arten von Knotenpools in der Reihenfolge der Priorität in der ComputeClass:

  1. Manuell erstellte Knotenpools: Diese Knotenpools haben genau die Spezifikationen, auf denen die meisten Ihrer Pods ausgeführt werden sollen. Konfigurieren Sie diese Knotenpools mit bestimmten Knotenlabels, Knoten-Taints, Kapazitätsreservierungen oder speziellen Konfigurationen wie kubelet-Parametern. Erstellen Sie diese Knotenpools mit so vielen Knoten, wie Ihre Pods voraussichtlich benötigen. Weisen Sie diesen Knotenpools in Ihrer ComputeClass die höchste Priorität zu.
  2. Automatisch erstellte Knotenpools: Verwenden Sie als Fallback-Maßnahme die ComputeClass, um zusätzliche Knotenpools anzufordern, die weiterhin für Ihre Pods optimiert sind. Weisen Sie diesen automatisch erstellten Knotenpools eine niedrigere Priorität zu als Ihren manuell erstellten Knotenpools.

In der folgenden Beispiel-ComputeClass wird diese Hybridstrategie verwendet:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: hybrid-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - nodepools: ['manual-pool1']
  - machineFamily: n4
    minCores: 16
    minMemoryGb: 64
  whenUnsatisfiable: DoNotScaleUp

Wenn Sie eine Arbeitslast bereitstellen, die diese ComputeClass verwendet, platziert GKE Pods auf verfügbaren Knoten in manual-pool1. GKE erstellt neue Knotenpools nur, wenn der manuell erstellte Knotenpool keine verfügbare Kapazität hat. Die Planungs-Latenz nimmt ab, wenn die Anzahl der vorhandenen Knoten im manuell erstellten Knotenpool zunimmt, da GKE nicht so häufig neue Knoten erstellen muss.

Skalierungsverhalten für den Notfall explizit definieren

Mit dem Feld whenUnsatisfiable wird gesteuert, was passiert, wenn GKE die Anforderungen einer der Prioritätsregeln in einer Compute-Klasse nicht erfüllen kann. Um unerwartetes Verhalten nach einem Versionsupgrade zu vermeiden, geben Sie in jeder ComputeClass explizit einen Wert für dieses Feld an. Wenn Sie einen Wert festlegen, wissen ComputeClass-Nutzer, was sie erwartet, wenn sie diese ComputeClass in einer Arbeitslast auswählen. Der empfohlene Wert für dieses Feld hängt vom Typ der Arbeitslast ab:

  • Arbeitslasten für allgemeine Zwecke: Wenn Ihre Arbeitslasten auf jeder Maschinenserie ausgeführt werden können, geben Sie den Wert ScaleUpAnyway an. Wenn keine Knoten verfügbar sind, die einer Prioritätsregel in der ComputeClass entsprechen, skaliert GKE Knoten hoch, die die Standardmaschinenreihe des Clusters verwenden.
  • Arbeitslasten, die spezielle Hardware erfordern: Für Beschleuniger oder Hochleistungs-Computing-Arbeitslasten, die von bestimmter Hardware wie GPUs oder bestimmten Compute Engine-Maschinenserien abhängen, geben Sie den Wert DoNotScaleUp an. Wenn keine Knoten verfügbar sind, die einer Prioritätsregel in der ComputeClass entsprechen, bleiben die Pods im Status Pending, bis Ressourcen verfügbar werden. So wird verhindert, dass Pods auf inkompatibler Hardware ausgeführt werden.

Weitere Informationen finden Sie unter Skalierungsverhalten definieren, wenn keine Prioritätsregeln gelten.

Standard-ComputeClass auf Clusterebene für die meisten Arbeitslasten festlegen

Wenn die meisten Ihrer Arbeitslasten dieselben Hardwareanforderungen haben, konfigurieren Sie eine Standard-ComputeClass für den Cluster. GKE wendet die Standard-ComputeClass auf alle Arbeitslasten an, für die keine ComputeClass explizit ausgewählt wurde. Durch das Festlegen einer Standard-ComputeClass müssen Anwendungsoperatoren keine Knotenselektoren ändern oder bestimmte Knotenpools und Hardware in einzelnen Pods manuell anfordern. Wenn Sie eine Standard-Compute-Klasse auf Clusterebene festlegen, fügen Sie vorhandenen Knotenpools im Cluster keine Knotenlabels und Taints für andere Compute-Klassen hinzu. Bei der Planung für die Standard-ComputeClass auf Clusterebene ignoriert GKE alle Knotenpools, die Knotenlabels oder Knotenmarkierungen für andere ComputeClasses haben.

Standard-ComputeClasses für Namespaces festlegen, um Mandanten zu trennen

Zusätzlich zu einer Standard-ComputeClass auf Clusterebene können Sie eine Standard-ComputeClass für bestimmte Namespaces festlegen. Wenn Sie Multi-Tenant-Umgebungen haben oder Arbeitslasten trennen möchten, die auf spezialisierter Hardware ausgeführt werden, konfigurieren Sie Standard-Compute-Klassen für diese Namespaces. Damit System-Pods nicht auf spezieller Hardware wie GPU-Knoten ausgeführt werden, fügen Sie eine ComputeClass für allgemeine Zwecke als Standard-ComputeClass für System-Namespaces hinzu.

Arbeitslasten mit geringer Interaktion im Autopilot-Modus ausführen

Wenn Sie Arbeitslasten haben, die keine manuelle Interaktion oder Verwaltung erfordern, können Sie diese Arbeitslasten im Autopilot-Modus mit Compute-Klassen ausführen. Sie können den Autopilot-Modus in jeder ComputeClass aktivieren, auch wenn Sie einen Standardcluster haben. GKE führt die Arbeitslasten, für die eine Autopilot-Compute-Klasse ausgewählt wurde, auf vollständig verwalteten Knoten aus, die die Sicherheits-, Skalierungs- und Abrechnungsfunktionen von GKE Autopilot implementieren. Weitere Informationen finden Sie unter Arbeitslasten im Autopilot-Modus in GKE Standard.

Zustandsorientierte Arbeitslasten

In den folgenden Abschnitten finden Sie Best Practices, mit denen Sie Unterbrechungen oder unerwartetes Verhalten bei zustandsorientierten Arbeitslasten, die auf persistenten Daten basieren, reduzieren können.

Aktive Migration deaktivieren

Bei der aktiven Migration werden Pods automatisch auf neue Knoten verschoben, die in der ComputeClass eine höhere Priorität haben oder die Kapazität zum Ausführen nicht geplanter DaemonSet-Pods haben. Während der aktiven Migration beendet GKE Pods auf vorhandenen Knoten und erstellt neue Pods auf Knoten mit höherer Priorität. Wenn Sie Arbeitslasten haben, die auf Daten im lokalen nichtflüchtigen Speicher angewiesen sind, kann das Verschieben der Pods auf neue Knoten zu Störungen führen, da die Pods den Zugriff auf persistente Daten verlieren. Um dieses Problem zu vermeiden, deaktivieren Sie die aktive Migration für Compute-Klassen, die für zustandsorientierte Arbeitslasten vorgesehen sind.

Planungszuverlässigkeit durch Verwendung von StorageClasses verbessern

Verwenden Sie StorageClasses, um die Planungszuverlässigkeit für zustandsorientierte Arbeitslasten auf folgende Weise zu verbessern:

  • Volumes erst nach der Pod-Erstellung erstellen: Wenn Sie die dynamische Volume -Bereitstellung verwenden, geben Sie in einer StorageClass im Feld volumeBindingMode den Wert WaitForFirstConsumer an. Dieser Volume-Bindungsmodus verhindert die Erstellung eines PersistentVolume, bis GKE einen Pod erstellt hat, der den entsprechenden PersistentVolumeClaim verwendet. GKE stellt das PersistentVolume in derselben Zone wie der Knoten bereit, auf dem der Pod ausgeführt wird.
  • Topologiebewusste StorageClasses verwenden:Wenn sich Ihre Compute-Klasse über mehrere Generationen einer Maschinenreihe erstreckt (z. B. C4 und C3), verwenden Sie eine StorageClass, für die die automatische Auswahl des Festplattentyps aktiviert ist und die nur auf Knoten geplant wird, die die angegebenen Festplattentypen unterstützen. Sie können die integrierte dynamic-rwo-StorageClass oder eine benutzerdefinierte StorageClass verwenden. Ihre zustandsorientierten Arbeitslasten können dann auf mehreren Compute Engine-Instanzgenerationen ausgeführt werden, da der Cluster-Autoscaler dynamisch einen kompatiblen Festplattentyp auswählt.

Infrastruktur für Flexibilität, Effizienz und Verfügbarkeit von Rechenkapazität entwerfen

In den folgenden Abschnitten finden Sie Best Practices zur Verbesserung der Flexibilität, Effizienz und Verfügbarkeit von Rechenkapazität in ComputeClasses, damit Ihre Pods weniger Zeit im Status Pending verbringen.

Maschinenreihen anstelle von Maschinentypen anfordern

Sie können eine Compute Engine-Maschinenreihe oder bestimmte Maschinentypen in ComputeClass-Prioritätsregeln anfordern. Sofern Sie nicht von einem bestimmten Maschinentyp abhängig sind, wählen Sie eine Maschinenserie über das machineFamily-Feld aus. Während eines Skalierungsvorgangs kann GKE Knoten erstellen, die einen beliebigen geeigneten Maschinentyp in dieser Maschinenreihe verwenden. Dadurch wird die Wahrscheinlichkeit erhöht, dass Ihre Pods mit Ihrer bevorzugten Knotenkonfiguration ausgeführt werden.

Kapazitätsreservierungen für stark nachgefragte Hardware verwenden

Wenn Ihre Arbeitslasten auf stark nachgefragte Hardware wie TPUs oder leistungsstarke GPUs angewiesen sind, erstellen Sie Compute Engine-Kapazitätsreservierungen für die Hardware und nutzen Sie diese Reservierungen in Ihren Compute-Klassen. Kapazitätsreservierungen erhöhen die Wahrscheinlichkeit, dass Hardware in Ihrer Region oder Zone verfügbar ist. So können Sie die Flexibilität, Effizienz und Verfügbarkeit von Rechenkapazität steigern. Wenn Sie eine Reservierung in einer Compute-Klasse nutzen möchten, ohne das Fallback-Verhalten zu beeinträchtigen, verwenden Sie die Reservierungsaffinität Specific oder AnyThenFail. Wenn Sie die Affinität AnyBestEffort oder Automatic verwenden und keine reservierte Kapazität verfügbar ist, umgeht Compute Engine möglicherweise die Prioritätsregeln für Compute-Klassen und greift auf On-Demand-Hardware zurück. Weitere Informationen finden Sie unter Reservierte zonale Ressourcen nutzen.

Mindestens eine Stunde lang keine neuen Reservierungen nutzen

Der Cluster Autoscaler speichert Informationen zu Kapazitätsreservierungen in einem Cache. Wenn Sie eine neue Kapazitätsreservierung erstellen, kann es bis zu einer Stunde dauern, bis der Autoscaler diese Reservierung erkennt. Nachdem Sie eine Reservierung erstellt haben, warten Sie mindestens eine Stunde, bevor Sie sie in einer Arbeitslast verwenden. Wenn Sie eine Arbeitslast bereitstellen, die die Reservierung verwendet, bevor der Autoscaler die Reservierung im Cache speichert, schlägt der Autoscaling-Vorgang möglicherweise fehl.

Sicherheit

In den folgenden Abschnitten finden Sie Best Practices zur Verbesserung der Sicherheit der Compute-Klassen in Ihren Clustern. Diese Maßnahmen sind wichtig, da mit ComputeClasses Knoten erstellt und konfiguriert werden können, die Hardware verwenden, die teuer ist oder nur begrenzt verfügbar ist. Eine absichtliche oder versehentliche Falschverwendung kann zu Unterbrechungen der Arbeitslast, ungeplanten Gebühren für die Ressourcennutzung und einer Erschöpfung des Kontingents führen.

API-Zugriff auf ComputeClass-Konfigurationen einschränken

Arbeitslasten können ComputeClasses verwenden, um Knoten zu erstellen, auf denen spezielle Hardware wie GPUs und TPUs ausgeführt wird. Beschränken Sie den Zugriff zum Erstellen, Ändern und Löschen von ComputeClasses auf dieselben Principals, die Knoten in Ihren Clustern erstellen, ändern und löschen können. Um den Zugriff auf ComputeClasses zu steuern, verwenden Sie RBAC-Richtlinien.

Verfügbarkeit von ComputeClass nach Namespace einschränken

GKE-Kunden trennen verschiedene Teams oder Arbeitslasttypen häufig nach Kubernetes-Namespace. ComputeClasses sind eine clusterbezogene Ressource. Das bedeutet, dass standardmäßig jede Arbeitslast in jedem Namespace jede ComputeClass auswählen kann. Um vorsätzlichen oder versehentlichen Missbrauch zu vermeiden, können Sie ValidatingAdmissionPolicies verwenden, um die Menge der Compute-Klassen zu steuern, die Arbeitslasten in jedem Namespace auswählen können. Sie können beispielsweise verhindern, dass Pods in Ihrem Web-Frontend-Namespace Compute-Klassen auswählen, mit denen Beschleuniger erstellt werden. Prüfen Sie, ob Ihre ValidatingAdmissionPolicies die folgenden gängigen Konfigurationen berücksichtigen:

  • Alle Auswahlfelder prüfen:Eine Arbeitslast kann eine ComputeClass auswählen, indem sie das Feld nodeSelector, nodeAffinity oder tolerations in der Pod-Spezifikation verwendet. Um eine unbeabsichtigte Auswahl von ComputeClass zu vermeiden, prüfen Sie alle diese Felder in Ihren ValidatingAdmissionPolicy-Ausdrücken.
  • Bypässe für Platzhalter-Toleranzen prüfen:Platzhalter-Toleranzen explizit blockieren oder validieren (z. B. die operator: Exists-Toleranz ohne Schlüssel). Diese Platzhalterselektoren können die meisten Knoten-Taints umfassen, einschließlich ComputeClass-Taints.
  • Alle Workload-Controller prüfen:Konfigurieren Sie die matchConstraints der Richtlinie so, dass alle Workload-Controller-Ressourcen (z. B. Deployment, StatefulSet, DaemonSet, Job und CronJob) abgedeckt sind. Beschränken Sie Ihre Prüfungen nicht nur auf Pod-Ressourcen.

Weitere Informationen finden Sie unter Zugriff zum Ändern und Auswählen von ComputeClasses einschränken.

Zuverlässigkeit

In den folgenden Abschnitten finden Sie Best Practices zur Verbesserung der Zuverlässigkeit von Autoscaling und Pod-Migration für ComputeClasses, wodurch das Risiko von Unterbrechungen oder hängenden Pods verringert wird.

Verwendung widersprüchlicher Knotenauswahlen verhindern

Knotenselektoren in Ihren Pods wirken sich darauf aus, wo GKE diese Pods platziert. Im Autopilot-Modus oder bei der automatischen Erstellung von Knotenpools kann dadurch die Erstellung neuer Knotenpools in Ihrem Cluster ausgelöst werden. Wenn Sie Pods haben, die eine ComputeClass auswählen und Knotenselektoren verwenden, um Knoten anzufordern, die mit der ComputeClass-Konfiguration in Konflikt stehen, plant GKE die Pods möglicherweise überhaupt nicht.

Angenommen, Sie haben eine ComputeClass, in der nur On-Demand-Instanzen angefordert werden. Wenn ein Pod diese ComputeClass und Spot-VMs in einer Knotenauswahl auswählt, kann GKE den Pod nicht planen, da die ComputeClass und die Knotenauswahl miteinander in Konflikt stehen. Um dieses Problem zu vermeiden, verwenden Sie Methoden wie ValidatingAdmissionPolicies, um zu verhindern, dass Pods, die ComputeClasses auswählen, auch Systemknotenlabels auswählen. Weitere Informationen finden Sie unter Knotenselektoren für Systemknotenlabels.

Alle Änderungen an aktiven Migrations- und Autoscaling-Einstellungen testen

Die Einstellungen für aktive Migration und Autoscaling in einer ComputeClass wirken sich direkt darauf aus, wie oft GKE Ihre Pods beendet, um Aufgaben wie das Verschieben von Pods auf bevorzugte Hardware und das Konsolidieren von unterlasteten Knoten auszuführen. Änderungen an diesen Einstellungen in einer vorhandenen ComputeClass können zu unerwarteten Unterbrechungen der Arbeitslast führen. Bevor Sie Änderungen an diesen Einstellungen in vorhandenen Compute-Klassen vornehmen, sollten Sie die Änderungen in einer Staging-Umgebung testen. Sie können auch Annotationen verwenden, um kritische Arbeitslasten während der Skalierung vor dem Entfernen zu schützen.

ComputeClass-CRD-Updates vor Clusterupgrades testen

GKE aktualisiert die ComputeClass CustomResourceDefinition (CRD) regelmäßig, um Felder hinzuzufügen, das Feldverhalten zu ändern und Probleme zu beheben. Feldänderungen und ‑ergänzungen werden in der Regel in bestimmten GKE-Versionen wirksam. Bevor Sie Ihre Produktionscluster auf neue Neben- oder Patchversionen aktualisieren, prüfen Sie anhand der folgenden Richtlinien, ob Änderungen an der CRD Probleme mit der Arbeitslast verursachen:

PodDisruptionBudgets verwenden, um die Verfügbarkeit von Arbeitslasten zu verbessern

ComputeClass-Vorgänge, die zu Pod-Entfernungen führen, z. B. aktive Migration, berücksichtigen alle konfigurierten PodDisruptionBudgets. Sie können beispielsweise ein Inferenz-Deployment so konfigurieren, dass ein PodDisruptionBudget erforderlich ist, bei dem mehr als 70% der Pods verfügbar sein müssen. Wenn während der aktiven Migration durch die Entfernung eines Pods gegen dieses Budget verstoßen wird, entfernt GKE den Pod nicht. Geben Sie PodDisruptionBudgets für Arbeitslasten wie die folgenden an:

  • Zustandslose Arbeitslasten wie Inferenzbereitstellungen.
  • Replizierte zustandsorientierte Arbeitslasten wie hochverfügbare Datenbankanwendungen.

Verlassen Sie sich nicht auf PodDisruptionBudgets, um Arbeitslasten zu schützen, die bis zum Abschluss ausgeführt werden müssen, nur eine Instanz haben oder auf lokale persistente Daten angewiesen sind. Geben Sie ein Budget an, das ein Gleichgewicht zwischen der Verfügbarkeit von Arbeitslasten und der Ausführung von Funktionen wie Upgrades schafft.

Kritische Arbeitslasten vor dem Entfernen schützen

Wenn Sie Arbeitslasten haben, bei denen jeder Pod bis zum Abschluss ausgeführt werden muss, bevor er beendet wird, fügen Sie der Pod-Spezifikation die Annotation cluster-autoscaler.kubernetes.io/safe-to-evict: "false" hinzu. Diese Annotation verhindert, dass GKE Pods während des Autoscalings entfernt. Verwenden Sie diese Annotation, um Pods zu schützen, die keine Unterbrechungen tolerieren können, z. B. zustandsorientierte Arbeitslasten mit einer einzelnen Instanz und lang andauernde Batchjobs.

Zusammenfassung der Best Practices

Dieses Dokument enthält die folgenden Best Practices für ComputeClasses:

Nächste Schritte