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. Dieses Dokument enthält Best Practices für das Entwerfen und Implementieren von ComputeClasses in Ihren Clustern. Sie sollten bereits mit benutzerdefinierten ComputeClasses 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 basierend auf Zielen wie der Maximierung der Verfügbarkeit und Leistung. 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. den manuellen Aufwand zu reduzieren oder die Planungsleistung zu verbessern. In den folgenden Abschnitten werden gängige Strategien beschrieben.

Verfü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. Das Autoscaling konfiguriert Knoten basierend auf der Hardwareverfügbarkeit, den Ressourcenanforderungen der Pods und der zonalen Kapazität. Mit dieser Strategie müssen Sie Knotenpools nicht manuell erstellen und optimieren. Außerdem können Sie die Kosten für ungenutzte Knotenkapazität im Leerlauf senken.

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. Mit dieser Hybridstrategie wird die Häufigkeit reduziert, 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 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 die genauen Spezifikationen, die Sie für die meisten Ihrer Pods wünschen. Konfigurieren Sie diese Knotenpools mit bestimmten Knotenlabels, Knotenmarkierungen, 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 die ComputeClass als Fallback-Maßnahme, 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.

Die folgende Beispiel-ComputeClass verwendet diese Hybridstrategie:

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 nur dann neue Knotenpools, wenn der manuell erstellte Knotenpool keine verfügbare Kapazität hat. Die Planungslatenz sinkt, wenn die Anzahl der vorhandenen Knoten im manuell erstellten Knotenpool steigt, da GKE nicht so häufig neue Knoten erstellen muss.

Skalierungsverhalten im Notfall explizit definieren

Das Feld whenUnsatisfiable steuert, was passiert, wenn GKE die Anforderungen keiner der Prioritätsregeln in einer ComputeClass erfüllen kann. Um unerwartetes Verhalten nach einem Versionsupgrade zu vermeiden, geben Sie für dieses Feld in jeder ComputeClass explizit einen Wert 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 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, die die Standard-Maschinenserie des Clusters verwenden.
  • Arbeitslasten, die spezielle Hardware benötigen: Für Arbeitslasten mit Beschleunigern oder Hochleistungs-Computing, die von bestimmter Hardware wie GPUs oder bestimmten Compute Engine-Maschinenserien abhängig sind, 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 sind. Mit diesem Ansatz 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, die keine ComputeClass explizit auswählen. Wenn Sie eine Standard-ComputeClass festlegen, müssen Anwendungsoperatoren keine Knotenselektoren ä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.

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 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. 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 zu reduzieren, die auf nichtflüchtige Daten angewiesen sind.

Aktive Migration deaktivieren

Bei der aktiven Migration werden Pods automatisch zu neuen 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 lokalem nichtflüchtigem Speicher angewiesen sind, kann das Verschieben der Pods zu neuen 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 mit StorageClasses verbessern

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

Verfügbarkeit

In den folgenden Abschnitten finden Sie Best Practices zur Verbesserung der Verfügbarkeit in ComputeClasses, damit Ihre Pods weniger Zeit im Status Pending verbringen.

Maschinenserien anstelle von Maschinentypen anfordern

Sie können in den Prioritätsregeln der ComputeClass eine Compute Engine-Maschinenserie oder bestimmte Maschinentypen anfordern. Sofern Sie nicht unbedingt einen bestimmten Maschinentyp benötigen, wählen Sie eine Maschinenserie mit dem machineFamily Feld aus. Bei einem Skalierungsvorgang kann GKE Knoten erstellen, die einen beliebigen geeigneten Maschinentyp in dieser Maschinenserie verwenden. Dadurch wird die Wahrscheinlichkeit erhöht, dass Ihre Pods mit der bevorzugten Knotenkonfiguration ausgeführt werden.

Kapazitätsreservierungen für gefragte Hardware verwenden

