Kubernetes v1.35: Was ist neu und verbessert?

Kubernetes v1.35: Stable-Features

1. In-Place-Update von Pod-Ressourcen****

Feature Group: SIG Node | KEP: #1287

In Kubernetes v1.35 haben In-Place-Updates der CPU- und Speicherressourcen von Pods den Status General Availability (GA) erreicht.

Vor diesem Feature mussten Sie den Pod jedes Mal neu erstellen, wenn Sie .spec.resources.requests oder .spec.resources.limits geändert haben. Kubernetes behandelte Ressourcenänderungen als unveränderliche Felder, sodass selbst eine kleine CPU- oder Speicheranpassung einen vollständigen Neustart auslöste. Für Stateful-Services, lang laufende Batch-Jobs und latenzsensitive Anwendungen war das äußerst störend. Außerdem führte es zu Ausfallzeiten.

Mit v1.35 können Sie die CPU- und Speicher-Requests oder -Limits eines laufenden Pods ändern, ohne den Pod oder seine Container neu starten zu müssen. Ressourcenänderungen lassen sich jetzt direkt auf den laufenden Container anwenden, sofern Runtime und Node-Konfiguration dies unterstützen. Das kubelet aktualisiert die cgroup-Einstellungen an Ort und Stelle, und der Pod läuft einfach weiter. Kann eine Ressourcenänderung nicht sicher angewendet werden, greift Kubernetes weiterhin auf die Neuerstellung des Pods zurück – die Abwärtskompatibilität bleibt erhalten. Das macht vertikales Skalieren einfacher, sicherer und effektiver.

2. PreferSameNode Traffic Distribution

Feature Group: SIG Network | KEP:#3015

In Kubernetes v1.35 hat die PreferSameNode-Traffic-Verteilung General Availability (GA) erreicht.

Vor dieser Änderung gab es in Kubernetes die Option PreferClose im Feld trafficDistribution. Sie war hilfreich, aber nicht eindeutig. PreferClose bedeutete implizit "bevorzuge nahegelegene Endpoints", was in der Praxis Nähe auf Zonen-Ebene meinte, nicht auf Node-Ebene. Es gab keine klare Möglichkeit, eine strikte Node-lokale Präferenz auszudrücken, und die API kommunizierte den Unterschied zwischen Routing auf Node- und Zonen-Ebene nicht deutlich.

Mit v1.35 können Sie steuern, wohin Service-Traffic fließt. Kubernetes kann Endpoints stark bevorzugen, die auf demselben Node wie der Client-Pod liegen, und Remote-Endpoints nur dann verwenden, wenn keine lokalen verfügbar sind. Mit PreferSameNode wird eine neue Option eingeführt, die Endpoints auf demselben Node priorisiert. Gleichzeitig wird PreferClose in PreferSameZone umbenannt, wodurch die API selbsterklärend und klarer wird. PreferClose wird aus Gründen der Abwärtskompatibilität weiterhin unterstützt, aber PreferSameZone ist jetzt die bevorzugte und explizite Option für zonales Routing. Zusammen trennen diese Änderungen die Traffic-Präferenzen auf Node- und Zonen-Ebene klar voneinander. Das ist hilfreich für Workloads, bei denen Performance zählt und die Latenz sowie Node-übergreifenden Traffic reduzieren wollen.

apiVersion: v1
kind: Service
metadata:
  name: node-local-service
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 8080
  trafficDistribution: PreferSameNode

Mit dieser Konfiguration routet Kubernetes den Traffic lokal, wenn ein Client-Pod und ein passender Backend-Pod auf demselben Node laufen. Nur wenn keine lokalen Endpoints existieren, wird der Traffic an Pods auf anderen Nodes gesendet.

3. Konfigurierbares NUMA-Node-Limit für den Topology Manager

Feature Group: SIG Node | KEP:#4622

In Kubernetes v1.35 hat das konfigurierbare NUMA-Node-Limit des Topology Managers General Availability (GA) erreicht.

