Unser Kubernetes Release Review zu v1.34 „Of Wind & Will“

Ende August gab es wie gewohnt einen neuen Release des Kubernetes Projekts, und so schauen auch wir in unserem Kubernetes Release Review wieder auf die Neuerungen, Verbesserungen und wegfallenden Features in unserem liebsten Containerorchestrator.

Der neue Release Of Wind & Will betont hierbei, dass Kubernetes als Open Source Projekt vor Allem durch den Willen und die Motivation der vielen Beitragenden fortbesteht, egal ob mit oder ohne Gegenwind. So haben es auch dieses Mal wieder 58 Verbesserungen in den Release geschafft, darunter

• 23 Stable Enhancements
• 22 Beta Enhancements
• 13 Alpha Enhancements

Zusätzlich gibt es wie gewohnt auch wieder ein paar Ankündigungen von wegfallenden Features in zukünftigen Releases, doch dazu später mehr. Legen wir los!

Kubernetes Release Review: Unsere wichtigsten Stable Enhancements

Als Betreiber von NETWAYS Managed Kubernetes® sind für uns natürlich vor Allem neue Features relevant, die die Stabilität und Performanz von Kubernetes Clustern verbessern. Kubernetes v1.34 bringt hier gleich mehrere Verbesserungen in die Stable Kategorie, sodass wir und unsere Kunden in Zukunft davon profitieren können:

• Dynamic Resource Allocation ist einen guten Schritt weiter gekommen, und einige API Ressourcen sind nun stable, unter Anderem ResourceClaims, DeviceClasses, ResourceClaimTemplates und ResourceSlices. Mehr Informationen gibt es in KEP #4381.
• Die Löschung von Namespaces und darin enthaltenen Objekten erfolgt jetzt geordnet. Dadurch gehören sicherheitsrelevante Racing Conditions wie bspw. die Löschung von NetworkPolicies vor durch diese geschützte Workloads der Vergangenheit an. Mehr Informationen gibt es in KEP #5080.
• Die Abfrage von umfangreichen Auflistungen, bspw. von Pods oder CustomResources, sorgte bisher für großen Speicherverbrauch innerhalb des Kubernetes API-Servers. Durch das Streamen solcher Anfragen verringert sich die Last auf dem API-Server nun erheblich. Das Feature ist für JSON und das Kubernetes protobuf Format standardmäßig aktiv. Mehr Informationen gibt es in KEP #5116.
• Eine gelockerte DNS Search Path Validierung sorgt bei Anwendungen im Cluster nun dafür, dass nicht jede Anfrage zwangsweise durch die internen DNS-Server des Clusters laufen muss, sondern für externe Hostname direkt aufgelöst werden kann. Mehr Informationen gibt es in KEP #4427.
• Swap auf Linux Nodes ist nun stable und somit allgemein in Kubernetes v1.34 verfügbar. Hierdurch können Workloads mit variierenden, möglicherweise großem Speicherverbrauch besser gemanaged werden. Der kubelet Service auf den jeweiligen Clusternodes muss allerdings weiterhin entsprechend konfiguriert werden. Mehr Informationen gibt es in KEP #2400.

Beta Enhancements in Kubernetes v1.34

Zusätzlich zu den neuen Stable Enhancements in Kubernetes v1.34 gibt es auch wieder einige Features, die vorerst in eine Beta-Phase gehen. Darunter wollen wir in unserem Kubernetes Release Review besonders einige Quality-of-Life Funktionen für Clusteradministratoren und Endnutzer hervorheben:

• Resource Requests und Limits können in Kubernetes v1.34 auf Podebene statt auf Containerebene gesetzt werden. Hierdurch wird das Dilemma von potenzieller Überprovisionierung von Ressourcen oder aufwendigem Micromanagement gelöst, das für Pods bestehend aus mehreren Containern bisher oft notwendig war. Das gesetzte Ressourcenbudget eines Pods wird hierbei über alle Container geteilt, und Komponenten wie der Horizontal Pod Autoscaler (HPA) oder Scheduler können sich in ihren Entscheidungen auf dieses Budget beziehen. Mehr Informationen gibt es in KEP #2837.
• Eine neue Konfigurationsdatei für kubectl Nutzereinstellungen wurde durch .kuberc eingeführt. In dieser Datei können nun Standardeinstellungen und Befehlsaliase gepflegt werden, die bisher separat und manuell gehandhabt werden mussten. Mehr Informationen gibt es in KEP #3104.
• Mutating Admission Policies bieten in Kubernetes v1.34 eine neue, einfachere Möglichkeit für Administratoren, Admission Controls direkt in Kubernetes‘ API-Server vorzunehmen. Die Policies basieren hierbei auf CEL und JSON’s Patch Strategie. Mehr Informationen gibt es in KEP #3962.

