KubeIP v2: Statische öffentliche IPs für Kubernetes-Nodes – Cloud-übergreifend

In bestimmten Szenarien profitieren Kubernetes-Nodes davon, eigene statische öffentliche IP-Adressen zu erhalten.

KubeIP, ein Open-Source-Tool, deckt genau diesen Bedarf ab und weist Kubernetes-Nodes statische öffentliche IPs zu. Die neueste Version, KubeIP v2, erweitert den Support von Google Clouds GKE auf Amazons EKS – und ist so konzipiert, dass sich weitere Cloud-Anbieter problemlos ergänzen lassen. KubeIP läuft als DaemonSet und bietet damit gegenüber dem bisherigen Kubernetes-Controller-Ansatz mehr Zuverlässigkeit, flexiblere Konfiguration und eine bessere Usability. KubeIP v2 unterstützt sowohl IPv4- als auch IPv6-Adressen.

In diesem Beitrag gehen wir auf konkrete Einsatzszenarien für KubeIP ein, vergleichen es mit Cloud-NAT-Gateways und werfen einen Blick auf Architektur und Konfiguration von KubeIP.

KubeIP ist in vielen Szenarien hilfreich, in denen Kubernetes-Nodes statische öffentliche IPs brauchen.

Hier einige typische Einsatzfälle:

Gaming-Anwendungen

Im Gaming muss eine Konsole unter Umständen eine direkte Verbindung zu einer Cloud-VM aufbauen, um Netzwerk-Hops und Latenz zu minimieren. Bekommt der Node, auf dem der Gameserver läuft, eine eigene öffentliche IP, kann sich die Konsole direkt verbinden. Das verbessert das Spielerlebnis durch geringere Latenz und weniger Paketverluste.

Whitelisting von Agent-IPs

Wenn Sie mehrere Agents oder Services in Kubernetes betreiben, die direkte Verbindungen zu einem externen Server brauchen, und dieser Server die IP-Adressen der Agents auf eine Whitelist setzen muss, lässt sich das mit KubeIP deutlich einfacher steuern als über breit gefasste CIDR-Bereiche – KubeIP weist den Nodes stabile öffentliche IPs zu. Besonders praktisch ist das, wenn der externe Server strenge IP-basierte Zugriffskontrollen einsetzt.

SNAT für ausgewählte Pods umgehen

Standardmäßig erhalten Pods private IPs aus dem CIDR-Bereich der VPC. Bei der Kommunikation mit externen IPv4-Adressen übersetzt das Amazon VPC CNI Plugin die Pod-IP per SNAT (Source Network Address Translation) auf die primäre private IP der Netzwerkschnittstelle des Nodes.

In manchen Fällen wollen Sie SNAT für bestimmte Pods umgehen, damit externe Services die echten Pod-IPs sehen. Indem Sie den Nodes mit KubeIP öffentliche IPs zuweisen und im Pod-Spec hostNetwork: true setzen, erreichen Sie genau das. Der Pod kommuniziert dann direkt über die öffentliche IP des Nodes mit externen Services.

Direkte eingehende Verbindungen und individuelle Netzwerk-Szenarien

Öffentliche IPs auf Nodes via KubeIP eröffnen vielfältige Netzwerk-Szenarien. So können Sie Traffic direkt an Pods weiterleiten, die auf diesen Nodes laufen – praktisch, wenn Sie Services auf dem Node ohne klassischen Load Balancer im Internet bereitstellen wollen.

Ein Beispiel: Sie betreiben einen Webserver in einem Pod und leiten den Traffic über die öffentliche IP des Nodes an ihn weiter.

Darüber hinaus lässt sich KubeIP für maßgeschneiderte Netzwerk-Szenarien einsetzen, in denen öffentliche IPs auf Nodes erforderlich sind. Sie könnten etwa einen eigenen Load Balancer bauen, der Traffic anhand der öffentlichen IP an bestimmte Nodes weiterleitet. Diese Flexibilität macht KubeIP zu einem mächtigen Werkzeug, um eigene Netzwerklösungen in Kubernetes zu testen oder produktiv zu betreiben.

KubeIP geht über IPv4 hinaus und unterstützt auch die Zuweisung statischer öffentlicher IPv6-Adressen an Nodes. Das gewinnt zunehmend an Bedeutung, da das Internet aufgrund der Knappheit an IPv4-Adressen immer stärker auf IPv6 umstellt.