Wenn Ihre Arbeitslasten auf gefragte 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. So können Sie die Ressourcenverfügbarkeit verbessern. 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.

Neue Reservierungen mindestens eine Stunde lang nicht nutzen

Das Cluster-Autoscaling 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 sie in einer Arbeitslast nutzen. Wenn Sie eine Arbeitslast bereitstellen, die die Reservierung verwendet, bevor das Autoscaling 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 zum Erstellen und Konfigurieren von Knoten verwendet werden können, die teure oder nur begrenzt verfügbare Hardware verwenden. Eine absichtliche oder versehentliche missbräuchliche Verwendung kann zu Unterbrechungen der Arbeitslast, unerwarteten Gebühren für die Ressourcennutzung und Kontingentüberschreitungen führen.

API-Zugriff auf ComputeClass-Konfigurationen einschränken

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

Verfügbarkeit von ComputeClasses 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 eine beliebige ComputeClass auswählen kann. Um eine absichtliche oder versehentliche missbräuchliche Verwendung zu vermeiden, verwenden Sie ValidatingAdmissionPolicies, um die ComputeClasses zu 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. Um eine unbeabsichtigte Auswahl von ComputeClasses zu vermeiden, prüfen Sie alle diese Felder in Ihren ValidatingAdmissionPolicy-Ausdrücken.
  • Auf Wildcard-Toleranzumgehungen prüfen:Blockieren oder validieren Sie explizit Wildcard-Toleranzen (z. B. die Toleranz operator: Exists ohne Schlüssel). Diese Wildcard-Selektoren können die meisten Knotenmarkierungen umfassen, einschließlich ComputeClass-Markierungen.
  • Alle Arbeitslastcontroller prüfen: Konfigurieren Sie die matchConstraints der Richtlinie so, dass alle Arbeitslastcontroller-Ressourcen abgedeckt sind (z. B. Deployment, StatefulSet, DaemonSet, Job und CronJob). 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 des Autoscalings und der Pod-Migration für ComputeClasses. Dadurch wird das Risiko von Unterbrechungen oder Pods im Status `Pending` reduziert.

Verwendung von in Konflikt stehenden Knotenselektoren 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 gar nicht.

Betrachten Sie beispielsweise eine ComputeClass, die nur On-Demand-Instanzen anfordert. Wenn ein Pod diese ComputeClass auswählt und Spot-VMs in einem Knotenselektor auswählt, kann GKE den Pod nicht planen, da die ComputeClass und der Knotenselektor 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 den Einstellungen für aktive Migration und Autoscaling 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 zu bevorzugter 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, testen Sie die Änderungen in einer Staging-Umgebung. Sie können auch Anmerkungen verwenden, um kritische Arbeitslasten während der Skalierung vor dem Entfernen zu schützen.

ComputeClass-CRD-Updates vor Clusterupgrades testen

GKE aktualisiert regelmäßig die ComputeClass-CustomResourceDefinition (CRD), 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 Nebenversionen 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 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 eine Pod-Entfernung während der aktiven Migration gegen dieses Budget verstößt, entfernt GKE den Pod nicht. Geben Sie PodDisruptionBudgets für Arbeitslasten wie die folgenden an:

  • Zustandslose Arbeitslasten wie Inferenz-Deployments.
  • 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 nichtflüchtige Daten angewiesen sind. Geben Sie ein Budget an, das ein Gleichgewicht zwischen der Verfügbarkeit der Arbeitslast und der Möglichkeit zum Abschließen von Funktionen wie Upgrades bietet.

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 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" Anmerkung hinzu. Diese Anmerkung verhindert, dass GKE Pods während des Autoscalings entfernt. Verwenden Sie diese Anmerkung, um Pods zu schützen, die keine Unterbrechungen vertragen, z. B. zustandsorientierte Arbeitslasten mit einer einzelnen Instanz und Batchjobs mit langer Ausführungszeit.

Zusammenfassung der Best Practices

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

Nächste Schritte