NUMA (Non-Uniform Memory Access) ist eine Hardware-Architektur, bei der ein Server in mehrere Speicherbereiche (NUMA-Nodes) unterteilt ist, die jeweils direkt an eine bestimmte Gruppe von CPUs angebunden sind. Der Topology Manager ist eine kubelet-Komponente, die CPU-, Speicher- und Gerätezuweisungen so ausrichtet, dass Workloads auf physisch nahe beieinanderliegender Hardware laufen.

Vor diesem Feature setzte Kubernetes ein hartes Limit von 8 NUMA-Nodes, sobald der Topology Manager aktiviert war. Diese Schutzmaßnahme sollte eine Zustandsexplosion bei der Berechnung der NUMA-Affinität verhindern. Auf Nodes mit mehr als 8 NUMA-Nodes deaktivierte das kubelet den Topology Manager daher vollständig. Diese Einschränkung bedeutete, dass Kubernetes große Multi-Socket-Server nicht ausnutzen konnte, bei denen präzise CPU-, Speicher- und Gerätelokalität für die Performance entscheidend ist.

Mit v1.35 ist die Policy-Option max-allowable-numa-nodes jetzt stabil. Kubernetes erlaubt Cluster-Administratoren, den Topology Manager auf Maschinen mit mehr als 8 NUMA-Nodes zu betreiben. Damit fällt die künstliche Obergrenze, und Kubernetes kann CPU-, Speicher- und Geräteplatzierung selbst auf sehr großen Maschinen koordinieren. Auch wenn bei extrem großen NUMA-Systemen weiterhin Performance-Herausforderungen bestehen, gibt Kubernetes Betreibern nun die Kontrolle, sich je nach Hardware- und Workload-Anforderungen bewusst dafür zu entscheiden.

Dieses Feature ermöglicht es Kubernetes also, moderne High-End-Server besser zu nutzen, wie sie häufig für HPC-, AI/ML-, Telekommunikations- und Low-Latency-Workloads eingesetzt werden.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
topologyManagerPolicy: restricted
topologyManagerScope: pod
topologyManagerPolicyOptions:
  max-allowable-numa-nodes: "true"

4. Neue CPUManager-Policy-Option zur Beschränkung von reservedSystemCPUs

Feature Group: SIG Node | KEP: #4540

Vor diesem Feature konnten Administratoren mit reservedSystemCPUs bestimmte CPUs für das System reservieren. Diese Reservierung wurde jedoch nur für Guaranteed-Pods mit ganzzahligen CPU-Requests durchgesetzt. Burstable- und BestEffort-Pods sowie Guaranteed-Pods mit fraktionalen CPU-Requests konnten weiterhin CPU-Zeit dieser reservierten Kerne verbrauchen. In realen Clustern führte das zu Noisy-Neighbor-Problemen, bei denen Anwendungs-Workloads Systemprozesse störten – mit der Folge von Node-Instabilität, Scheduling-Verzögerungen oder Performance-Einbußen unter Last.

Mit Kubernetes v1.35 ist die Option strict-cpu-reservation für die statische CPUManager-Policy jetzt General Availability (GA). Ist sie aktiviert, verhindert Kubernetes strikt, dass Pods – unabhängig von ihrer QoS-Klasse – auf den in reservedSystemCPUs aufgeführten CPUs laufen. Das macht die CPU-Isolation vorhersehbar und zuverlässig und stellt sicher, dass System-Daemons immer über dedizierte CPU-Kapazität verfügen. Das Ergebnis: stabilere Nodes und bessere Performance für latenzsensitive und durchsatzstarke Workloads, die neben kritischen Systemkomponenten laufen.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
cpuManagerPolicy: static
reservedSystemCPUs: "0-1"
cpuManagerPolicyOptions:
  strict-cpu-reservation: "true"

Mit dieser Konfiguration sind die CPUs 0-1 exklusiv für das Betriebssystem und die Kubernetes-System-Daemons reserviert. Kein Anwendungs-Pod – ob BestEffort, Burstable oder Guaranteed – kann auf diesen CPUs laufen.

5. Kubelet-Limit für parallele Image-Pulls

Feature Group: SIG Node | KEP: #3673

Das kubelet-Limit für parallele Image-Pulls steuert, wie viele Container-Images ein Node gleichzeitig herunterladen darf. Das Pullen von Images ist eine netzwerk- und festplattenintensive Operation.