Mit dem IPv6-Support von KubeIP können Sie Ihren Kubernetes-Nodes statische öffentliche IPv6-Adressen zuweisen, sodass sie direkt per IPv6 mit externen Services kommunizieren. Das ist besonders nützlich für Anwendungen, die IPv6-Konnektivität voraussetzen. Wenn Sie etwa eine Anwendung entwickeln oder ausrollen, die IPv6 unterstützen muss, können Sie KubeIP nutzen, um den Pods Ihrer Anwendung IPv6-Konnektivität bereitzustellen.

Hinzu kommt: IPv6 bietet einen größeren Adressraum, ein vereinfachtes Header-Format, besseren Support für Erweiterungen und Optionen, optimiertes Multicast-Routing und weitere Verbesserungen gegenüber IPv4.

NAT-Gateways sind Managed Services in der Cloud, die Ressourcen in privaten Subnetzen ausgehenden Internetzugang ermöglichen, indem sie deren private IPs in öffentliche IPs übersetzen. Sie sind darauf ausgelegt, Ressourcen in einem privaten Netzwerk ausgehende Verbindungen ins Internet zu erlauben und gleichzeitig deren Privatsphäre und Sicherheit zu wahren.

Allerdings unterstützen NAT-Gateways weder eingehende Verbindungen, noch weisen sie Ressourcen direkt öffentliche IPs zu. Heißt: Für sicheren ausgehenden Zugriff sind sie hervorragend geeignet, aber nicht für Szenarien, in denen eingehende Verbindungen erforderlich sind oder Ressourcen eigene öffentliche IPs brauchen.

KubeIP weist Kubernetes-Nodes hingegen statische öffentliche IPs direkt zu. Dadurch lassen sich eingehende Verbindungen direkt zu Pods auf diesen Nodes herstellen, indem der Traffic vom Node an den Pod weitergeleitet wird. Das ist besonders nützlich für Anwendungen, die aus dem Internet erreichbar sein müssen, oder für individuelle Netzwerk-Szenarien.

Ist zudem hostNetwork aktiviert, können Pods ausgehende Verbindungen direkt über die IP-Adresse des Hosts initiieren. Das kann die Netzwerkperformance verbessern und das Troubleshooting vereinfachen – sollte aber wegen möglicher Sicherheitsimplikationen mit Bedacht eingesetzt werden.

Kurz gesagt: NAT-Gateways sind eine ausgezeichnete Lösung für sicheren ausgehenden Zugriff; KubeIP bietet darüber hinaus zusätzliche Flexibilität und Kontrolle über ein- und ausgehende Konnektivität für bestimmte Pods und Nodes.

Bei den Kosten von KubeIP im Vergleich zu Cloud-NAT-Gateways spielen mehrere Faktoren eine Rolle.

Kosten für Cloud-NAT-Gateways

Cloud-NAT-Gateways sind ein Managed Service und damit kostenpflichtig. Die Kosten richten sich in der Regel nach der verarbeiteten Datenmenge und der Zeit, in der das NAT-Gateway bereitgestellt und verfügbar ist.

AWS berechnet zum Zeitpunkt der Erstellung dieses Beitrags etwa 0,045 USD pro Stunde für ein NAT-Gateway, zuzüglich Gebühren für die Datenverarbeitung. Hinzu kommen die üblichen AWS-Gebühren für sämtlichen über das NAT-Gateway laufenden Datentransfer.

Das Preismodell von Google Cloud NAT ist vergleichbar.

Kosten für KubeIP

KubeIP ist Open Source – die Nutzung selbst ist also kostenlos. Es gibt jedoch einige indirekte Kostenpunkte zu berücksichtigen:

1. Statische öffentliche IP-Adressen: Sie zahlen für die statischen öffentlichen IP-Adressen, die Sie Ihren Nodes zuweisen. Die Preise variieren je nach Cloud-Anbieter. AWS berechnet etwa 0,005 USD pro Stunde für eine Elastic IP, unabhängig davon, ob sie genutzt wird oder nicht. Google Cloud verlangt denselben Preis für eine statische IP-Adresse.
2. Datentransfer: Für Daten, die über die zugewiesenen statischen öffentlichen IP-Adressen übertragen werden, fallen die üblichen Datentransfergebühren an. Diese richten sich nach den Tarifen Ihres Cloud-Anbieters.
3. Zusätzliche Last im Cluster: Auch wenn KubeIP als DaemonSet läuft und kaum CPU- und Speicherressourcen benötigt, ist es ein zusätzlicher Workload in Ihrem Kubernetes-Cluster. Das kann insbesondere bei knappen Ressourcen die Performance anderer workloads beeinflussen. In den meisten Fällen ist die Auswirkung jedoch minimal.
4. Wartung und Support: Als Open-Source-Tool kommt KubeIP ohne dedizierten Support. Wartung, Troubleshooting und Updates müssen Sie selbst übernehmen. Direkte Kosten entstehen dadurch zwar nicht, aber der Zeit- und Personalaufwand schlägt sich indirekt im Budget Ihres Unternehmens nieder.

