Docker & Kubernetes: So kommunizieren Container und Pods korrekt

Netzwerke sind das Rückgrat moderner Container- und Kubernetes-Anwendungen. Ohne das richtige Verständnis der Kommunikationsmechanismen zwischen Containern, Pods und dem Hostsystem laufen selbst einfache Architekturen ins Leere.

Doch wie gelangen zwei isolierte Container zueinander? Warum scheitert die localhost-Anbindung? Und wie funktioniert die Kommunikation in Kubernetes, wo Pods flüchtige IP-Adressen besitzen? Dieser Leitfaden erklärt die wichtigsten Szenarien – von Docker-Netzwerken bis zu Kubernetes Services – und zeigt, wie Entwickler typische Fallstricke vermeiden.

Warum die Container-Kommunikation oft übersehen wird

Ein Container ist standardmäßig ein isoliertes System mit eigenem Netzwerk-Namensraum, eigener IP-Adresse und separatem Blick auf die Umgebung. Für zwei Dienste – etwa eine API und eine Datenbank – bedeutet das: Sie müssen aktiv miteinander verbunden werden.

Ein persönliches Beispiel: Beim Bau von SwiftDeploy, einem Tool, das seine Infrastruktur selbst generiert, liefen Go-API und Nginx in separaten Containern. Erst durch gezielte Netzwerkkonfiguration wurde die Kommunikation zwischen ihnen möglich. Ohne dieses Wissen wäre die Anwendung niemals funktionsfähig gewesen.

Szenario 1: Zwei Container kommunizieren miteinander

Das klassische Szenario: Ein Frontend verbindet sich mit einem Backend, oder eine API greift auf eine Datenbank zu. Hier scheitern viele Entwickler bereits an einem fundamentalen Missverständnis:

• Der Fehler: localhost:5432 verwenden, um auf eine PostgreSQL-Datenbank zuzugreifen.
• Die Ursache: Innerhalb eines Containers bezieht sich localhost nur auf diesen Container selbst – nicht auf den Host oder andere Container.

Die Lösung: Docker-Netzwerke und Service-Namen

Der richtige Ansatz nutzt Docker-Netzwerke und Service-Namen. Sobald zwei Container demselben Netzwerk angehören, können sie sich über den Servicenamen ansprechen.

networks:
  myapp-net:
    driver: bridge

services:
  api:
    image: my-api
    networks:
      - myapp-net
  database:
    image: postgres
    networks:
      - myapp-net

Die API kann nun die Datenbank unter database:5432 erreichen. Docker’s internes DNS-System löst diesen Namen automatisch in die Container-IP auf – etwa 172.18.0.3.

In SwiftDeploy nutzt Nginx die API unter api:3000. Erst diese Konfiguration ermöglichte die reibungslose Zusammenarbeit beider Dienste.

Szenario 2: Container erreichen den Host-Rechner

Manchmal muss ein Container auf Dienste zugreifen, die direkt auf dem Entwicklungsrechner laufen – etwa eine lokale Datenbank oder einen Entwicklungs-Server. Doch auch hier gilt: localhost im Container ist nicht der Host.

Die Lösung: Spezielle Host-Namen oder Gateway-IPs

• Mac/Windows: Nutzen Sie host.docker.internal. Docker stellt diesen Hostnamen automatisch bereit.
• Linux: Verwenden Sie die Standard-Gateway-IP 172.17.0.1 des Docker-Bridge-Netzwerks.

# Verbindung zu einer lokalen PostgreSQL-Datenbank in einem Container
db = connect("host.docker.internal:5432")

Alternativ können Sie den Container im Host-Netzwerkmodus starten. Dann teilt er sich das Netzwerk des Hosts – localhost funktioniert wieder, allerdings um den Preis der Netzwerkisolierung.

docker run --network host my-app

Szenario 3: Zwei reguläre Anwendungen auf demselben Rechner

Nicht immer kommen Container zum Einsatz. Zwei klassische Anwendungen auf demselben System kommunizieren über localhost und Ports.

Beispiel: Flask-API und React-App im Entwicklungsmodus

Die Flask-API wird auf Port 8000 gestartet:

app.run(host="0.0.0.0", port=8000)

Die React-App greift über localhost:8000 darauf zu:

