Best Practices für ComputeClasses

Plattformentwickler können benutzerdefinierte ComputeClasses verwenden, um Knoteneinstellungen und Fallback-Prioritäten deklarativ zu konfigurieren, die Google Kubernetes Engine (GKE) beim Autoscaling zum Erstellen von Knoten verwendet. Sie können ComputeClasses basierend auf bestimmten Strategien und Arbeitslastanforderungen erstellen. In diesem Dokument finden Sie Best Practices zum Entwerfen und Implementieren von ComputeClasses in Ihren Clustern. Sie sollten bereits mit benutzerdefinierten ComputeClasses vertraut sein. Eine konsolidierte Übersicht aller Best Practices für GKE 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, basierend auf Zielen wie der Maximierung der Flexibilität, Effizienz, Verfügbarkeit und Leistung der Rechenkapazität. ComputeClasses 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 Pod-Ressourcenanforderungen 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 reduzieren, die mit inaktiver, ungenutzter Knotenkapazität verbunden sind.

Planungsleistung verbessern und Knoten optimieren

Wenn Sie Ihre Knoten mit der höchsten Priorität optimieren und die Planungslatenz reduzieren möchten, verwenden Sie in Ihrer ComputeClass eine Mischung aus manuell erstellten und automatisch erstellten Knotenpools. Diese Hybridstrategie reduziert die Häufigkeit, mit der 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 auf die Anforderungen Ihrer Pods abstimmen.

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

  1. Manuell erstellte Knotenpools: Diese Knotenpools haben genau die Spezifikationen, die Sie für die meisten Ihrer Pods verwenden möchten. 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: Als Fallback-Maßnahme können Sie mit der ComputeClass zusätzliche Knotenpools anfordern, 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 Planungslatenz 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

Das Feld whenUnsatisfiable steuert, was passiert, wenn GKE die Anforderungen einer der Prioritätsregeln in einer ComputeClass 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 einer beliebigen Maschinenreihe 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 Standard-Maschinenserie des Clusters verwenden.
  • Arbeitslasten, die spezielle Hardware erfordern: Geben Sie für Beschleuniger oder Hochleistungs-Computing-Arbeitslasten, die von bestimmter Hardware wie GPUs oder bestimmten Compute Engine-Maschinenserien abhängen, 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 sind. Dadurch wird verhindert, dass Pods auf inkompatibler Hardware ausgeführt werden.

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

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. Die GKE wendet die Standard-ComputeClass auf alle Arbeitslasten an, für die nicht explizit eine ComputeClass ausgewählt wurde. Wenn Sie eine Standard-ComputeClass festlegen, müssen Anwendungsoperatoren keine Knotenauswahl ändern oder bestimmte Knotenpools und Hardware in einzelnen Pods manuell anfordern. Wenn Sie eine Standard-ComputeClass auf Clusterebene festlegen, fügen Sie vorhandenen Knotenpools im Cluster keine Knotenlabels und Markierungen für andere ComputeClasses hinzu. Bei der Planung für die Standard-ComputeClass auf Clusterebene ignoriert GKE alle Knotenpools, die Knotenlabels oder Knotenmarkierungen für andere ComputeClasses haben.

ComputeClasses als Standard 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 mandantenfähige Umgebungen haben oder Arbeitslasten trennen möchten, die auf spezieller Hardware ausgeführt werden, konfigurieren Sie Standard-ComputeClasses 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, führen Sie diese Arbeitslasten im Autopilot-Modus mit ComputeClasses aus. Sie können den Autopilot-Modus in jeder ComputeClass aktivieren, auch wenn Sie einen Standardcluster haben. Die GKE führt die Arbeitslasten, die eine Autopilot-ComputeClass auswählen, 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, um Unterbrechungen oder unerwartetes Verhalten bei zustandsorientierten Arbeitslasten, die auf nichtflüchtigen Daten basieren, zu reduzieren.

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 haben, nicht geplante DaemonSet-Pods auszuführen. 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 in einem lokalen nichtflüchtigen Speicher angewiesen sind, kann das Verschieben der Pods auf neue Knoten zu Unterbrechungen führen, da die Pods den Zugriff auf nichtflüchtige Daten verlieren. Um dieses Problem zu vermeiden, deaktivieren Sie die aktive Migration für ComputeClasses, die für zustandsorientierte Arbeitslasten vorgesehen sind.