Fazit: KubeIP verursacht zwar keine direkten Kosten, aber mehrere indirekte Kostenpunkte sollten einkalkuliert werden. In vielen Anwendungsfällen überwiegen jedoch die Flexibilität und die Kontrolle, die KubeIP bietet.

Kostenüberlegungen

Bei der Bewertung der Wirtschaftlichkeit von KubeIP sollten Sie sowohl direkte als auch indirekte Kosten berücksichtigen. Dazu zählen die Kosten für statische öffentliche IP-Adressen, Datentransfergebühren, die mögliche Auswirkung eines zusätzlichen Workloads auf Ihren Kubernetes-Cluster sowie der Aufwand für Wartung und Support.

KubeIP an sich ist zwar kostenlos, doch diese indirekten Kosten können sich – vor allem bei größeren Clustern – summieren. Gleichzeitig liefern die Flexibilität und Kontrolle von KubeIP einen erheblichen Mehrwert, gerade für Anwendungsfälle mit direkten eingehenden Verbindungen oder individuellen Netzwerk-Szenarien.

Cloud-NAT-Gateways bieten dagegen einen Managed Service, der ausgehende Konnektivität für Ressourcen in privaten Subnetzen vereinfacht. Dieser Service ist kostenpflichtig, dafür profitieren Sie von Vorteilen wie einfacher Bedienung, Skalierbarkeit und Zuverlässigkeit.

Fazit: Die Wahl zwischen KubeIP und einem Cloud-NAT-Gateway hängt von Ihrem konkreten Anwendungsfall, der Größe und den Anforderungen Ihres Kubernetes-Clusters sowie Ihrem Budget ab. Wir empfehlen, die Kosten auf Basis Ihres erwarteten Datentransfers, der Anzahl an Nodes/IP-Adressen und Ihres Wartungsaufwands zu kalkulieren, um eine fundierte Entscheidung zu treffen.

KubeIP läuft als DaemonSet auf den von Ihnen ausgewählten Nodes. Auf jedem Node führt es folgende Schritte aus:

1. Es ermittelt über die Kubernetes Downward API Informationen zum Node und zum Cloud-Anbieter.
2. Es holt sich einen clusterweiten Lock, sodass immer nur ein Node gleichzeitig eine IP zuweist – das verhindert Race Conditions und IP-Konflikte.
3. Es wählt anhand von Filtern und Selektoren eine verfügbare statische IP aus dem konfigurierten Pool aus.
4. Es weist die IP über die API des Cloud-Anbieters der primären Netzwerkschnittstelle des Nodes zu.
5. Schlägt die Zuweisung fehl – etwa durch eine Netzwerkunterbrechung oder einen API-Fehler – versucht KubeIP es bis zu einem konfigurierten Limit erneut.
6. Wird ein Node gelöscht, gibt KubeIP die zugewiesene IP zurück in den Pool, sodass sie für andere Nodes wieder verfügbar ist.

KubeIP unterstützt IPv4- und IPv6-Adressen und lässt sich für unterschiedliche Pools je Adresstyp konfigurieren. Auch eigene IP-Pools für verschiedene Nodes oder Node Groups sind möglich – das schafft Flexibilität bei der IP-Verwaltung.

KubeIP v2 ist als gewöhnliches Kubernetes-DaemonSet konzipiert und läuft damit auf jedem Node im Cluster.

Dieses Design erhöht Zuverlässigkeit und Usability gegenüber dem vorherigen Controller-basierten Ansatz. Es vereinfacht zudem das Deployment und stellt sicher, dass jeder Node eine öffentliche IP erhält. Über Standard-Kubernetes-Features wie Node Selectors oder Node Affinity steuern Sie zudem, auf welchen Nodes KubeIP ausgerollt wird. So gewinnen Sie feingranulare Kontrolle über die IP-Zuweisung und können bestimmten Nodes je nach Anforderung gezielt öffentliche IPs zuweisen.

Die erweiterbare Architektur von KubeIP v2 erlaubt eine einfache Integration weiterer Cloud-Anbieter über GKE und EKS hinaus – das macht es zu einem vielseitigen Werkzeug für die Verwaltung öffentlicher IPs in Multi-Cloud-Umgebungen.