Vor diesem Feature war das kubelet-Verhalten faktisch binär. War serializeImagePulls auf true gesetzt, wurden Images nacheinander gepullt – das vermied Ressourcenkonflikte, verlangsamte aber den Pod-Start bei Scale-ups oder Node-Neustarts erheblich. War serializeImagePulls auf false gesetzt, gab es keine Obergrenze für parallele Image-Pulls. Auf stark ausgelasteten Nodes konnte das das Netzwerk fluten, die Festplatten auslasten und andere kritische Operationen auf dem Node verzögern.

Mit Kubernetes v1.35 ist die Einstellung maxParallelImagePulls jetzt General Availability (GA). Administratoren können damit eine explizite Obergrenze für gleichzeitige Image-Pulls festlegen. Kubernetes kann nun mehrere Images parallel pullen – aber nur bis zu einem sicheren, vom Betreiber definierten Limit. Weitere Image-Pulls werden in eine Warteschlange gestellt, bis ein laufender Pull abgeschlossen ist. Das sorgt für kontrollierte Parallelität statt Alles-oder-nichts-Verhalten.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
serializeImagePulls: false
maxParallelImagePulls: 3

Mit dieser Konfiguration erlaubt das kubelet, dass auf einem Node bis zu drei Images gleichzeitig gepullt werden.

6. Kubelet Image Garbage Collection nach maximalem Alter

Feature Group: SIG Node | KEP:#4210

Vor diesem Feature wurde die Image Garbage Collection des kubelet in erster Linie über Schwellenwerte für die Festplattennutzung gesteuert. Images wurden nur entfernt, wenn die Festplattennutzung HighThresholdPercent überschritt, und die Bereinigung lief, bis die Nutzung unter LowThresholdPercent fiel. Das verhinderte zwar effektiv volllaufende Festplatten, bedeutete aber auch, dass selten genutzte oder veraltete Images unbegrenzt auf der Festplatte verbleiben konnten, solange der Node nicht unter Disk-Pressure stand. Mit der Zeit führte das zu aufgeblähten Image-Caches und ineffizienter Festplattennutzung.

Mit Kubernetes v1.35 ist die Einstellung imageMaximumGCAge jetzt stabil. Das kubelet kann damit Images per Garbage Collection entfernen, die für eine bestimmte Dauer nicht genutzt wurden – unabhängig von der Festplattennutzung. Administratoren können ein maximales Alter für ungenutzte Images als Zeitspanne definieren. Überschreitet ein Image dieses Alter, ohne genutzt zu werden, kommt es für die Löschung infrage. Das ergänzt die bestehende festplattenbasierte GC und macht die Image-Bereinigung proaktiv statt reaktiv.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
imageMaximumGCAge: 24h
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 70

Mit dieser Konfiguration kann das kubelet jedes Container-Image entfernen, das 24 Stunden lang nicht genutzt wurde – selbst wenn die Festplattennutzung unter dem oberen Schwellenwert liegt.

7. managedBy-Mechanismus der Job-API

Feature Group: SIG Apps | KEP:#4368

Vor diesem Feature wurde jedes Job-Objekt immer vom integrierten Job-Controller abgeglichen. Selbst wenn ein externes System (etwa ein Custom Controller oder ein Multi-Cluster-Scheduler) Ausführung oder Status verwalten wollte, erstellte Kubernetes weiterhin Pods, aktualisierte Job-Conditions, wiederholte fehlgeschlagene Versuche und setzte die Completion-Semantik durch. Fortgeschrittene Anwendungsfälle wie das Spiegeln von Jobs über Cluster hinweg erforderten daher Annotations, Controller-Workarounds oder Unterdrückungslogik, um Konflikte zu vermeiden.

Mit Kubernetes v1.35 ist das Feld managedBy jetzt General Availability (GA). Ist es gesetzt, behandelt Kubernetes den Job als extern verwaltet und gleicht weder seine Pods noch seinen Status ab. Das ermöglicht Systeme wie MultiKueue, bei denen ein Job in einem Management-Cluster erstellt, in einem Worker-Cluster ausgeführt und der Status zurücksynchronisiert wird – ohne Eingriffe des nativen Job-Controllers. Das Feature ist bewusst begrenzt: Es ermöglicht die Delegation der Job-Verwaltung, ändert aber weder die Job-Semantik noch das CronJob-Verhalten und übergibt auch keine Konfiguration an den externen Controller.

