IPv6-Dual-Stack in Kubernetes: Was Enterprise-Cluster-Admins jetzt wissen müssen

Die Meldungen über „Kubernetes 1.36 stabil“ kursieren seit einigen Tagen in Tech-Kanälen – doch ein Blick in die offizielle Release-Historie bremst die Euphorie: Die aktuell stabile Upstream-Version liegt bei 1.31, eine fertige Version 1.36 existiert Stand Juni 2026 noch nicht als veröffentlichter Release. Was aber sehr wohl existiert und für Cluster-Admins heute relevant ist: IPv6-Dual-Stack als produktionsreifes Feature, das seit Kubernetes 1.23 GA-Status hat, plus eine wachsende Toolchain rund um CNI-Plugins, Container-Runtimes und Cluster-Management-Plattformen. Wer gerade seinen Enterprise-Cluster oder sein Homelab fit machen will, findet hier das Wesentliche.

Was stabil ist – und was nicht

Vorweg zur Versionsfrage: Kubernetes 1.36 taucht in Roadmap-Diskussionen auf, ist aber kein veröffentlichter stabiler Release. Wer Entscheidungen für Produktionscluster trifft, arbeitet mit dem, was tatsächlich freigegeben und dokumentiert ist. Die letzte offiziell stabile Upstream-Version ist 1.31. Enterprise-Distributionen wie k0s, MicroK8s oder Rancher liegen jeweils auf eigenen Release-Tracks, integrieren aber upstream-Features zeitversetzt – und haben IPv6-Dual-Stack längst in ihre stabilen Zweige übernommen.

Das ist keine Kleinigkeit. Viele Artikel vermischen Roadmap-Spekulation mit Produktionsrealität, und Admins richten ihre Upgrade-Planung danach aus. Wer auf ein Feature wartet, das angeblich „in 1.36 kommt“, und dabei übersieht, dass das Fundament längst steht, verschenkt Zeit.

Meine Einschätzung: Die Kubernetes-Community tendiert dazu, bei jeder neuen Versionsnummer einen Marketing-Moment zu konstruieren – dabei ist das eigentlich interessante Thema die Reife der bestehenden Features und wie gut die Toolchain rundherum mitspielt.

IPv6-Dual-Stack: GA seit 1.23, aber kein Selbstläufer

IPv6-Dual-Stack ist seit Kubernetes 1.23 (Dezember 2021) offiziell General Availability. Das bedeutet: Pods können sowohl eine IPv4- als auch eine IPv6-Adresse erhalten, Services lassen sich dual-stack betreiben, und der Cluster routet beide Adressfamilien. Die Aussage „das ist noch experimentell“ ist seit über drei Jahren schlicht veraltet – trotzdem kursiert sie noch in Blog-Posts, die niemand gepflegt hat.

Was bedeutet das konkret? Bei aktiviertem IPv6-Dual-Stack trägt jeder Pod zwei Adressen, eine pro Adressfamilie. Services können als PreferDualStack oder RequireDualStack konfiguriert werden. Der Cluster routet dann tatsächlich über beide Protokolle – sofern die Infrastruktur mitmacht. Und genau hier liegt der Haken, der in vielen Einführungstexten fehlt.

Die technischen Voraussetzungen sind nicht trivial: Nodes müssen dual-homed sein, also echte IPv4- und IPv6-Adressen besitzen. Control-Plane-Komponenten – API-Server, Controller-Manager, kube-proxy – brauchen entsprechende CIDR-Flags (--cluster-cidr, --service-cluster-ip-range) mit beiden Adressfamilien. Und das CNI-Plugin muss Dual-Stack tatsächlich unterstützen. Letzteres ist der am häufigsten unterschätzte Punkt.

Der Entwicklungspfad von Dual-Stack illustriert, wie Kubernetes Features schrittweise in die Produktion bringt: IPv6-only war ab Version 1.9 als Alpha verfügbar, Dual-Stack-Alpha folgte mit 1.16, und erst mit 1.23 war der Feature-Gate-Overhead weg. Wer die Alpha-Phasen miterlebt hat, weiß, wie viel sich in der CNI-Kompatibilität und den Control-Plane-Flags zwischen 1.16 und 1.23 getan hat – der GA-Status ist also nicht einfach ein Label, sondern spiegelt echte Reifung wider.