KubeIP benötigt einen Kubernetes Service Account mit Berechtigungen, um Nodes abzurufen und Leases zu verwalten.

Auf Cloud-Seite ist eine IAM-Rolle bzw. ein Service Account mit Berechtigungen zum Zuweisen, Aufheben und Auflisten öffentlicher IPs sowie zum Abrufen von Node-Informationen erforderlich.

Hier ein Beispiel für eine AWS-IAM-Policy:

{
  "Version": "2012-10-17",
  "Statement": [\
    {\
      "Effect": "Allow",\
      "Action": [\
        "ec2:AssociateAddress",\
        "ec2:DisassociateAddress",\
        "ec2:DescribeInstances",\
        "ec2:DescribeAddresses"\
      ],\
      "Resource": "*"\
    }\
  ]
}

Und eine Google Cloud IAM-Rolle:

title: "KubeIP Role"
description: "KubeIP required permissions"
stage: "GA"
includedPermissions:
- compute.instances.addAccessConfig
- compute.instances.deleteAccessConfig
- compute.instances.get
- compute.addresses.get
- compute.addresses.list
- compute.addresses.use
- compute.zoneOperations.get
- compute.subnetworks.useExternalIp
- compute.projects.get

Um auszuwählen, welche IPs verwendet werden sollen, geben Sie Filter in derselben Syntax an wie das CLI bzw. die API des jeweiligen Cloud-Anbieters zum Auflisten von IPs. Zum Beispiel:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kubeip
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: kubeip
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: kubeip
    spec:
      serviceAccountName: kubeip-service-account
      terminationGracePeriodSeconds: 30
      priorityClassName: system-node-critical
      nodeSelector:
        nodegroup: public
        kubeip: "use"
      tolerations:
        - operator: "Exists"
          effect: "NoSchedule"
        - operator: "Exists"
          effect: "NoExecute"
      containers:
      - name: kubeip
        image: doitintl/kubeip-agent
        imagePullPolicy: Always
        resources:
          requests:
            cpu: "10m"
            memory: "32Mi"
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: LEASE_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: FILTER
          value: "Name=tag:kubeip,Values=reserved;Name=tag:environment,Values=prod"
        - name: LOG_LEVEL
          value: "debug"
        - name: LOG_JSON
          value: "true"

Damit weisen Sie KubeIP auf AWS an, ausschließlich IPs mit den Tags kubeip=reserved und environment=prod zu berücksichtigen.

Der KubeIP-AWS-Filter unterstützt dieselbe Filtersyntax wie der AWS-Befehl describe-addresses. Weitere Informationen finden Sie unter describe-addresses. Wenn Sie mehrere Filter angeben, werden diese mit einem AND verknüpft, und es werden nur Ergebnisse zurückgegeben, die alle angegebenen Filter erfüllen. Mehrere Filter müssen durch Semikolons (;) getrennt werden.

Der KubeIP-Google-Cloud-Filter unterstützt dieselbe Filtersyntax wie der Google-Cloud-Befehl gcloud compute addresses list. Weitere Informationen finden Sie unter gcloud topic filter. Wenn Sie mehrere Filter angeben, werden diese mit einem AND verknüpft, und es werden nur Ergebnisse zurückgegeben, die alle angegebenen Filter erfüllen. Mehrere Filter müssen durch Semikolons (;) getrennt werden.

Das Verzeichnis examples enthält Terraform-Konfigurationen, mit denen Sie GKE- und EKS-Cluster inklusive KubeIP-Deployment hochziehen können.

Für EKS:

cd examples/aws

terraform init

terraform apply

Und für GKE:

cd examples/gcp

terraform init

# ohne IPv6-Support
terraform apply -var="project_id=<your-project-id>"

# mit IPv6-Support
terraform apply -var="project_id=<your-project-id>" -var="ipv6_support=true"

Damit wird ein Cluster mit öffentlichen und privaten Node Pools bereitgestellt, einige statische IPs werden reserviert und das KubeIP-DaemonSet so konfiguriert, dass es genau diese reservierten IPs nutzt.

Als Open-Source-Projekt freuen wir uns über jede Form der Mitarbeit! Reichen Sie Pull Requests ein, eröffnen Sie Issues, helfen Sie bei der Dokumentation oder erzählen Sie anderen davon.

Mit dem erweiterten Cloud-Support und dem vereinfachten DaemonSet-Modell in v2 sind wir gespannt, welche neuen Anwendungsfälle KubeIP ermöglicht. Probieren Sie es in Ihrer Umgebung aus und lassen Sie uns wissen, wie es läuft!