Das GKE-Feature, das die meisten Cluster noch nicht nutzen: Custom ComputeClasses

Ich sehe bei fast jedem GKE-Cluster-Review dasselbe Muster: eine lange Liste statischer Node-Pools, jeder an einen einzelnen Maschinentyp gebunden. Ein n2-standard-8-Pool für allgemeine Workloads, ein n2-highmem-16-Pool für die speicherhungrigen Services, ein Spot-Pool, den jemand letztes Jahr während einer Kostensenkungsinitiative angelegt hat, und vielleicht noch ein GPU-Pool. Workloads werden über nodeSelector, Taints, Tolerations und über Jahre gewachsene Node-Affinity-Regeln auf die Nodes verteilt.

Das funktioniert, bis sich etwas ändert – und meistens ist es eines von drei Dingen.

• Zonale Stockouts: In einer Zone wird Ihre gewählte Maschinenserie knapp. Der Cluster Autoscaler kann nur die konkreten Pools skalieren, die Sie ihm gegeben haben – Pods bleiben in Pending hängen, während benachbarte Maschinenfamilien in derselben Zone ungenutzt bereitstehen.

• Spot-Preemption-Fallen: Massive Spot-Preemptions verdrängen Workloads auf On-Demand-Fallback-Pools. Sobald die Kapazität zurückkehrt, migriert nichts die Workloads aktiv zurück – die geplanten Einsparungen tauchen auf der Rechnung nie auf.

• Generationswechsel: Der Umstieg von N2 auf N4 oder C4 wird zum wochenlangen operativen Kraftakt: neue Pools provisionieren, Helm-Values in Dutzenden Repositories aktualisieren, alte Nodes drainen und hoffen, dass kein Manifest alte Labels hartkodiert hat.

GKE hat auf alle drei Probleme schon länger eine Antwort: Custom ComputeClasses. Die Kunden, mit denen ich spreche, haben entweder noch nie davon gehört oder gehen davon aus, dass es sie nur in Autopilot gibt. Das stimmt nicht. Custom ComputeClasses stehen ab GKE 1.30.3-gke.1451000 sowohl im Autopilot- als auch im Standard-Modus zur Verfügung und sind in allen geeigneten Clustern standardmäßig aktiviert.

Nennenswerte Neuerungen

Das Feature hat sich über die letzten GKE-Minor-Versionen schnell weiterentwickelt. Diese Änderungen sollte jeder kennen, der sich ComputeClasses vor einem Jahr angesehen und wieder beiseitegelegt hat.

Gewichtete Prioritäts-Scores (ab 1.35.2-gke.1842000)

Statt sich nur auf die Listenreihenfolge zu verlassen, können Regeln einen expliziten priorityScore von 1 bis 1000 definieren. Dabei gilt: alles oder nichts – entweder hat jede Regel in der Klasse einen Score oder keine. Bis zu drei Regeln können sich einen Score teilen; GKE wertet gleichauf liegende Regeln gemeinsam aus und lässt den Cluster Autoscaler zwischen ihnen wählen.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: priority-rule-score-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: e2
    spot: true
    priorityScore: 30
  - machineFamily: n2
    spot: true
    priorityScore: 20
  - machineFamily: t2d
    spot: true
    priorityScore: 20
  - machineFamily: n1
    spot: true
    priorityScore: 10
  whenUnsatisfiable: ScaleUpAnyway

Hier gelten N2- und T2D-Spot als gleichwertige zweite Wahl. Gruppierte Regeln können die Autoscaling-Latenz erhöhen – bei breiten machineFamily-Regeln stärker als bei engen machineType-Regeln, weil GKE mehr Simulationen durchrechnen muss.

Automatische Storage-Auswahl (ab 1.35.3-gke.1290000)