CNI ist der kritische Faktor, nicht die Container-Runtime

Ein verbreitetes Missverständnis: Dual-Stack sei primär eine Frage der Container-Runtime. Das ist falsch. Containerd und CRI-O – die seit dem Entfernen des dockershim in Kubernetes 1.24 obligatorischen CRI-Runtimes – brauchen für Dual-Stack keine besonderen Anpassungen. Die eigentliche Arbeit liegt beim CNI-Plugin und der Control-Plane-Konfiguration.

Calico ist ein häufig genannter Kandidat für Dual-Stack-Setups. Was dabei oft nicht erwähnt wird: Calico im Standard-vxlan-Modus unterstützt kein IPv6-Tunneling. Wer Dual-Stack mit Calico betreiben will, muss auf den BIRD-Modus wechseln. Das k0s-Projekt dokumentiert diese Einschränkung explizit – viele generische Kubernetes-Anleitungen verschweigen sie. Wer das übersieht, steht vor einem Cluster, der auf dem Papier Dual-Stack konfiguriert hat, aber faktisch keinen IPv6-Traffic transportiert.

Für k0s selbst sieht die Konfiguration konkret so aus: dualStack.enabled: true, dazu separate IPv6-CIDRs für Pods (Beispiel: fd00::/108) und Services (Beispiel: fd01::/108). Als Default-CNI nutzt k0s kube-router, Calico ist optional – jeweils mit den beschriebenen Einschränkungen. OKD und OpenShift setzen auf OVN-Kubernetes, das von Haus aus Dual-Stack beherrscht und der empfohlene Weg für Konvertierungen bestehender Single-Stack-Cluster ist.

Ein weiterer Fallstrick: falsche CIDR-Größen. Das GitHub-Issue #93446 dokumentiert, wie eine fehlerhafte Konfiguration von --node-cidr-mask-size-ipv4 und --node-cidr-mask-size-ipv6 dazu führt, dass Dual-Stack trotz korrekt gesetzter Feature-Gates nicht wirksam wird. Admins, die ein selbst gebautes Cluster aufsetzen, sollten diese Flags explizit prüfen.

Cilium ist als CNI-Alternative zunehmend relevant, besonders in Umgebungen, die eBPF-basiertes Netzwerking einsetzen. Cilium unterstützt Dual-Stack vollständig und ersetzt in vielen modernen Setups kube-proxy komplett. Der Vorteil gegenüber Calico im BIRD-Modus: Cilium bringt eine einheitliche Datenebene für IPv4 und IPv6 mit, ohne zwischen Tunneling-Modi wechseln zu müssen. Der Nachteil ist die höhere Komplexität beim Einstieg und der Bedarf an einem aktuellen Kernel – ältere RHEL-Derivate mit Kernel 4.x sind hier manchmal eine Bremse.

Enterprise-Distributionen: Wer hat Dual-Stack wirklich integriert?

Die gute Nachricht für alle, die nicht jeden CIDR-Flag von Hand setzen wollen: Die großen Enterprise-Distributionen haben IPv6-Dual-Stack inzwischen produktionsreif verpackt.

MicroK8s von Canonical dokumentiert Dual-Stack mit Calico als CNI-Backend und zeigt, wie Pods beide Adressen erhalten. Die Konfiguration läuft über Add-on-Mechanismen und ist verhältnismäßig zugänglich – auch für Homelab-Setups, wo MicroK8s eine sinnvolle Wahl ist, wenn man nicht jede Komponente selbst zusammenstecken will.