Kubernetes Release Review: Neue Enhancements in der Alpha-Phase

Zu guter Letzt haben es natürlich auch einige brandneuen Features mit Kubernetes v1.34 in einen Alpha-Status geschafft, unter Anderem Kubernetes‘ neues YAML-Subset KYAML:

• KYAML ist ein für Kubernetes geschaffener YAML-Dialekt, der einem sichereren und eindeutigeren YAML-Subset entspricht. Hierbei wurden vor Allem bestehende Schwächen von YAML auf der einen Seite (bspw. der bekannte „Norway-Bug“ oder fehlerhafte Einrückung) und JSON auf der anderen Seite (bspw. fehlende Unterstützung von Kommentaren) berücksichtigt. KYAML kann als Ein- und Ausgabeformat bspw. für kubectl genutzt werden und entspricht jederzeit gültigem YAML. Ein Beispiel für KYAML-Syntax liefert folgender Befehl im Terminal. Mehr Informationen gibt es in KEP #5295.

KUBECTL_KYAML=true kubectl run kyaml-demo --image=nginx:latest --dry-run=client -o=kyaml
---
{
  kind: "Pod",
  apiVersion: "v1",
  metadata: {
    name: "kyaml-demo",
    labels: {
      run: "kyaml-demo",
    },
  },
  spec: {
    containers: [{
      name: "kyaml-demo",
      image: "nginx:latest",
      resources: {},
    }],
    restartPolicy: "Always",
    dnsPolicy: "ClusterFirst",
  },
  status: {},
}

KUBECTL_KYAML=true kubectl run kyaml-demo --image=nginx:latest --dry-run=client -o=kyaml
---
{
  kind: "Pod",
  apiVersion: "v1",
  metadata: {
    name: "kyaml-demo",
    labels: {
      run: "kyaml-demo",
    },
  },
  spec: {
    containers: [{
      name: "kyaml-demo",
      image: "nginx:latest",
      resources: {},
    }],
    restartPolicy: "Always",
    dnsPolicy: "ClusterFirst",
  },
  status: {},
}

• Der Restricted Pod Security Standard erlaubt in Kubernetes v1.34 keine remote Probes mehr. Hierdurch wird das Setzen des host Feldes in der Probe- oder Lifecyclekonfiguration eines Pods unterbunden, da dieser theoretisch auf einen beliebigen, von der jeweiligen podIP abweichenden Wert gesetzt werden könnte. Mehr Informationen gibt es in KEP #4940.
• Container Restart Rules innerhalb des selben Pods können in Kubernetes v1.34 voneinander abweichen. Bisher folgten alle Container der gleichen, auf Podebene in .spec.restartPolicy definierten Restart Rule. In Pods mit mehreren Containern (bspw. Init- und Workloadcontainern) ist in einigen Szenarien allerdings eine unterschiedliche Behandlung von Restarts sinnvoll. Dies kann nun durch das Featuregate ContainerRestartRules ermöglicht und konfiguriert werden. Mehr Informationen gibt es in KEP #5307.

In Kubernetes v1.34 angekündigte Deprecations

Neben vielen Neuerungen wurden in Kubernetes v1.34 auch wieder einige bestehende Features abgekündigt. Schließen wir unseren Kubernetes Release Review also damit ab:

• Manuelle Konfiguration von cgroup Treibern in der kubelet Konfiguration ist nun offiziell deprecated, nachdem in Kubernetes v1.28 eine Möglichkeit der automatischen Erkennung korrekter cgroup Treiber eingeführt wurde. Endgültigt entfernt wird das Feature nicht vor Kubernetes v1.36. Mehr Informationen gibt es in KEP #4033.
• containerd 1.x Support wird in Kubernetes v1.36 eingestellt. Sind containerd 1.7 und mehrere LTS-Versionen der Container-Runtime in Kubernetes v1.34 noch unterstützt, wird das ab Kubernetes v1.36 nicht mehr der Fall sein, und ein Wechsel auf containerd 2.x notwendig. Mehr Informationen gibt es in KEP #4033.

Das waren die Highlights unseres Kubernetes Release Reviews für Kubernetes v1.34 „Of Wind & Will“. Den ausführlicheren Release Blogpost auf der Projekt-Website von Kubernetes findest du hier.
Die kommenden Wochen werden wir selbstverständlich damit verbringen, Kubernetes v1.34 so schnell wie möglich auch in NETWAYS Managed Kubernetes® für euch zur Verfügung zu stellen – wie immer mit zertifizierter Konformität zum Upstream-Projekt und zertifiziertem Support durch unsere MyEngineers®.

Und in gut vier Monaten heißt es dann ja auch schon: Hallo, Kubernetes v1.35!