apiVersion: batch/v1
kind: Job
metadata:
  name: delegated-job
spec:
  managedBy: kueue.x-k8s.io/multikueue
  ........

8. Pod Generation (zuverlässiges Tracking von Pod-Updates)

Feature Group: SIG Node | KEP: #5067

Vor diesem Feature besaßen Pods kein metadata.generation-Feld wie höherstufige Objekte, etwa Deployments oder StatefulSets. Controller konnten zwar die Spec eines Pods aktualisieren, aber es gab keine eingebaute, monotone Möglichkeit zu erkennen, ob das kubelet eine bestimmte Änderung bereits verarbeitet hatte. Dadurch war es schwierig, zuverlässig festzustellen, ob ein Pod-Update noch ausstand, teilweise angewendet oder vollständig im Status abgebildet war – insbesondere bei In-Place-Updates und schnellen, aufeinanderfolgenden Änderungen.

Mit Kubernetes v1.35 ist das Pod-Generation-Tracking jetzt General Availability (GA). Jeder Pod startet mit metadata.generation: 1, und jedes Update eines veränderbaren Felds in der Pod-Spec erhöht diesen Wert. Das kubelet vermerkt die von ihm verarbeitete Generation in status.observedGeneration. Damit wird explizit sichtbar, ob der aktuelle Status des Pods die neueste gewünschte Spec oder eine frühere Version widerspiegelt. Externe Controller können diese beiden Felder sicher vergleichen, um festzustellen, ob die Reconciliation abgeschlossen ist – ohne auf Timing oder Rätselraten angewiesen zu sein.

Kubernetes v1.35: Beta-Features

9. Konfigurierbare Toleranz für HorizontalPodAutoscaler

Feature Group: SIG Autoscaling | KEP: #4951

Der Horizontal Pod Autoscaler (HPA) passt die Anzahl der Pod-Replicas eines Workloads automatisch an – basierend auf beobachteten Metriken wie CPU- oder Speichernutzung.

Vor diesem Feature verwendete der HPA eine feste, clusterweite Toleranz von 10 %, um zu entscheiden, ob skaliert werden soll. Dieser Wert war nicht pro Workload konfigurierbar. Hochsensible Anwendungen konnten dadurch mitunter nicht skalieren, wenn sie auf kleine Lastanstiege reagieren mussten, während andere Workloads unnötiges Skalieren oder Oszillationen erlebten. Um dieses Verhalten anzupassen, musste ein globales Controller-Flag geändert werden – mit Auswirkungen auf jeden HPA im Cluster.

Mit Kubernetes v1.35 hat die konfigurierbare Toleranz den Beta-Status erreicht und ist standardmäßig aktiviert. Sie können Toleranzwerte jetzt pro HPA und pro Skalierungsrichtung über das behavior-Feld definieren. Das gibt Ihnen feingranulare Kontrolle über die Autoscaling-Sensitivität, ohne andere Workloads zu beeinflussen. Betreiber können kritische Services so tunen, dass sie aggressiv skalieren, während weniger sensible Workloads stabil bleiben.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleUp:
      tolerance: 0.05

Mit dieser Konfiguration skaliert der HPA nur dann hoch, wenn die CPU-Auslastung 65 % überschreitet (5 % über dem Zielwert).

10. Veränderbare Volume-Attach-Limits

Feature Group: SIG Storage | KEP:#4876

Volume-Attach-Limits legen fest, wie viele Storage-Volumes zu einem bestimmten Zeitpunkt an einen Node angehängt werden können. Kubernetes stützt sich auf diese Information, um zu entscheiden, wo Pods mit Persistent Volumes geplant werden. CSI-Treiber melden diese Limits über das CSINode-Objekt.