Rancher beschreibt IPv4/IPv6 Dual-Stack in seiner Cluster-Konfiguration und bietet UI-gestützte Optionen. Für Enterprise-Umgebungen mit zentralisiertem Cluster-Management ist das relevant: Admins konfigurieren Dual-Stack deklarativ, ohne direkt in kubelet-Flags eingreifen zu müssen. Die zugrundeliegenden Kubernetes-Konzepte bleiben dieselben, aber die Fehlerquelle durch manuelle Flag-Setzen wird reduziert.

k0s ist besonders interessant für On-Premises-Setups und Self-Hosting, weil die Konfiguration vollständig über eine YAML-Datei läuft und wenig externe Abhängigkeiten hat. Die Dual-Stack-Dokumentation ist konkret und listet CNI-Einschränkungen offen auf – das ist pragmatischer als viele andere Distributionen.

OKD/OpenShift zeigt einen definierten Migrationspfad für bestehende IPv4-Single-Stack-Cluster: Patchen von network.config.openshift.io, Hinzufügen von IPv6-CIDRs, Neustart betroffener Komponenten. OKD empfiehlt dabei für Service-CIDRs ein IPv6-/112-Netz, für Pod-Netzwerke mindestens /64. Das ist einer der wenigen offiziell dokumentierten Migrationspfade – im Upstream-Kubernetes ohne Distribution ist eine Migration riskanter und wird häufig durch einen Cluster-Neubau ersetzt.

CIDR-Planung: Wo Admins konkret aufpassen müssen

IPv6-Adressplanung ist ein Thema, das viele Admins unterschätzen, die aus reinen IPv4-Umgebungen kommen. ULA-Adressen (Unique Local Addresses, Präfix fd00::/8) sind für interne Cluster-Kommunikation üblich und nicht im öffentlichen Internet routbar – das entspricht dem RFC-1918-Konzept aus der IPv4-Welt, funktioniert aber anders.

Für Pod-CIDRs empfiehlt sich ein Präfix, das genug Spielraum für viele Nodes lässt. Bei einem /108 für den gesamten Pod-CIDR bleiben pro Node-Subnetz weniger Adressen als bei einem /64 – das muss zur erwarteten Cluster-Größe passen. Service-CIDRs sind typischerweise kleiner als Pod-CIDRs, weil die Anzahl der Services im Cluster geringer ist als die Anzahl der Pod-IPs.

Was bleibt nach der CIDR-Planung? Firewalling. IPv6-Firewalling funktioniert strukturell anders als IPv4-NAT-basierte Ansätze. In reinen IPv4-Clustern versteckt NAT viele Pods hinter wenigen Node-IPs – in Dual-Stack-Umgebungen sind Pod-IPv6-Adressen potenziell direkt routbar, je nach Netzwerkdesign. Das erfordert explizite Firewall-Regeln und ein durchdachtes Routing-Konzept.

Typische Fehler und wie man sie vermeidet

Aus der Praxis von Dual-Stack-Einführungen kristallisieren sich einige wiederkehrende Fehlerquellen heraus, die man kennen sollte, bevor man anfängt:

• Inkonsistente Flag-Reihenfolge: Kubernetes erwartet bei --cluster-cidr und --service-cluster-ip-range immer IPv4 an erster Stelle, wenn der primäre Stack IPv4 ist. Eine vertauschte Reihenfolge führt zu schwer diagnostizierbaren Routing-Fehlern, weil der Cluster formal startet, aber Services falsch zugewiesen werden.
• Kube-proxy im iptables-Modus mit IPv6: In älteren Setups, die noch iptables statt nftables oder eBPF nutzen, kann IPv6-Dual-Stack zu Race Conditions bei der Regelgenerierung führen. Der ipvs-Modus oder ein vollständiger kube-proxy-Ersatz durch Cilium ist hier robuster.
• Unvollständige CoreDNS-Konfiguration: CoreDNS muss AAAA-Records auflösen können und selbst über IPv6 erreichbar sein, wenn Pods bevorzugt über IPv6 kommunizieren sollen. Eine CoreDNS-Instanz, die nur über IPv4 lauscht, beantwortet AAAA-Anfragen zwar, ist aber über IPv6 selbst nicht erreichbar – das führt zu asymmetrischen Auflösungszeiten.
• LoadBalancer-Services ohne IPv6-Unterstützung im Ingress: Viele On-Premises-LoadBalancer-Lösungen wie MetalLB unterstützen Dual-Stack, müssen aber explizit mit einer IPv6-Adresspool-Konfiguration versehen werden. Wer MetalLB ohne IPv6-Pool betreibt, bekommt für RequireDualStack-Services keinen zweiten Load-Balancer-Eintrag.

