--- title: "Kubernetes 1.34 End of Life: Was EKS-Teams jetzt tun müssen – bevor AWS die Kontrolle übernimmt" description: Kubernetes 1.34 End of Life trifft EKS am 2. Dezember 2026. Extended Support kostet 0,60 $/h – und der Auto-Upgrade kommt ohne Vorwarnung. Jetzt lesen. image: https://dmoove.com/hubfs/blog/agent-images/kubernetes-1-34-end-of-life-eks-featured-040109.png --- [Zum Inhalt springen](https://dmoove.com/blog/kubernetes-1-34-end-of-life-eks#main-content) [![DMoove](https://dmoove.com/hubfs/raw_assets/public/dmoove-2026/images/logo.svg)](https://dmoove.com/) Menü - Leistungen - [AWS Landing Zone](https://dmoove.com/aws-landing-zone) - [Kubernetes auf AWS](https://dmoove.com/kubernetes-auf-aws) - [European Sovereign Cloud](https://dmoove.com/european-sovereign-cloud) - [Amazon Quick & KI](https://dmoove.com/amazon-quick-ki) - [Migration & DevOps](https://dmoove.com/migration-devops) - Lösungen - [GuardAudit](https://dmoove.com/dmoove-guardaudit) - [Cloud Kosten optimieren](https://dmoove.com/cloud-kosten-optimieren) - [EC2 Image Builder](https://dmoove.com/ec2-image-builder) - [Case Study](https://dmoove.com/case-study-kubernetes-cluster) - [Über uns](https://dmoove.com/ueber-uns) - [Blog](https://dmoove.com/blog) [Termin buchen](https://dmoove.com/meetings/yannick-tresch) 1. [Blog](https://dmoove.com/blog) 2. [Cloud Computing](https://dmoove.com/blog/tag/cloud-computing) Cloud Computing # Kubernetes 1.34 End of Life: Was EKS-Teams jetzt tun müssen – bevor AWS die Kontrolle übernimmt [Yannick Tresch](https://dmoove.com/blog/author/yannick-tresch) 26\. Oktober 2026 · Min. Lesezeit ![Uhr kurz vor Mitternacht auf einem Server-Rack – symbolisiert das bevorstehende Kubernetes 1.34 End of Life auf EKS](https://dmoove.com/hs-fs/hubfs/blog/agent-images/kubernetes-1-34-end-of-life-eks-featured-040109.png?width=1200&height=750&name=kubernetes-1-34-end-of-life-eks-featured-040109.png) Am 27. Oktober 2026 stellt das Kubernetes-Projekt jegliche Patches für Version 1.34 ein. Wer einen EKS-Cluster auf 1.34 betreibt, hat damit noch nicht unmittelbar ein Problem – aber die Uhr tickt lauter, als viele Teams gerade wahrnehmen. Das **Kubernetes 1.34 End of Life** auf EKS folgt einem eigenen Kalender und wer ihn nicht kennt, riskiert entweder eine unerwartete Rechnung oder einen unkontrollierten Zwangsupgrade durch AWS. ## Zwei Uhren, eine Frist ![Zwei Uhren nebeneinander mit unterschiedlichen Zeigerpositionen – symbolisiert die unterschiedlichen Support-Fristen von Upstream Kubernetes und Amazon EKS](https://dmoove.com/hubfs/blog/agent-images/kubernetes-1-34-end-of-life-eks-inline-040121.png) Das Kubernetes-Projekt und Amazon EKS laufen auf unterschiedlichen Zeitplänen. Upstream – also das Kubernetes-Projekt selbst – hat Version 1.34 am 27. August 2026 in den Maintenance-Modus versetzt. Seitdem werden nur noch kritische Sicherheitslücken gepatcht. Der letzte reguläre Patch, [1.34.12, erschien am 15. September 2026](https://kubernetes.io/hi/releases/1.34/). Am 27. Oktober 2026 endet auch dieser minimale Support vollständig. Für EKS-Cluster gelten andere Daten. [Laut AWS-Dokumentation](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) endet der Standard-Support für Kubernetes 1.34 auf EKS am **2. Dezember 2026**. Danach beginnt automatisch der Extended Support – sofern die Cluster-Upgrade-Policy auf `EXTENDED` gesetzt ist, was seit einiger Zeit der Standard für neue und bestehende Cluster ist. Der Extended Support läuft bis zum **2. Dezember 2027**. Die Konsequenz: Zwischen dem 27. Oktober und dem 2. Dezember 2026 läuft ein EKS-1.34-Cluster auf einer Kubernetes-Version, für die es upstream keine Sicherheitspatches mehr gibt – aber EKS hält den Cluster noch am Laufen und berechnet noch keine Aufschläge. Das Risikoprofil erhöht sich allerdings. ## Was passiert, wenn Sie nichts tun Ab dem 2. Dezember 2026 wechselt EKS automatisch in den Extended Support. Der Preis ändert sich damit von **0,10 USD auf 0,60 USD pro Cluster-Stunde** – ein Faktor sechs. Bei einem einzelnen Cluster summiert sich das auf rund 438 USD pro Monat allein für den Versions-Aufschlag, bevor eine einzige Workload-Ressource berechnet wird. Wer mehrere Cluster betreibt, multipliziert entsprechend. Das ist noch der kontrollierbare Fall. Wer die Upgrade-Policy auf `STANDARD` gesetzt hat oder wer den Extended Support bis zum 2. Dezember 2027 nicht selbst beendet, erlebt den eigentlichen Schock: [AWS dokumentiert explizit](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html), dass der automatische Upgrade des Control Planes „jederzeit erfolgen kann" und dass „Sie keine Benachrichtigung vor dem Update erhalten". Der Zwangsupgrade betrifft dabei nur den Control Plane – Managed Node Groups, Self-Managed Nodes und Add-ons bleiben auf der alten Version und erzeugen damit einen Versions-Skew, der eigene Probleme mitbringt. Die drei Stolpersteine auf dem Weg von 1.34 zu 1.37 EKS erlaubt nur einen Minor-Versionssprung pro Upgrade-Schritt. Von 1.34 nach 1.37 sind das drei separate Upgrades: 1.34 → 1.35 → 1.36 → 1.37. Jeder Schritt hat eigene Breaking Changes. Die drei folgenreichsten: ### 1. cgroup v1 – der harte Stopp in 1.35 Mit Kubernetes 1.35 wurde der Kubelet-Parameter `failCgroupV1` standardmäßig auf `true` gesetzt. [Laut Kubernetes-Blog](https://kubernetes.io/blog/2026/10/06/kubernetes-cgroups-v2-shift/) bedeutet das: Ein Kubelet startet auf einem Node, der noch cgroup v1 verwendet, schlicht nicht mehr. Kein Soft-Warning, kein Fallback – der Node bleibt offline. Wer noch ältere Linux-Distributionen oder AMIs ohne cgroup-v2-Unterstützung einsetzt, muss diese vor dem Upgrade auf 1.35 migrieren. Den aktuellen cgroup-Modus eines Nodes prüft man mit: ``` stat -fc %T /sys/fs/cgroup/ ``` Gibt der Befehl `tmpfs` zurück, läuft der Node noch auf cgroup v1 und muss vor dem Upgrade auf 1.35 migriert werden. Gibt er `cgroup2fs` zurück, ist der Node bereit. **Hinweis für EKS-Nutzer:** EKS-optimierte Amazon-Linux-2023-AMIs und Bottlerocket nutzen cgroup v2. Amazon Linux 2 AMIs werden für 1.34 bereits nicht mehr bereitgestellt – wer noch AL2 einsetzt, muss ohnehin migrieren. ### 2. containerd 1.x – das letzte Mal in 1.35 [Kubernetes 1.35 ist die letzte Version, die containerd 1.x unterstützt.](https://kubernetes.io/blog/2025/11/26/kubernetes-v1-35-sneak-peek/) Ab 1.36 ist containerd 1.x nicht mehr kompatibel. EKS-optimierte AMIs für 1.34 liefern bereits containerd 2.1 aus – wer aber Self-Managed Nodes mit eigenen AMIs betreibt, sollte die containerd-Version vor dem Upgrade auf 1.36 prüfen: ``` kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}' ``` Alles, was mit `containerd://1.` beginnt, muss auf 2.x aktualisiert werden, bevor der Cluster auf 1.36 gehoben wird. ### 3. Entfernte Feature Gates und Kubelet-Flags in 1.37 Der Sprung von 1.36 auf 1.37 entfernt laut Release Notes 25 Feature Gates und 18 Kubelet-Flags. Wer diese in Launch Templates, Karpenter-NodeClasses oder eigenen Kubelet-Konfigurationen gesetzt hat, wird beim Node-Start Fehler sehen. Außerdem wurde in 1.37 kube-dns zugunsten von CoreDNS formal abgekündigt – wer noch kube-dns betreibt, muss vor Kubernetes 1.40 migrieren. ## Vor dem Upgrade: EKS Upgrade Insights und kubent Bevor Sie den Control Plane anfassen, sollten zwei Scans abgeschlossen sein. **EKS Upgrade Insights** ist der zuverlässigste Einstiegspunkt. AWS scannt die Audit-Logs des Clusters auf veraltete API-Versionen und meldet Upgrade-Blocker direkt in der Konsole unter *Cluster → Upgrade Insights*. Per CLI: ``` aws eks list-insights \ --cluster-name mein-cluster \ --filter 'statuses=ERROR,WARNING' ``` Ein `ERROR`-Status bedeutet: Diese API-Version wird nach dem Upgrade abgelehnt. Das muss vor dem Upgrade behoben sein. AWS scannt dabei ein 30-Tage-Fenster der Audit-Logs – ein Insight verschwindet erst, wenn 30 Tage lang keine veraltete API mehr aufgerufen wurde. **kubent** (kube-no-trouble) ergänzt den Scan auf Helm-Release-Manifeste, die EKS Upgrade Insights nicht erfasst: ``` kubent ``` Typische Kandidaten sind veraltete `policy/v1beta1`-PodDisruptionBudgets, alte HorizontalPodAutoscaler-Versionen und Ingress-Ressourcen aus älteren Helm-Charts. Wer Ingress NGINX betreibt, sollte außerdem wissen: Das Projekt wurde am 24. März 2026 eingestellt – keine neuen Releases, keine Sicherheitspatches. Der Upgrade ist ein guter Zeitpunkt, die Migration zu Gateway API zu planen. ## Die richtige Reihenfolge Die Reihenfolge beim EKS-Upgrade ist nicht optional. Wer sie nicht einhält, riskiert Versions-Skew zwischen Control Plane und Nodes, der schwer zu debuggen ist: - **Control Plane zuerst** – per Konsole, eksctl oder Terraform. Der Upgrade dauert 15–30 Minuten; er lässt sich nicht pausieren, aber innerhalb von 7 Tagen zurückrollen. - **EKS-verwaltete Add-ons danach** – VPC CNI, CoreDNS, kube-proxy und EBS CSI Driver müssen auf die für die neue Version empfohlene Version gebracht werden, bevor die Nodes aktualisiert werden. - **Node Groups zuletzt** – Managed Node Groups können mit Rolling Update oder Surge aktualisiert werden. Self-Managed Nodes und Karpenter-Nodes müssen manuell ersetzt werden. Wer von 1.34 direkt auf 1.37 möchte, durchläuft diese Sequenz dreimal. Das ist kein Nachmittagsprojekt, sondern dauert: Planen Sie mindestens ein Wartungsfenster pro Versionssprung und testen Sie jeden Schritt zuerst in einer Staging-Umgebung. Für Teams, die den Upgrade-Prozess automatisieren wollen, bietet sich eine eksctl-Konfigurationsdatei an, die den Zielzustand deklarativ beschreibt. Wie EKS-Cluster-Upgrades mit Rollback-Option funktionieren, haben wir in unserem Artikel [EKS Version Rollback: Kubernetes-Upgrades auf AWS endlich rückgängig machen](https://dmoove.com/blog/eks-version-rollback-kubernetes-upgrade) beschrieben. Die neuen EKS-Fähigkeiten, die den Upgrade-Prozess vereinfachen – darunter Managed Argo CD und ACK – sind in [EKS Capabilities: Managed Argo CD, ACK und kro im Überblick](https://dmoove.com/blog/eks-capabilities-platform-engineering) zusammengefasst. ## Was jetzt zu tun ist Fünf Schritte, die sich in dieser Woche erledigen lassen: - **Alle Cluster inventarisieren.** `aws eks list-clusters` über alle Accounts und Regionen. Für jeden Cluster die aktuelle Version und die Upgrade-Policy prüfen: `aws eks describe-cluster --name --query 'cluster.upgradePolicy'`. - **EKS Upgrade Insights auswerten.** Alle Cluster mit Kubernetes-Version 1.34 auf ERROR- und WARNING-Insights prüfen. Blocker dokumentieren und Tickets erstellen. - **cgroup-Modus aller Nodes prüfen.** Nodes mit cgroup v1 identifizieren und den Migrationspfad auf cgroup v2 festlegen, bevor der Upgrade auf 1.35 angesetzt wird. - **containerd-Versionen prüfen.** Nodes mit containerd 1.x identifizieren – diese müssen vor dem Upgrade auf 1.36 auf containerd 2.x aktualisiert werden. - **Upgrade-Fenster im Kalender blockieren.** Drei Versionssprünge, drei Wartungsfenster. Wer bis Ende November 2026 auf 1.35 ist, hat noch ausreichend Zeit, den Rest kontrolliert durchzuführen, bevor der Extended-Support-Aufschlag ab 2. Dezember 2026 greift. Ob sich ein direkter Sprung auf 1.37 lohnt oder ob 1.35 als Zwischenziel sinnvoller ist, hängt von der Workload und den vorhandenen Breaking Changes ab. Was sich pauschal sagen lässt: Wer den Upgrade-Zeitpunkt selbst wählt, hat ein 7-Tage-Rollback-Fenster. Wer ihn AWS überlässt, hat keines. Yannick Tresch In diesem Artikel Fragen zu Ihrer Plattform? 30 Minuten, direkt mit dem Gründer. [Termin buchen](https://dmoove.com/meetings/yannick-tresch) Weiterlesen ## Weitere Artikel. - ### [![Schematische Darstellung eines kontinuierlichen Cloud-Analyse-Kreislaufs mit vernetzten Knoten und Dokumenten-Icons – symbolisiert den AWS Well-Architected Agent](https://dmoove.com/hs-fs/hubfs/blog/agent-images/aws-well-architected-agent-preview-featured-040119.png?width=800&height=500&name=aws-well-architected-agent-preview-featured-040119.png) Cloud Computing AWS Well-Architected Agent: Kontinuierliche Cloud-Optimierung statt jährlichem Review 24\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/aws-well-architected-agent-cloud-optimierung) - ### [![Serverrack mit geöffnetem Einschub, aus dem ein Netz gleichzeitiger HTTP-Verbindungen strömt – symbolisch für Lambda Web Functions und Multi-Concurrency](https://dmoove.com/hs-fs/hubfs/blog/agent-images/lambda-web-functions-serverless-http-featured-040109.png?width=800&height=500&name=lambda-web-functions-serverless-http-featured-040109.png) Cloud Computing Lambda Web Functions: AWS startet einen neuen Serverless-Typ für HTTP-Workloads 15\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/lambda-web-functions-serverless-http) - ### [![Kalenderseite mit dem 2. Dezember, umkreist in Rot, neben drei ineinandergreifenden Zahnrädern mit Schloss-Symbol – symbolisch für die EU AI Act Dezember 2026 Compliance-Fristen](https://dmoove.com/hs-fs/hubfs/blog/agent-images/eu-ai-act-dezember-2026-neue-verbote-featured-205033.png?width=800&height=500&name=eu-ai-act-dezember-2026-neue-verbote-featured-205033.png) Cloud Computing EU AI Act Dezember 2026: Zwei neue Verbote und eine Kennzeichnungspflicht – was Unternehmen jetzt tun müssen 13\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/eu-ai-act-dezember-2026-neue-verbote) ![DMoove](https://dmoove.com/hubfs/raw_assets/public/dmoove-2026/images/logo-white.svg) DMoove Solutions GmbH Damaschkestraße 23 10711 Berlin Leistungen - [AWS Landing Zone](https://dmoove.com/aws-landing-zone) - [Kubernetes auf AWS](https://dmoove.com/kubernetes-auf-aws) - [European Sovereign Cloud](https://dmoove.com/european-sovereign-cloud) - [Amazon Quick & KI](https://dmoove.com/de/amazon-quick-ai-essentials) - [Migration & DevOps](https://dmoove.com/migration-devops) Unternehmen - [Über uns](https://dmoove.com/ueber-uns) - [Blog](https://dmoove.com/blog) - [Termin buchen](https://dmoove.com/meetings/yannick-tresch) - [LinkedIn](https://www.linkedin.com/company/dmoove) Rechtliches - [Impressum](https://dmoove.com/impressum) - [Datenschutz](https://dmoove.com/datenschutz) © 2026 DMoove Solutions GmbH ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Yannick Tresch", "url" : "https://dmoove.com/blog/author/yannick-tresch" }, "dateModified" : "2026-10-26T08:00:01.225Z", "datePublished" : "2026-10-26T08:00:01.000Z", "headline" : "Kubernetes 1.34 End of Life: Was EKS-Teams jetzt tun müssen – bevor AWS die Kontrolle übernimmt", "image" : [ "https://dmoove.com/hubfs/blog/agent-images/kubernetes-1-34-end-of-life-eks-featured-040109.png" ], "mainEntityOfPage" : { "@id" : "https://dmoove.com/blog/kubernetes-1-34-end-of-life-eks", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://dmoove.com/hubfs/dmo_logo450.png" }, "name" : "DMoove Solutions GmbH" } } ``` ```json { "@context" : "https://schema.org", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://dmoove.com/blog", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://dmoove.com/blog/tag/cloud-computing", "name" : "Cloud Computing", "position" : 2 }, { "@type" : "ListItem", "item" : "https://dmoove.com/blog/kubernetes-1-34-end-of-life-eks", "name" : "Kubernetes 1.34 End of Life: Was EKS-Teams jetzt tun müssen – bevor AWS die Kontrolle übernimmt", "position" : 3 } ] } ```