IPv4-Adressierung für Kubernetes: Was du beachten musst

IPv4-Adressierung für Kubernetes ist ein Thema, das in vielen Clustern erst dann Aufmerksamkeit bekommt, wenn es bereits weh tut: Pods bleiben im Pending, Nodes skalieren nicht mehr sauber hoch, Services sind plötzlich nicht erreichbar oder eine Hybrid-Anbindung scheitert wegen überlappender Netze. Der Grund ist simpel: Kubernetes ist extrem „IP-hungrig“. Anders als klassische VM-Umgebungen braucht Kubernetes nicht nur IPs für Nodes, sondern auch für Pods, Services und – je nach Netzwerk-Plugin – zusätzliche Overlay- oder Tunneladressen. Wer den IPv4-Adressraum zu knapp plant oder unkoordiniert wählt, produziert IP-Engpässe und Routing-Konflikte, die später nur mit großem Aufwand zu beheben sind. Dazu kommen Cloud-spezifische Besonderheiten: In AWS, Azure oder GCP beeinflussen Subnetzgrößen, reservierte IPs, CNI-Verhalten und Load-Balancer-Konzepte direkt, wie viele Pods pro Node möglich sind und wie viel Wachstum im Cluster steckt. In diesem Artikel erfährst du, welche IPv4-Bereiche in Kubernetes typischerweise benötigt werden, wie du Pod- und Service-CIDRs sauber planst, welche typischen Stolperfallen (IP-Overlap, zu kleine Subnetze, SNAT-Engpässe) auftreten und wie du deine Adressierung so aufbaust, dass sie in On-Premises-, Hybrid- und Cloud-Setups langfristig stabil bleibt.

Warum Kubernetes bei IPv4 so schnell an Grenzen stößt

Kubernetes orchestriert sehr viele kurzlebige Endpunkte: Pods werden dynamisch erstellt, skaliert und verschoben. Jeder Pod braucht eine IP-Adresse, damit Service-Discovery, Network Policies und direkte Pod-zu-Pod-Kommunikation funktionieren. Zusätzlich kommen Services hinzu, die (je nach Typ) eigene virtuelle IPs bekommen. Das führt dazu, dass die Anzahl benötigter IPv4-Adressen deutlich höher ist als in typischen VM-Designs.

• Nodes: Jede Worker-Node benötigt mindestens eine IP im Node-Subnetz.
• Pods: Je Pod eine IP (häufig im Pod-CIDR oder – bei bestimmten CNIs – direkt im VPC/VNet-Subnetz).
• Services: ClusterIP-Services beziehen IPs aus dem Service-CIDR.
• Ingress/Load Balancer: Je nach Cloud und Service-Typ entstehen zusätzliche IP-Belegungen.

Die privaten IPv4-Adressbereiche, die in Kubernetes-Umgebungen typischerweise eingesetzt werden, sind in RFC 1918 definiert. Für CIDR und die Logik hinter Präfixen ist RFC 4632 hilfreich.

Die drei wichtigsten IPv4-Adressräume im Kubernetes-Design

Für eine robuste Planung solltest du drei Adressräume klar unterscheiden und dokumentieren. Je nach CNI und Plattform können Details variieren, das Grundprinzip ist jedoch stabil:

• Node-Netz: Das Subnetz, in dem die Nodes (VMs/Server) liegen. In der Cloud ist das meist ein VPC/VNet-Subnetz.
• Pod-Netz (Pod CIDR): Der IPv4-Bereich, aus dem Pods ihre IPs erhalten (Overlay oder direkt geroutet).
• Service-Netz (Service CIDR): Der IPv4-Bereich für ClusterIP-Services (virtuelle Service-IP).

In Kubernetes selbst sind diese Konzepte an die Cluster-Netzwerkarchitektur gekoppelt. Ein guter Einstieg in die offiziellen Grundlagen ist die Kubernetes-Dokumentation zum Thema Networking: Kubernetes Networking Model und Services, Load Balancing, and Networking.

Pod-CIDR planen: die wichtigste Entscheidung für Skalierung