Diese Fehler sind nicht exotisch – sie tauchen in Community-Foren regelmäßig auf und kosten Stunden Debugging-Zeit. Sie vorab zu kennen, ist barer Zeitgewinn bei der Einrichtung.

Warum Dual-Stack strategisch trotzdem sinnvoll ist

IPv4-Adressen sind knapp. Das ist kein neues Thema, aber in Cluster-Umgebungen, die auf 5G-Edge-Workloads, IoT-Integration oder sehr große Pod-Zahlen ausgelegt sind, wird es konkret. CloudNativeNow beschreibt IPv6-Dual-Stack als zentralen Baustein für das Skalieren von Kubernetes jenseits heutiger IPv4-Grenzen und als Vorbereitung für 5G- und Edge-Workloads. Das ist keine Hype-Aussage, sondern eine Netzwerk-Realität: Wer große Cluster mit zehntausenden Pods betreibt, kommt mit RFC-1918-Adressräumen in RFC-1918-Adressräumen irgendwann an Grenzen.

Dual-Stack ist dabei kein Endzustand, sondern ein Übergang. Greenfield-Datacenter-Setups und Edge-Deployments können mittelfristig IPv6-only werden. Dual-Stack hält die Rückwärtskompatibilität zu IPv4-Diensten aufrecht, während die Infrastruktur auf IPv6 migriert. CERN betreibt seit Jahren große wissenschaftliche Cluster auf IPv6-fähiger Infrastruktur und hat früh auf Dual-Stack-Ansätze gesetzt – das ist ein Datenpunkt, der zeigt, dass das kein Thema nur für Public-Cloud-Provider ist.

Für On-Premises-Homelab-Cluster gilt: Wer jetzt Dual-Stack einrichtet, übt die Konzepte und hat später weniger Migrationsschmerz. MicroK8s bietet dafür einen vergleichsweise niedrigschwelligen Einstieg mit dokumentierter Calico-Konfiguration für IPv4/IPv6-Dual-Stack.

Cluster-Management: Deklarativ oder doch noch manuell?

Ein Trend, der sich in den Distro-Dokumentationen abzeichnet: Cluster-Management wird zunehmend deklarativ. OKD/OpenShift patcht Netzwerkkonfigurationen über CRDs, Rancher abstrahiert Dual-Stack-Optionen in eine UI, k0s zieht alles aus einer YAML. Das ist sinnvoll, weil manuelle kubelet-Flag-Orgie auf zehn Nodes fehleranfällig ist und Drift erzeugt.

Für Self-Hosting-Setups bedeutet das konkret: GitOps-Workflows funktionieren für Netzwerkkonfiguration nur, wenn das Cluster-Tool selbst deklarative Konfiguration unterstützt. k0s und MicroK8s sind hier praktisch, weil die gesamte Cluster-Konfiguration – inklusive Dual-Stack-Flags – in versionierbaren Dateien liegt. Wer mit kubeadm arbeitet, muss mehr manuell orchestrieren, hat aber maximale Kontrolle über jeden Schritt.

Monitoring und Observability sind in Dual-Stack-Umgebungen aufwendiger. Zwei Adressfamilien bedeuten doppelte Routing-Tabellen, potenziell unterschiedliche MTUs und separate Logs für IPv4- und IPv6-Traffic. Werkzeuge wie kube-prometheus-stack brauchen entsprechende Scrape-Konfigurationen, die beide Adressfamilien abdecken. Das ist lösbar, aber kein Zero-Effort. Die k0s-Dokumentation zur Dual-Stack-Konfiguration listet CNI-Einschränkungen und konkrete Konfigurationsfelder klar auf – ein seltenes Beispiel für ehrliche technische Dokumentation ohne Marketing-Weichzeichner.