Planungszuverlässigkeit durch Verwendung von StorageClasses verbessern

Verwenden Sie StorageClasses, um die Zuverlässigkeit der Planung 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 volumeBindingMode-Feld 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 den Knoten bereit, auf dem der Pod ausgeführt wird.
  • Topologie-orientierte StorageClasses verwenden: Wenn Ihre ComputeClass mehrere Generationen von Maschinenserien umfasst, verwenden Sie eine StorageClass, für die die automatische Auswahl des Laufwerkstyps (parameters.type: dynamic) aktiviert ist und die nur auf Knoten geplant wird, die die von Ihnen angegebenen Laufwerkstypen unterstützen. Beispiel: Ihre ComputeClass fällt bei zonalen Kapazitätsengpässen von reinen Hyperdisk-Serien wie C4, C4D oder N4 auf Persistent Disk-Serien wie N2 oder N2D zurück. Sie können die integrierte StorageClass dynamic-rwo oder eine benutzerdefinierte StorageClass verwenden. Ihre zustandsorientierten Arbeitslasten können dann über mehrere Compute Engine-Instanzgenerationen hinweg ein Failover ausführen, da der Cluster Autoscaler dynamisch einen kompatiblen Laufwerkstyp (hyperdisk-balanced oder pd-balanced) für den bereitgestellten Fallback-Knoten 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 statt Maschinentypen anfordern

Sie können in ComputeClass-Prioritätsregeln eine Compute Engine-Maschinenserie oder bestimmte Maschinentypen anfordern. Wenn Sie keine strikte Abhängigkeit von einem bestimmten Maschinentyp haben, wählen Sie eine Maschinenreihe im Feld machineFamily aus. Während eines Skalierungsvorgangs kann GKE Knoten erstellen, die einen beliebigen geeigneten Maschinentyp in dieser Maschinenreihe verwenden. Dadurch erhöht sich die Wahrscheinlichkeit, dass Ihre Pods auf der von Ihnen bevorzugten Knotenkonfiguration ausgeführt werden.

Kapazitätsreservierungen für gefragte Hardware verwenden

Wenn Ihre Arbeitslasten auf stark nachgefragte Hardware wie TPUs oder Hochleistungs-GPUs angewiesen sind, erstellen Sie Compute Engine-Kapazitätsreservierungen für die Hardware und nutzen Sie diese Reservierungen in Ihren ComputeClasses. Kapazitätsreservierungen erhöhen die Wahrscheinlichkeit, dass Hardware in Ihrer Region oder Zone verfügbar ist. Dadurch können Sie die Flexibilität, Effizienz und Verfügbarkeit der Rechenkapazität erhöhen. Wenn Sie eine Reservierung in einer ComputeClass 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 der ComputeClass 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 das Autoscaling diese Reservierung erkennt. Warten Sie nach dem Erstellen einer Reservierung mindestens eine Stunde, bevor Sie diese Reservierung 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 ComputeClasses in Ihren Clustern. Diese Maßnahmen sind wichtig, da ComputeClasses verwendet werden können, um Knoten zu erstellen und zu konfigurieren, die Hardware verwenden, die teuer oder nur begrenzt verfügbar ist. Ein vorsätzlicher oder versehentlicher Missbrauch kann zu Unterbrechungen der Arbeitslast, ungeplanten Gebühren für die Ressourcennutzung und zur Erschöpfung von Kontingenten führen.

API-Zugriff auf ComputeClass-Konfigurationen einschränken

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

ComputeClass-Verfügbarkeit nach Namespace einschränken