Der Pod-CIDR bestimmt, wie viele Pod-IP-Adressen insgesamt zur Verfügung stehen. Dabei solltest du nicht nur den Ist-Zustand planen, sondern auch Skalierung und Ausfall-Szenarien: Wenn eine Availability Zone ausfällt, müssen Workloads möglicherweise in anderen Zonen hochskaliert werden. Eine zu enge Pod-Range führt dann zu einem echten Betriebsrisiko.

Faustregel: Pods pro Node und Node-Anzahl zuerst schätzen

Ein praxistauglicher Startpunkt ist, die maximal erwartete Anzahl Pods pro Node (oder pro Node-Pool) zu schätzen und daraus die Gesamtzahl benötigter Pod-IP-Adressen abzuleiten. Vereinfacht gilt:

$\mathrm{PodIPs}\approx \mathrm{Nodes}\times \mathrm{PodsProNode}\times \mathrm{ReserveFaktor}$

Der ReserveFaktor liegt in der Praxis häufig zwischen 1,2 und 1,5 (20–50% Reserve), abhängig von Wachstum, Burst-Scaling und dem Risiko, das du akzeptierst.

Adressanzahl eines CIDR-Präfixes verstehen

Die Anzahl an IPv4-Adressen in einem Präfix berechnest du so:

$\mathrm{Adressen}=2^{32-p}$

Ein /16 hat 65.536 Adressen, ein /20 hat 4.096, ein /22 hat 1.024, ein /24 hat 256. Für Kubernetes ist ein einzelnes /24 als Pod-CIDR fast immer zu klein, sobald du ernsthaft skalierst.

Service-CIDR: oft klein, aber nicht vernachlässigen

Services (ClusterIP) erhalten IPs aus dem Service-CIDR. Viele Cluster kommen mit relativ wenigen Services aus, aber moderne Plattformen nutzen oft zahlreiche interne Services (pro Namespace, pro Team, pro Microservice). Ein zu kleiner Service-CIDR ist zwar seltener ein Problem als ein zu kleiner Pod-CIDR, kann aber in großen Umgebungen unerwartet limitieren.

• Typische Größen: /20 bis /24 (abhängig von Plattform und Service-Dichte).
• Wichtig: Service-CIDR darf nicht mit Pod- oder Node-Netzen überlappen.
• Praxis: Lieber moderat großzügig planen, weil eine spätere Änderung häufig migrationsintensiv ist.

Grundlagen zu Services und ClusterIP liefert die offizielle Kubernetes-Dokumentation: Service.

CNI macht den Unterschied: Overlay vs. „Pods im VPC/VNet“

Die IPv4-Adressierung hängt stark vom CNI (Container Network Interface) ab. Zwei große Modelle dominieren:

• Overlay-Netz: Pods nutzen einen eigenen Pod-CIDR, der per Overlay (z. B. VXLAN) über das Node-Netz transportiert wird.
• Native IPs im Cloud-Netz: Pods bekommen IPs direkt aus dem VPC/VNet-Subnetz (z. B. bei bestimmten Cloud-CNIs).

Overlay: mehr Freiheit, weniger Druck auf VPC/VNet-Subnetze

Overlay-Modelle entkoppeln Pod-IPs vom Cloud-Subnetz. Das kann IP-Skalierung erleichtern, weil du den Pod-CIDR unabhängig vom Node-Netz dimensionierst. Gleichzeitig entstehen Anforderungen an Routing, MTU und Netzwerk-Policies, die du sauber testen solltest.

Pods im VPC/VNet: einfache Integration, aber Subnetzgröße wird kritisch

Wenn Pod-IPs direkt aus Cloud-Subnetzen kommen, „frisst“ Kubernetes sehr schnell die verfügbaren IPv4-Adressen in diesen Subnetzen. Dann werden Subnetze pro Node-Pool groß und müssen mit ausreichender Reserve geplant werden. Zudem sind in Cloud-Subnetzen häufig IPs reserviert, was kleine Subnetze noch unattraktiver macht.