Das Mischen von Maschinengenerationen barg bisher ein Storage-Risiko, weil jede Serie bestimmte Disk-Typen unterstützt (N4 unterstützt z. B. Hyperdisk, während N2 auf Standard-PDs setzt). Jetzt können Sie eine StorageClass mit automatischer Disk-Typ-Auswahl verwenden: GKE erstellt dann einen Disk-Typ, der zu dem Maschinentyp passt, auf dem der Pod landet. Das macht generationsübergreifende Fallback-Ketten für Workloads mit dynamischem Provisioning deutlich sicherer. Bereits vorhandene Disks brauchen weiterhin einen Disk-Typ, den jede Maschinenserie in der Klasse unterstützt.

Custom Machine Shapes (ab 1.33.2-gke.1111000)

Sie können benutzerdefinierte Shapes wie n4-custom-8-20480 direkt in machineType definieren – für Workloads, deren CPU-zu-Speicher-Verhältnis nicht in die vordefinierten Shapes passt.

Boot-Disk-Einstellungen auf machineFamily-Regeln (ab 1.34.1-gke.1431000)

Definieren Sie storage.bootDiskType und storage.bootDiskSize auf flexiblen machineFamily-Regeln statt nur auf spezifischen machineType-Regeln:

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 100

Labels und Taints in der Klasse (1.33.2 bis 1.34.1)

Deklarieren Sie nodeLabels und taints pro Prioritätsregel (Labels ab 1.33.2-gke.1111000, Taints ab 1.33.4-gke.1350000) oder global unter nodePoolConfig (ab 1.34.1-gke.3084002). Werte auf Regelebene und globale Werte dürfen sich nicht überschneiden. So bleiben Labelling und Isolation im selben Objekt wie die Hardware-Entscheidung.

Default-Klassen für System-Workloads (ab 1.33.1-gke.1788000)

Namespaces können über das Label cloud.google.com/default-compute-class-non-daemonset eine Default-Klasse erhalten, die nur für Nicht-DaemonSet-Pods gilt. GKE nutzt das, um System-Pods in Namespaces wie kube-system und gmp-system getrennt von Ihren Workloads auszuführen, während DaemonSet-Pods den Klassen-Selektor nicht erhalten.

Autopilot-Compute neben einem eigenen Default (ab 1.34.1-gke.1829001)

Wenn Sie in einem Autopilot-Cluster eine Custom-Klasse als Cluster-Default setzen, laufen Pods nicht mehr standardmäßig auf der container-optimierten Autopilot-Plattform. Sie können die Autopilot-Compute-Plattform jetzt gezielt für einzelne Pods aktivieren, indem Sie diesen Pods den Node-Selektor cloud.google.com/compute-class: autopilot hinzufügen.

Ein paar kleinere Neuerungen

priorityDefaults (1.32.1-gke.1729000) erlaubt es, gemeinsame Werte einmal zu setzen, statt sie in jeder Regel zu wiederholen. nodeSystemConfig bringt kubelet- und sysctl-Tuning in die Klasse. Compact Placement und Workload Policies stehen für Autopilot ab 1.33.2-gke.1335000 zur Verfügung.

Fallstricke und Grenzfälle in der Produktion

ComputeClasses haben Grenzen – und die sollten Sie im Design-Review entdecken, nicht in der Produktion.

• kube-scheduler kennt die Prioritätsregeln nicht: ComputeClasses beeinflussen das Autoscaling, aber der kube-scheduler berücksichtigt sie nicht. Haben Fallback-Nodes bereits freie Kapazität, können neue Pods dort landen statt auf den bevorzugten Nodes. Mit aktiviertem activeMigration.optimizeRulePriority werden diese Fallback-Nodes mit der Zeit ersetzt, und ein strengerer consolidationThreshold sorgt dafür, dass unterausgelastete Fallback-Nodes früher gedraint werden.

• Änderungen wirken nur nach vorn: Das Bearbeiten einer ComputeClass ändert laufende Nodes nicht. Cordonen und drainen Sie bestehende Nodes in einem Wartungsfenster, damit sie nach den neuen Regeln ersetzt werden.