fetch(")

Das Betriebssystem leitet die Anfrage intern weiter. Diese Methode ist schnell, erfordert aber, dass beide Anwendungen auf demselben Rechner laufen.

Szenario 4: Ein Container kommuniziert mit einer Host-Anwendung

Ein häufiges Architektur-Muster: Ein Reverse-Proxy wie Nginx läuft im Container, während die API direkt auf dem Host läuft. Wie erreicht der Proxy die API?

Zwei bewährte Lösungen

1. Port-Mapping: Die API läuft auf Port 3000 des Hosts. Der Nginx-Container greift über host.docker.internal:3000 darauf zu.

1. Host-Netzwerkmodus: Nginx wird mit --network host gestartet. Nun kann er localhost:3000 direkt nutzen.

In SwiftDeploy wurden sowohl API als auch Nginx in Containern betrieben – und nutzten dafür ein gemeinsames Docker-Netzwerk. Diese Konfiguration ist jedoch typisch für Entwicklungs-Setups.

Szenario 5: Kubernetes – wie Pods untereinander kommunizieren

In Kubernetes laufen Container in Pods. Die Kommunikation funktioniert auf zwei Ebenen:

Innerhalb eines Pods: Shared Network Namespace

Enthält ein Pod mehrere Container, teilen sie sich einen Netzwerk-Namensraum. Sie kommunizieren über localhost, als wären es lokale Prozesse.

spec:
  containers:
    - name: api
      ports:
        - containerPort: 8000
    - name: sidecar
      # Kann die API unter localhost:8000 erreichen

Zwischen Pods: Kubernetes Services als stabiler Anker

Pods erhalten dynamische IP-Adressen, die sich bei Neustarts ändern. Direkte IP-Adressen zu nutzen, ist daher riskant. Stattdessen kommen Services zum Einsatz – sie bieten einen stabilen DNS-Namen, der Anfragen an die passenden Pods weiterleitet.

apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api  # Leitet Anfragen an Pods mit diesem Label weiter
  ports:
    - port: 80
      targetPort: 8000

Jeder Pod im Cluster erreicht die API nun unter api-service:80. Kubernetes-DNS löst diesen Namen automatisch in die richtige Pod-IP auf – selbst wenn sich diese ändert.

Die verschiedenen Service-Typen im Überblick

• ClusterIP: Nur innerhalb des Clusters erreichbar (ähnlich wie Docker’s internes Netzwerk).
• NodePort: Macht den Service über einen bestimmten Port auf jedem Node zugänglich.
• LoadBalancer: Erstellt einen Cloud-Load-Balancer mit öffentlicher IP.

Zusammenfassung: Wann welche Methode nutzen?

| Szenario | Kommunikation | Schlüsseltechnologie | Beispiel | |----------|---------------|----------------------|----------| | Container ↔ Container | Service-Name auf gemeinsamem Netzwerk | Docker-Netzwerk | api:3000 | | Container → Host | host.docker.internal oder Gateway-IP | Docker-Bridge | 172.17.0.1:5432 | | App ↔ App (ohne Docker) | localhost:Port | Betriebssystem | localhost:8000 | | Container ↔ Host-App | Port-Mapping oder Host-Netzwerk | Docker-Ports | host.docker.internal:3000 | | Pod ↔ Pod (Kubernetes) | Service-DNS-Name | Kubernetes Service | api-service:80 | | Pod ↔ Pod (gleicher Pod) | localhost | Shared Network Namespace | localhost:8000 |

Fazit: Netzwerkkonfiguration als Grundpfeiler moderner Anwendungen

Die Kommunikation zwischen Containern und Pods ist kein Detail, sondern das Fundament jeder verteilten Anwendung. Ob Docker, Kubernetes oder klassische Setups – das richtige Netzwerkdesign entscheidet über Stabilität, Skalierbarkeit und Wartbarkeit.

Wer diese Mechanismen beherrscht, vermeidet typische Fallstricke wie falsche localhost-Zugriffe oder flüchtige IP-Adressen. Und wie SwiftDeploy zeigt: Selbst einfache Anwendungen profitieren von einer durchdachten Netzwerkarchitektur.

Für Entwickler lohnt es sich, diese Konzepte frühzeitig zu verinnerlichen – denn sie sind der Schlüssel zu robusten, skalierbaren Systemen.