Für AWS ist der Zusammenhang zwischen VPC/Subnetzen und Kubernetes in der Praxis besonders sichtbar – eine stabile Grundlage für VPC-Adressierung ist die AWS-Dokumentation zu VPC CIDR blocks. Für Azure sind die Konzepte und Reservierungen in Private IP addresses in Azure relevant. Für GCP ist der Überblick zu VPC und Subnetzen hier hilfreich: VPC networks und Subnets.

Stolperfalle: Cloud-IP-Overlap mit On-Premises, VPN und Peering

Kubernetes-Cluster sind selten völlig isoliert. Oft gibt es Hybrid-Anbindungen (VPN/Direct Connect/ExpressRoute), Peering oder Multi-Cluster-Setups. In solchen Szenarien sind überlappende IPv4-Bereiche ein klassischer Showstopper: Wenn Pod- oder Service-CIDRs mit On-Premises-Netzen kollidieren, wird Routing unzuverlässig oder unmöglich. Besonders häufig passiert das, wenn Teams „irgendwelche“ RFC1918-Bereiche verwenden, ohne zentralen Abgleich.

• Pod-CIDR kollidiert mit On-Premises: interne Systeme sind aus Pods nicht erreichbar oder Traffic geht in den falschen Pfad.
• Service-CIDR kollidiert: Service-IPs sind virtuell, aber Routing/Proxying kann scheitern, sobald Pakete nach „außen“ müssen.
• Mehrere Cluster kollidieren: Multi-Cluster-Service-Mesh oder Cluster-Peering wird komplex.

Ein übergreifender Abgleich und klare Governance sind hier entscheidend. Die grundlegenden privaten Bereiche sind in RFC 1918 definiert – die Planung musst du jedoch selbst diszipliniert umsetzen.

Stolperfalle: SNAT, Egress und „zu wenige Ports“ bei IPv4

Ein Thema, das in Kubernetes-Umgebungen besonders häufig unterschätzt wird, ist Egress über NAT (SNAT). Viele Pods teilen sich beim Zugriff ins Internet oder auf externe Services eine kleine Anzahl öffentlicher IPv4-Adressen. Das kann zu Port-Engpässen führen, wenn sehr viele gleichzeitige Verbindungen aufgebaut werden. Dann treten Fehler auf, die wie Application-Bugs wirken, aber eigentlich „NAT-Erschöpfung“ sind.

Warum NAT-Ports begrenzt sind

Pro Quell-IP stehen nur eine begrenzte Anzahl an Quellports zur Verfügung. Wenn viele Pods gleichzeitig zu denselben Zielen sprechen, kann ein NAT-Gateway oder eine SNAT-Instanz an Limits stoßen. Eine vereinfachte Obergrenze pro Quell-IP (ohne Reserven/Provider-Details) kann man so ausdrücken:

$\mathrm{MaxVerbindungen}\approx \mathrm{VerfuegbareQuellports}\times \mathrm{AnzahlEgressIPs}$

In der Praxis spielen Timeouts, Zielverteilung, Keep-Alives und Provider-Implementierungen eine große Rolle – entscheidend ist das Verständnis: IPv4-Egress skaliert nicht „unendlich“, wenn du zu wenige Egress-IP-Adressen oder zu wenige NAT-Kapazitäten planst.

Gegenmaßnahmen für stabile IPv4-Egress-Architektur

• Egress-IPs skalieren: mehr öffentliche IPv4s oder mehrere NAT-Instanzen/Gateways (je nach Plattform).
• Egress kontrollieren: Egress-Gateways, Proxy, zentrale Egress-Punkte pro Namespace/Team.
• Verbindungsmanagement: Keep-Alive sinnvoll konfigurieren, Connection Pools nutzen.
• Monitoring: SNAT-Fehler, Port-Auslastung und Connection-Tracking überwachen.

On-Premises Kubernetes: zusätzliche IPv4-Themen

In On-Premises-Clustern sind die Freiheitsgrade oft größer, aber die Verantwortung ebenfalls. Typische Themen sind:

• Routing des Pod-CIDR: Wenn Pods aus anderen Netzen erreichbar sein sollen, muss der Pod-Adressraum geroutet oder per Overlay/Ingress abstrahiert werden.
• Firewall-Regeln: Network Policies im Cluster ersetzen keine Perimeterregeln; beide müssen aufeinander abgestimmt sein.
• IPAM und Dokumentation: Ohne IPAM steigt das Overlap-Risiko, besonders in Multi-Cluster- oder Standort-Setups.

Praxisempfehlungen: IPv4-Adressierung für Kubernetes „richtig“ aufsetzen

Die folgenden Empfehlungen sind bewusst konservativ, weil Adressänderungen im laufenden Kubernetes-Betrieb oft aufwendiger sind als in klassischen Netzen:

• Pod-CIDR großzügig planen: lieber einen größeren, eindeutig reservierten Bereich (z. B. /16 oder /17) als späteres Flickwerk.
• Service-CIDR separat und eindeutig: keine Overlaps, ausreichend Reserve (z. B. /20 bis /24 je nach Service-Dichte).
• Node-Subnetze nicht zu knapp: besonders in der Cloud, wenn Pods aus dem Subnetz kommen oder viele ENIs genutzt werden.
• Adressräume zentral vergeben: IPAM oder zumindest verbindliche Dokumentation (Owner, Zweck, Lebenszyklus, Peering/Hybrid).
• Multi-Cluster berücksichtigen: pro Cluster eindeutige Pod/Service-CIDRs; Service Mesh oder Cluster-Peering früh einplanen.
• Egress-Design mitdenken: SNAT-Kapazität, Egress-IP-Strategie, Monitoring.

Konkrete Blueprint-Beispiele für Pod- und Service-CIDRs

Diese Beispiele sind nicht „die einzige Wahrheit“, aber sie zeigen gängige Muster, die gut skalieren und Overlaps vermeiden helfen:

Beispiel: Ein Cluster, Hybrid-Anbindung, moderates Wachstum

• Node-Netz: 10.20.0.0/20 (pro Region/AZ gesplittet, je nach Cloud)
• Pod-CIDR: 10.40.0.0/16
• Service-CIDR: 10.50.0.0/20

Beispiel: Mehrere Cluster (Dev/Prod), Multi-Cluster-fähig

• Prod Pod-CIDR: 10.60.0.0/16
• Prod Service-CIDR: 10.70.0.0/20
• Dev Pod-CIDR: 10.80.0.0/16
• Dev Service-CIDR: 10.90.0.0/20

Wichtig ist, dass diese Bereiche nicht mit On-Premises-Standortnetzen, Cloud-VPC/VNet-Ranges oder Partner-VPNs kollidieren.

Checkliste: IPv4-Adressierung für Kubernetes ohne böse Überraschungen

• Sind Pod-CIDR und Service-CIDR eindeutig und ohne Overlaps zu bestehenden Netzen?
• Sind die Node-Subnetze groß genug für Skalierung und ggf. Pod-IP-Zuweisung (CNI-Modell beachten)?
• Gibt es 20–50% Reserve für Wachstum, Burst-Scaling und Failover?
• Ist die Egress-Strategie definiert (NAT, Egress-IP, Proxy, Monitoring)?
• Ist Multi-Cluster (heute oder morgen) berücksichtigt, damit CIDRs nicht kollidieren?
• Existiert eine zentrale Dokumentation/IPAM mit Owner und Vergabeprozess?

Outbound-Links für vertiefende, offizielle Grundlagen

• Kubernetes: Cluster Networking Model
• Kubernetes: Services, Load Balancing, and Networking
• Kubernetes: Service (ClusterIP, NodePort, LoadBalancer)
• RFC 1918: Private IPv4-Adressbereiche
• RFC 4632: CIDR / Classless Routing
• AWS: VPC CIDR blocks (Planung in der Cloud)
• Azure: Private IP addresses (Subnetze und Reservierungen)
• Google Cloud: VPC networks (Grundlagen)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.