Sicherheitsaspekte, die Dual-Stack-Einführungen begleiten müssen

Ein Aspekt, der in technischen Dual-Stack-Anleitungen häufig zu kurz kommt, ist die Sicherheitsdimension. IPv6 verändert das Angriffsprofil eines Clusters auf mehreren Ebenen. Wer bislang davon ausgegangen ist, dass interne Pod-Adressen durch NAT nicht direkt ansprechbar sind, muss dieses Modell revidieren.

Konkret bedeutet das für die Kubernetes-Netzwerkpolitik: NetworkPolicy-Ressourcen müssen für IPv6 explizit definiert werden. Viele bestehende Policies sind implizit auf IPv4 ausgelegt, weil die Pod-Selektoren IP-unabhängig arbeiten – aber CNI-Plugins wenden NetworkPolicies je nach Implementierung unterschiedlich auf beide Adressfamilien an. Calico im BIRD-Modus und Cilium handhaben das korrekt, aber ältere CNI-Versionen können IPv6-Traffic durch eine Policy durchlassen, die für IPv4 eigentlich blockieren würde.

Ein weiterer Punkt ist die Neighbor-Discovery-Protocol-Sicherheit (NDP). IPv6 nutzt NDP anstelle von ARP für die Adressauflösung im Link-Layer. NDP-Spoofing ist analog zu ARP-Spoofing möglich und erfordert entsprechende Gegenmassnahmen auf dem physischen Switch oder im virtuellen Netzwerk. In VMware- oder Proxmox-Umgebungen muss Promiscuous Mode oder IPv6-NDP-Snooping auf Port-Ebene konfiguriert sein, damit Dual-Stack-Pods korrekt kommunizieren können und gleichzeitig das Netzwerk nicht offen für Spoofing-Angriffe ist. Wer die Entwicklung kryptografischer Sicherheitsstandards für verteilte Systeme verfolgt, erkennt, dass diese Netzwerkschicht-Probleme eine ähnliche strategische Aufmerksamkeit verdienen wie kryptografische Protokollfragen.

Für Cluster mit externem Routing empfiehlt sich zudem eine explizite Prüfung, ob der BGP-Speaker – etwa in MetalLB oder Calico – IPv6-Prefixes tatsächlich nur in die vorgesehenen Routing-Domains ankündigt. Eine fehlerhafte BGP-Konfiguration kann ULA-Adressen in unerwünschte Netzsegmente propagieren, was zwar nicht direkt eine Sicherheitslücke, aber ein erhebliches Debugging-Problem darstellt.

Was bleibt und was Sie jetzt tun können

Kubernetes 1.36 kommt – wann genau und mit welchem Feature-Set, ist zum jetzigen Zeitpunkt Spekulation. Was nicht spekulativ ist: IPv6-Dual-Stack ist seit über drei Jahren produktionsreif, die Toolchain ist ausgereifter als je zuvor, und der Migrationsdruck in Richtung IPv6 nimmt zu. Wer erst auf „die nächste große Version“ wartet, schiebt eine Lernkurve vor sich her, die sich nicht von allein abflacht.

Konkret: Wer ein Homelab-Cluster betreibt, kann Dual-Stack mit MicroK8s oder k0s heute einrichten – die Dokumentation ist vorhanden, die CNI-Einschränkungen sind bekannt, und der Aufwand ist überschaubar. Wer einen Enterprise-Cluster plant, sollte die CIDR-Planung für IPv6 früh angehen, das CNI-Plugin explizit auf Dual-Stack-Tauglichkeit prüfen und sich nicht auf „Calico kann das schon“ verlassen, ohne den Modus zu verifizieren.

Und die offene Frage bleibt: Wie viele Produktionscluster laufen heute noch IPv4-only – nicht weil Dual-Stack nicht verfügbar wäre, sondern weil niemand Zeit hatte, die CIDR-Planung aufzuräumen?