Vor diesem Feature war die in CSINode.spec.drivers[*].allocatable.count gemeldete Volume-Attachment-Kapazität statisch. Sobald ein CSI-Treiber sein Attach-Limit beim Start registriert hatte, ging Kubernetes davon aus, dass dieser Wert immer korrekt ist. Wurden später Volume-Slots verbraucht – durch externe Operationen, Node-Neustarts oder vorübergehende Fehler –, konnte der Scheduler weiterhin Pods auf Nodes platzieren, die keine Kapazität mehr hatten. Die Folge: Pods blieben in ContainerCreating hängen, weil das Volume tatsächlich nicht angehängt werden konnte.

Mit Kubernetes v1.35 ist das allocatable Volume-Attach-Limit jetzt veränderbar; das Feature ist Beta und standardmäßig aktiviert. CSI-Treiber können die verfügbare Attachment-Kapazität eines Nodes zur Laufzeit dynamisch aktualisieren. Kubernetes führt außerdem ein konfigurierbares Aktualisierungsintervall über das CSIDriver-Objekt ein, mit dem Treiber steuern können, wie häufig die allocatable Counts neu berechnet werden. Zusätzlich aktualisiert Kubernetes den allocatable Count automatisch, wenn es Attachment-Fehler aufgrund unzureichender Kapazität erkennt. Das macht Scheduling-Entscheidungen präziser und reduziert fehlgeschlagene oder hängende Pod-Starts erheblich.

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example.csi.storage
spec:
  attachRequired: true
  nodeAllocatableUpdatePeriodSeconds: 30  # Note: minimum is 10 seconds

Damit ruft das kubelet alle 30 Sekunden den NodeGetInfo-Endpoint des CSI-Treibers auf, um CSINode.spec.drivers[].allocatable.count zu aktualisieren.

11. Opportunistic Batching

Feature Group: SIG Scheduling | KEP: #5598

Opportunistic Batching ist eine Scheduler-Optimierung, die die Performance verbessert, wenn Kubernetes viele Pods mit identischen oder gleichwertigen Scheduling-Anforderungen plant.

Vor diesem Feature verarbeitete der kube-scheduler Pods einzeln, wobei die Scheduling-Komplexität proportional zur Anzahl der Pods multipliziert mit der Anzahl der Nodes war. Selbst wenn mehrere Pods aus Scheduling-Sicht identisch waren – gleiche Ressourcen-Requests, Affinitäten und Constraints –, wiederholte der Scheduler dieselben Filter- und Scoring-Berechnungen für jeden Pod. Das führte zu redundanter Arbeit und langsamem Scheduling, insbesondere bei Batch-Jobs, ML-Workloads und der Erstellung von Replicas in großem Maßstab.

Mit Kubernetes v1.35 wird Opportunistic Batching als Beta-Feature eingeführt und ist standardmäßig aktiviert. Der Scheduler berechnet jetzt eine Pod-Scheduling-Signatur, die alle scheduling-relevanten Aspekte eines Pods erfasst, einschließlich Pod-Specs, Node-Attributen und Cluster-Zustand. Treffen Pods mit derselben Signatur direkt nacheinander in der Scheduling-Queue ein, fasst der Scheduler sie zu einem Batch zusammen. Er cached die Scheduling-Ergebnisse des ersten Pods und verwendet sie für nachfolgende Pods mit derselben Signatur wieder – wiederholte Berechnungen entfallen. Der Cache ist kurzlebig und wird automatisch aktualisiert, um bei sich änderndem Cluster-Zustand Korrektheit sicherzustellen.

Diese Optimierung funktioniert transparent – es ist keine Benutzerkonfiguration erforderlich – und kommt vor allem Workloads mit vielen identischen Pods zugute, etwa Jobs, parallelen ML-Workern und großen Deployments. Durch die Reduzierung redundanter Scheduling-Arbeit kann Kubernetes Pods schneller platzieren und Workloads unter hoher Last effizienter skalieren.

12. maxUnavailable für StatefulSets

Feature Group: SIG Apps | KEP: #961

Ein StatefulSet verwaltet eine Gruppe von Pods, die stabile Identitäten, geordnetes Starten und Beenden sowie persistenten Storage benötigen.