GKE-Kunden trennen verschiedene Teams oder Arbeitslasttypen häufig nach Kubernetes-Namespace. ComputeClasses sind eine clusterbezogene Ressource. Das bedeutet, dass jede Arbeitslast in jedem Namespace standardmäßig jede ComputeClass auswählen kann. Um absichtlichen oder versehentlichen Missbrauch zu vermeiden, können Sie mit ValidatingAdmissionPolicies die Gruppe von ComputeClasses steuern, die Arbeitslasten in jedem Namespace auswählen können. Sie können beispielsweise verhindern, dass Pods in Ihrem Web-Frontend-Namespace ComputeClasses auswählen können, die Beschleuniger erstellen. Prüfen Sie, ob Ihre ValidatingAdmissionPolicies die folgenden gängigen Konfigurationen prüfen:

  • Alle Auswahlfelder prüfen: Eine Arbeitslast kann eine ComputeClass über das Feld nodeSelector, nodeAffinity oder tolerations in der Pod-Spezifikation auswählen. Prüfen Sie alle diese Felder in Ihren ValidatingAdmissionPolicy-Ausdrücken, um eine unbeabsichtigte Auswahl von ComputeClass zu vermeiden.
  • Auf Umgehungen von Platzhaltertolerierungen prüfen: Blockieren oder validieren Sie Platzhaltertolerierungen explizit (z. B. die Tolerierung operator: Exists ohne Schlüssel). Diese Platzhalterselektoren können die meisten Knotenmarkierungen umfassen, einschließlich ComputeClass-Markierungen.
  • Alle Arbeitslast-Controller prüfen: Konfigurieren Sie die matchConstraints der Richtlinie so, dass alle Arbeitslast-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, um das Risiko von Unterbrechungen oder hängenden Pods zu verringern.

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 dies die Erstellung neuer Knotenpools in Ihrem Cluster auslösen. 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.

Betrachten Sie beispielsweise eine ComputeClass, die nur On-Demand-Instanzen anfordert. 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. 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 den Einstellungen für die aktive Migration und das Autoscaling testen

Die Einstellungen für die aktive Migration und das 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 nicht ausgelasteten 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 ComputeClasses vornehmen, sollten Sie die Änderungen in einer Staging-Umgebung testen. Sie können Annotationen auch verwenden, um kritische Arbeitslasten während der Skalierung vor einer Bereinigung zu schützen.

ComputeClass-CRD-Updates vor Clusterupgrades testen

Die GKE aktualisiert die CustomResourceDefinition (CRD) für ComputeClass regelmäßig, um Felder hinzuzufügen, das Feldverhalten zu ändern und Probleme zu beheben. Feldhinzufügungen und -änderungen werden in der Regel in bestimmten GKE-Versionen wirksam. Bevor Sie Ihre Produktionscluster auf neue Neben- oder Patchversionen aktualisieren, sollten Sie anhand der folgenden Richtlinien prüfen, ob Änderungen an der CRD zu Problemen mit Arbeitslasten führen:

  • Testen Sie das Upgrade in einer Staging-Umgebung.
  • Informationen zu Änderungen oder Ergänzungen der ComputeClass-CRD finden Sie in den GKE-Versionshinweisen.
  • Informationen zu Feldaktualisierungen in der Ziel-Upgrade-Version finden Sie auf der Referenzseite zur ComputeClass-CRD.

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

ComputeClass-Vorgänge, die Pod-Entfernungen verursachen, z. B. die 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 eine Pod-Entfernung gegen dieses Budget verstößt, entfernt GKE den Pod nicht. Geben Sie PodDisruptionBudgets für Arbeitslasten wie die folgenden an:

  • Zustandslose Arbeitslasten, z. B. Inferenzbereitstellungen.
  • Replizierte zustandsorientierte Arbeitslasten, z. B. hochverfügbare Datenbankanwendungen.

Verlassen Sie sich nicht auf PodDisruptionBudgets, um Arbeitslasten zu schützen, die bis zum Ende ausgeführt werden müssen, nur eine Instanz haben oder auf lokalen nichtflüchtigen Daten basieren. Geben Sie ein Budget an, das ein ausgewogenes Verhältnis zwischen der Verfügbarkeit von Arbeitslasten und der Möglichkeit bietet, Funktionen wie Upgrades abzuschließen.

Kritische Arbeitslasten vor einer Bereinigung schützen

Wenn Sie Arbeitslasten haben, bei denen jeder Pod bis zum Ende 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 Autoscaling-Vorgängen entfernt. Verwenden Sie diese Annotation, um Pods zu schützen, die keine Unterbrechungen tolerieren, z. B. zustandsorientierte Arbeitslasten mit einer einzelnen Instanz und lang andauernde Batchjobs.

Zusammenfassung der Best Practices

In diesem Dokument werden die folgenden Best Practices für ComputeClasses beschrieben:

Nächste Schritte