• Stateful Workloads von der aktiven Migration fernhalten: Die aktive Migration verdrängt Pods per Eviction und verschiebt keine Daten. Der Best-Practices-Leitfaden empfiehlt, sie für Klassen zu deaktivieren, die von Stateful Workloads genutzt werden. Packen Sie diese Workloads in eine eigene Klasse und nutzen Sie entweder die automatische Disk-Typ-Auswahl oder beschränken Sie die Klasse auf Maschinenserien, die Ihren Disk-Typ allesamt unterstützen.

• Namespace-Defaults migrieren bestehende Pods nicht: GKE injiziert den Klassen-Selektor nur in Pods, die nach dem Labeln des Namespace erstellt werden – bereits laufende Pods bleiben unangetastet. Starten Sie die Workloads im Namespace nach dem Setzen eines Defaults neu, damit neu erstellte Pods den Selektor und die aktive Migration übernehmen. Ein Cluster-weiter Default kann bestehende Pods direkt migrieren.

• Vorsicht bei hoher Pod-Fluktuation: In Clustern mit sehr hohen Pod-Erstellungs- und -Löschraten schafft es der Cluster Autoscaler unter Umständen nicht, niedrigere Regeln auszuwerten, bevor der Backoff der höheren Regeln abläuft – Pods bleiben in Pending. Wenn Sie auf diesen Grenzfall stoßen, reduzieren Sie die Konsolidierungsfrequenz oder deaktivieren Sie die aktive Migration.

• Fallback-Verhalten bei Reservierungen: Mit AnyBestEffort versucht GKE, wenn keine passende Reservierung Kapazität hat, zunächst einen On-Demand-Node für dieselbe Regel, bevor es zur nächsten Regel weitergeht. Soll bei voller reservierter Kapazität direkt die nächste Regel greifen, nutzen Sie affinity: Specific (für benannte Reservierungen) oder affinity: AnyThenFail.

Kleinere Einschränkungen

Ein Workload kann nur eine ComputeClass selektieren, und jeder manuell erstellte Node-Pool kann nur zu einer gehören. In Autopilot unterstützt bootDiskType nur pd-balanced. Klassennamen dürfen nicht mit gke oder autopilot beginnen. Viele der genannten Features setzen aktuelle Patch-Versionen voraus – prüfen Sie also Ihren Release-Channel, bevor Sie Ihr Design darauf aufbauen.

Fazit

Wenn Ihre Cluster noch auf festen, an Maschinentypen gebundenen Node-Pools laufen, starten Sie mit einem zustandslosen Namespace. Geben Sie ihm eine Spot-first-Fallback-Kette und beobachten Sie, wie oft Pods auf den Fallback-Regeln landen und ob die aktive Migration sie zurückholt.

Behalten Sie dabei im Kopf: Eine ComputeClass entscheidet, welche Art von Node erstellt wird – die Node-Größe hängt jedoch von den Resource-Requests Ihrer Pods ab. Bei machineFamily-Regeln wählt der Cluster Autoscaler die Maschinengröße anhand der aggregierten Requests der pending Pods. Überdimensionierte Requests bedeuten größere Maschinen, schlechteres Bin Packing und mehr Kapazität auf Fallback-Nodes.

Genau hier zahlt sich Right-Sizing aus. PerfectScale dimensioniert Workload-Requests kontinuierlich richtig, sodass die Nodes, die Ihre ComputeClasses erstellen, dem tatsächlichen Bedarf Ihrer Pods entsprechen. Das Feature Node Recommendations hilft Ihnen, die kosteneffizientesten Maschinenfamilien für Ihre Prioritätsregeln auszuwählen. Wenn Sie Ihre Cluster-Ausgaben prüfen und sehen möchten, wie sich solche Fallback-Setups in der Praxis schlagen, buchen Sie eine Demo mit dem Team.

Referenzen

• Über GKE ComputeClasses
• Über Custom ComputeClasses
• Über integrierte ComputeClasses
• ComputeClasses standardmäßig auf Pods anwenden
• Best Practices für ComputeClasses
• PerfectScale-Dokumentation