Vor diesem Feature aktualisierten StatefulSets mit der RollingUpdate-Strategie Pods strikt nacheinander, beginnend mit der höchsten Ordinalzahl. Es gab keine Möglichkeit zu steuern, wie viele Pods während eines Updates nicht verfügbar sein dürfen. Selbst wenn eine Stateful-Anwendung mehrere vorübergehend ausgefallene Pods tolerieren konnte, erzwang Kubernetes serialisierte Updates – mit langen Rollout-Zeiten bei großen StatefulSets.

Mit Kubernetes v1.35 ist das Feld maxUnavailable für Rolling Updates von StatefulSets jetzt Beta und standardmäßig aktiviert. Betreiber können damit festlegen, wie viele Pods während eines Updates nicht verfügbar sein dürfen – entweder als absolute Zahl oder als Prozentsatz der Replicas. In Kombination mit podManagementPolicy: Parallel kann Kubernetes mehrere Pods gleichzeitig aktualisieren und dabei weiterhin Verfügbarkeitsvorgaben einhalten. Ohne explizite Angabe bleibt der Standardwert 1 – das bisherige Verhalten bleibt erhalten.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: database
spec:
  replicas: 10
  podManagementPolicy: Parallel
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 20%
      ........

13. Deployment-Status: Anzahl terminierender Replicas

Feature Group: SIG Apps | KEP: #3973

Ein Deployment verwaltet Rolling Updates und die Skalierung von Pods; sein Status wird von Betreibern und Automatisierung genutzt, um den Rollout-Fortschritt nachzuvollziehen.

Vor diesem Feature meldete der Deployment-Status nur Felder wie replicas, updatedReplicas, readyReplicas und availableReplicas. Terminierende Pods waren im Deployment-Status nicht explizit sichtbar. Dadurch war schwer zu erkennen, ob ein Deployment wirklich stabil war oder im Hintergrund noch Pods aufräumte. Betreiber und Controller mussten Pods manuell auflisten und nach deletionTimestamp filtern – fehleranfällig und ineffizient.

Mit Kubernetes v1.35 wurde das Feld status.terminatingReplicas auf Beta-Status angehoben und ist standardmäßig aktiviert (mit aktiviertem Feature Gate DeploymentReplicaSetTerminatingReplicas auf API-Server und Controller Manager). Dieses Feld meldet die Anzahl der Pods, die terminieren, aber noch nicht vollständig entfernt wurden. Das verbessert die Observability bei Rollouts und Scale-down-Ereignissen und legt die Grundlage für künftige Verbesserungen des Deployment-Verhaltens, etwa intelligentere Pod-Replacement-Policies, die den Shutdown-Fortschritt berücksichtigen.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
status:
  replicas: 5
  updatedReplicas: 5
  readyReplicas: 4
  availableReplicas: 4
  terminatingReplicas: 1
  ........

14. Node-Topology-Labels über die Downward API verfügbar machen

Feature Group: SIG Node | KEP:#4742

Node-Topology-Labels beschreiben, wo in der Infrastruktur ein Pod läuft, etwa die Region oder Availability Zone des Nodes.

Vor diesem Feature konnten Pods nicht direkt auf Node-Topologie-Informationen zugreifen. Workloads, die Zonen- oder Regionsdaten benötigten, mussten den Kubernetes-API-Server abfragen, auf Sidecars zurückgreifen oder zusätzliche RBAC-Berechtigungen erhalten. Das erhöhte die operative Komplexität und schuf Sicherheitsrisiken, weil Anwendungs-Pods mehr Berechtigungen bekamen, als sie tatsächlich brauchten.

Mit Kubernetes v1.35 werden Node-Topology-Labels jetzt in Pods injiziert und über die Downward API bereitgestellt – das Feature ist Beta und standardmäßig aktiviert. Das kubelet propagiert Standard-Labels wie topology.kubernetes.io/zone und topology.kubernetes.io/region vom Node zum Pod und stellt sie als Umgebungsvariablen oder projizierte Dateien zur Verfügung. Workloads werden so topologiebewusst, ohne API-Zugriff zu benötigen – das vereinfacht die Konfiguration und respektiert das Least-Privilege-Prinzip.

apiVersion: v1
kind: Pod
metadata:
  name: topology-aware-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "env"]
    env:
    - name: ZONE
      valueFrom:
        fieldRef:
          fieldPath: metadata.labels['topology.kubernetes.io/zone']
    - name: REGION
      valueFrom:
        fieldRef:
          fieldPath: metadata.labels['topology.kubernetes.io/region']

Mit dieser Konfiguration erhält der Pod automatisch Zone und Region des Nodes, auf dem er läuft.

Kubernetes v1.35: Alpha-Features

15. Gang-Scheduling-Unterstützung in Kubernetes

Feature Group: SIG Scheduling | KEP: #4671

Vor diesem Feature plante Kubernetes Pods einzeln. Für eng gekoppelte Workloads führte das zu partiellem Scheduling: Einige Pods starteten, während andere wegen Ressourcenknappheit auf Pending blieben. Solche teilweise geplanten Jobs konnten Deadlocks verursachen, Cluster-Ressourcen verschwenden und andere Workloads blockieren. Nutzer mussten daher auf externe Scheduler oder Custom Controller zurückgreifen, um Gang-Semantik durchzusetzen.

Mit Kubernetes v1.35 wird natives Gang Scheduling als Alpha-Feature eingeführt – auf Basis der neuen Workload-API und Pod-Group-Policies. Nutzer definieren einen Workload, der Pods gruppiert und eine minCount-Anforderung festlegt. Der Scheduler hält Pods zurück, bis die Gruppe vollständig ist, und versucht dann, sie gemeinsam zu platzieren. Kann er nicht mindestens die erforderliche Anzahl an Pods innerhalb eines Timeouts planen, wird keiner gebunden, und die Pods warten, bis ausreichend Ressourcen verfügbar sind. Damit erhält Kubernetes erstklassige Unterstützung für Gang-Semantik direkt auf Scheduler-Ebene.

Beispiel:

Workload, der eine Gang von Pods definiert

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: ml-training
spec:
  podGroups:
  - name: workers
    policy:
      gang:
        minCount: 4

Pod, der mit dem Workload verknüpft ist:

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
spec:
  workloadRef:
    name: ml-training
    podGroup: workers
  containers:
  - name: trainer
    image: <your-image>

Mit dieser Konfiguration plant Kubernetes die Pods nur, wenn mindestens vier Worker gemeinsam laufen können. Kann der Cluster diese Anforderung nicht erfüllen, wird keiner der Pods gestartet.

16. Erweiterte Toleration-Operatoren für schwellenwertbasierte Platzierung

Feature Group: SIG Scheduling | KEP: #5471

Taints und Tolerations steuern in Kubernetes, wo Pods laufen dürfen. Nodes signalisieren mit Taints "platziere hier keine Pods", und Pods erklären mit Tolerations "ich darf auf diesem Node laufen".

Vor diesem Feature unterstützten Tolerations nur einfache Operatoren wie Exists und Equal. Pods konnten einen Taint also entweder tolerieren oder nicht, aber keine Abstufungen der Toleranz ausdrücken. Ein Workload konnte zum Beispiel nicht sagen: "Laufe nur auf Nodes mit SLA ≥ 99,9" oder "Meide Nodes mit einer Zuverlässigkeit unter einem bestimmten Schwellenwert." Cluster, die eine SLA-bewusste Platzierung wollten, mussten daher auf Custom Scheduler, mehrere Node-Pools oder komplexe Admission-Logik zurückgreifen.

Mit Kubernetes v1.35 erhalten Tolerations numerische Vergleichsoperatoren (etwa Größer-als- oder Kleiner-als-Semantik) und werden Teil des erweiterten Schedulings. Nodes können SLA-orientierte Taints bereitstellen (zum Beispiel Zuverlässigkeitswerte oder die Qualität der Fault Domain), und Pods können Tolerations angeben, die nur greifen, wenn der Taint-Wert des Nodes eine numerische Bedingung erfüllt. Kritische Workloads können so gezielt Nodes mit hohem SLA ansteuern, während Best-Effort-Workloads bewusst auf günstigerer Infrastruktur mit niedrigerem SLA laufen – das verbessert die Auslastung, ohne die Zuverlässigkeit zu opfern.

Node-Taint, der ein SLA-Level ausdrückt:

kubectl taint nodes node-a
servicelevel.org.example/agreed-service-level=800:NoSchedule

Pod, der nur Nodes mit ausreichendem SLA toleriert:

apiVersion: v1
kind: Pod
metadata:
  name: sla-tolerant-pod
spec:
  tolerations:
  - key: servicelevel.org.example/agreed-service-level
    operator: LessThan
    value: "900"
    effect: NoSchedule
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "echo running on lower-SLA node"]

Mit dieser Konfiguration wird der Pod nur auf Nodes geplant, deren SLA-Taint-Wert unter 900 liegt.

17. Veränderbare Container-Ressourcen bei suspendierten Jobs

Feature Group: SIG Apps | KEP: #5440

Ein Kubernetes-Job führt eine Aufgabe aus, bis sie erfolgreich beendet ist, und stellt ihren Abschluss sicher.

Vor diesem Feature war das Pod-Template innerhalb eines Jobs faktisch unveränderlich. Scheiterte ein Job an unzureichender CPU oder unzureichendem Speicher (zum Beispiel durch wiederholte OOM-Kills), hatten Nutzer keine Möglichkeit, die Ressourcenwerte am bestehenden Job anzupassen. Die einzige Option war, den Job zu löschen und einen neuen mit aktualisierten Ressourcen zu erstellen – und damit Job-Historie, Status und jegliches Tooling zu verlieren, das Fortschritt oder Retries verfolgte.

Mit Kubernetes v1.35 können bei Jobs im Suspended-Zustand die Ressourcen-Requests und -Limits der Container geändert werden, sofern das Feature Gate MutableJobPodResourcesForSuspendedJobs aktiviert ist. Nutzer können einen fehlschlagenden Job suspendieren, das Pod-Template mit passenden Ressourcenwerten aktualisieren und den Job anschließend fortsetzen. Kubernetes setzt die Ausführung mit der aktualisierten Konfiguration fort und bewahrt dabei Identität und Lifecycle-Zustand des Jobs – die Wiederherstellung nach falsch konfigurierten Ressourcen wird deutlich reibungsloser.

apiVersion: batch/v1
kind: Job
metadata:
  name: data-processor
spec:
  suspend: true
  template:
    spec:
      restartPolicy: OnFailure
      containers:
      - name: worker
        image: busybox
        command: ["sh", "-c", "echo processing && sleep 30"]
        resources:
          requests:
            cpu: "1"
            memory: "1Gi"
          limits:
            cpu: "2"
            memory: "2Gi"

Nach der Aktualisierung der Ressourcen kann der Job fortgesetzt werden, indem spec.suspend auf false gesetzt wird. Der Job läuft mit den neuen CPU- und Speicherwerten weiter, ohne dass er gelöscht oder neu erstellt werden muss.

18. Node Declared Features vor dem Scheduling

Feature Group: SIG Node | KEP: #5328

Vor diesem Feature ging Kubernetes davon aus, dass Nodes innerhalb des unterstützten Versions-Skews weitgehend mit der Control Plane kompatibel sind. Wurden neue Features auf Control-Plane-Ebene aktiviert, konnte der Scheduler Pods, die diese Features nutzen, dennoch auf ältere Nodes platzieren, die sie noch nicht unterstützten. Das führte zu Laufzeitfehlern, subtilem Fehlverhalten oder Pods, die nach dem Scheduling hängen blieben – obwohl die Platzierungsentscheidung an sich gültig erschien.

Mit Kubernetes v1.35 führt ein Alpha-Feature einen formalen Mechanismus ein, mit dem Nodes ihre unterstützten Features über ein neues Feld status.declaredFeatures am Node-Objekt deklarieren. Ist das Feature aktiviert, veröffentlichen Nodes die Menge der Kubernetes-Features, die sie verstehen. Scheduler, Admission Controller und externe Komponenten können diese Information dann nutzen, um Pods zu validieren und das Scheduling auf kompatible Nodes zu beschränken – Feature-Skew-Probleme werden verhindert, bevor Pods gebunden werden.