Container-Networking: Grundlagen, Modelle und Best Practices

Kernkonzepte von Container-Networking

Die folgenden Konzepte sind wesentlich für das Verständnis von Container-Networking.

1. Netzwerk-Namespaces

Container laufen in isolierten Bereichen, die als Namespaces oder Namensräume bezeichnet werden. Jeder Namespace verfügt über seine eigenen Routing-Tabellen, Netzwerkschnittstellen und Firewall-Regeln. Dadurch verhindert man, dass verschiedene Container aufeinander zugreifen, sofern sie nicht explizit dafür konfiguriert sind. Ein Namespace erzeugt unterschiedliche Netzwerkumgebungen pro Pod oder Container.

2. Virtuelle Ethernet-Schnittstellen

Virtuelle Ethernet-Paare (veth-Paare) sorgen für Verbindungen zwischen Namespaces und dem Host-Netzwerk. Jedes Paar besitzt zwei Enden: Ein Ende ist mit dem Container-Namespace verbunden, das andere mit der Host-Netzwerk-Bridge. Dadurch lassen sich Daten zwischen dem Host und dem Container für die externe Konnektivität übertragen.

3. Diensterkennung

Die Diensterkennung ermöglicht die Kommunikation zwischen Containern, indem Containernamen IP-Adressen oder DNS-Namen zugeordnet werden, um die Skalierbarkeit zu gewährleisten.

4. Containernetzwerkschnittstelle

Das Container Networking Interface (CNI) ist ein Projekt der Cloud Native Computing Foundation (CNCF). Es besteht aus einer Spezifikation und einer Reihe von Bibliotheken, die für das Schreiben von Plug-ins sowie für die Konfiguration von Containerschnittstellen unter Linux und Windows verwendet werden. CNI weist Networking-Ressourcen zu, wenn Container erstellt werden. Es entfernt sie dann, wenn Teams diese Ressourcen nicht mehr benötigen und sie löschen.

CNI standardisiert, wie eine Container-Runtime mit verschiedenen Kubernetes-Netzwerk-Plug-ins interagiert, um Networking-Konfigurationen für Container zu erstellen und zu aktivieren. CNI bietet auch eine Standardisierung für Containerorchestratoren wie Kubernetes zur Integration mit verschiedenen Networking Tools und Plug-ins. Diese Standardisierung gewährleistet ein konsistentes Networking.

Wenn Netzwerke einen Container benötigen, ruft die Container-Runtime CNI auf, das Schnittstellen, Routen und Netzwerk-Namespaces konfiguriert. CNI gibt die Konfigurationen dann an die Container-Runtime zurück. Die Container-Runtime startet den Container und ruft, wenn er beendet oder gelöscht wird, erneut CNI auf, um die Ressourcen zu bereinigen.

Gängige Container-Networking-Modelle

Folgend finden Sie die häufigsten Container-Networking-Modelle, die Teams nutzen können:

• Bridge Networking (lokales Netzwerk mit Namespaces).
• Host Networking (direkte Host-Netzwerkanbindung).
• Overlay Networking (Networking über mehrere Hosts).

1. Bridge Networking (lokales Netzwerk mit Namespaces)

Bei diesem Modell isoliert ein Host ein Containernetzwerk, indem er eine Bridge erstellt. Dieses Modell eignet sich ideal für die lokale Entwicklung, Single-Host-Umgebungen und Situationen, in denen der Traffic zwischen Containern nicht über mehrere Hosts geroutet werden muss. Durch Port-Mapping lässt sich die Bridge auch erweitern, um die Services extern zugänglich zu machen.

In Kubernetes wird das Bridge-Networking-Modell nicht direkt verwendet. Stattdessen arbeitet es auf einer höheren Abstraktionsebene und wird meist von CNI-Plug-ins verwaltet. Das folgende Beispiel zeigt daher, wie man ein isoliertes Bridge-Netzwerk in Docker erstellt.

Beispiel

Docker erstellt standardmäßig eine virtuelle Bridge namens docker0. Diese ermöglicht die interne Kommunikation über IP-Adressen aus einem privaten Netzwerkbereich und Network Address Translation (NAT) für ausgehenden Traffic.

# Create a custom bridge network
docker network create --driver bridge my_bridge_network

# Run containers on the bridge
docker run -d --network my_bridge_network --name container1 nginx
docker run -d --network my_bridge_network --name container2 nginx

# Inspect the bridge network details
docker network inspect my_bridge_networks

2. Host Networking (direkte Host-Netzwerkanbindung)

Beim Host Networking ist im Gegensatz zum Bridge Networking eine Isolierung nicht erforderlich. Hierbei wird das Containernetzwerk direkt auf den Netzwerk-Namespace des Hosts gemappt, womit man NAT umgeht. Dieses Modell eignet sich für High-Performance-Anwendungen, bei denen eine niedrige Latenz entscheidend ist und die Isolierung keine große Rolle spielt.

Beispiel 1

Nachfolgend sehen Sie, wie Sie Host Networking in Docker nutzen.

# Run container with host networking
docker run -d --network host --name web nginx

Beispiel 2

In Kubernetes legen Sie Host Networking in der Pod-Spezifikation fest. Mit hostNetwork: true wird das Netzwerk des Pods direkt auf den Knoten gemappt.

apiVersion: v1
kind: Pod
metadata:
  name: host-network-pod
spec:
  hostNetwork: true
  containers:
  - name: nginx
    image: nginx

3. Overlay Networking (Networking über mehrere Hosts)

Overlay Networking ermöglicht die Host-übergreifende Kommunikation zwischen Containern und kapselt den Datenverkehr mittels Virtual Extensible LAN (VXLAN). Kubernetes- und Docker-Schwarm-Cluster verwenden dieses Modell für die Kommunikation zwischen Containern über verschiedene Knoten hinweg.

Dieses Modell ist am besten für hochgradig verteilte Anwendungen geeignet. Für Kubernetes verwalten CNI-Plug-ins, etwa Cilium, Overlay Networking häufig auf Layer 3.

Gestaltung von Containernetzwerken

Beim Design von Containernetzwerken werden herkömmliche Networking-Elemente mit den skalierbaren Anforderungen von containerisierten Umgebungen in Einklang gebracht. Zu diesen Elementen gehören unter anderem:

• Vorhandene Netzwerkinfrastruktur.
• Software-defined Networking (SDN).
• Netzwerkrichtlinien.

Vorhandene Netzwerkinfrastruktur

Bei der Gestaltung von Containernetzwerken ist es von entscheidender Bedeutung, eine reibungslose Integration in die bereits vorhandene Netzwerkinfrastruktur zu gewährleisten. Dies ist vor allem bei Legacy-Systemen und anderen externen Services wichtig.

Wenn Anwendungen mit Legacy-Datenbanken oder Anwendungen, die in On-Premises-Rechenzentren gehostet werden, kommunizieren müssen, gilt es, eine effektivere Verbindungsmethode zu konfigurieren, um eine hohe Performance sicherzustellen. Dazu gehören Verfahren wie VPN-Tunneling oder direkte Verbindungen.

SDN

SDN abstrahiert die Networking-Schicht, so dass Teams einfacher auf eine programmierbare und zentralisierte Control Plane zugreifen können. Die zentralisierte Control Plane verwaltet den Datenfluss zwischen Containern, sowohl innerhalb eines Clusters als auch über mehrere Cluster hinweg. Somit wird die Control Plane von der Data Plane entkoppelt. Diese Trennung ermöglicht es DevOps und Netzwerktechnikern, den Netzwerk-Traffic programmgesteuert zu kontrollieren und bei Bedarf auf Änderungen der Netzwerkanforderungen zu reagieren.

SDN-Controller legen das Netzwerkverhalten mithilfe von High-Level-Richtlinien fest. Sie weisen IP-Adressen dynamisch zu, setzen Richtlinien durch und verwalten Routen in den Containern. In Hybrid-Cloud- und Multi-Cloud-Umgebungen verwaltet SDN das Netzwerk infrastrukturübergreifend, indem es die Hardwareschicht abstrahiert.

Netzwerkrichtlinien

Netzwerkrichtlinien regeln, wie Pods untereinander und mit externen Diensten kommunizieren. Sie sind zudem für die Netzwerksicherheit essenziell und besonders dann notwendig, wenn sich Services in derselben physischen Netzwerkinfrastruktur befinden.

In Kubernetes wenden Netzwerktechniker Richtlinien auf Namespace- oder Pod-Ebene an. Netzwerkrichtlinien helfen den Technikern, den Datenverkehr zwischen Pods im Cluster zu steuern und eine Zero-Trust-Architektur in containerisierten Umgebungen zu erreichen. Tools wie Cilium oder Istio können Container dabei unterstützen, Zero Trust zu realisieren. Dadurch müssen Komponenten verifiziert und autorisiert werden, um zu kommunizieren, auch intern.

Beispiel

Das folgende Beispiel zeigt, wie man Traffic nur von bestimmten Pods zulässt. Angenommen, es gibt zwei Anwendungen: app-frontend und app-backend. Beide laufen im selben Kubernetes-Namespace. Nachstehend finden Sie ein Beispiel für eine Cilium-Netzwerkrichtlinie, die den Traffic zu app-backend nur von app-frontend aus erlaubt.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-frontend-to-backend"
spec:
  description: "Allows traffic from app-frontend to app-backend."
  endpointSelector:
    matchLabels:
      app: app-backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: app-frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP

Container-Networking: Herausforderungen und Lösungen

Container bieten zwar ein gewisses Maß an Flexibilität, bringen aber auch neue Herausforderungen für das Networking mit sich. Im Folgenden gehen wir auf einige der häufigsten Probleme und ihre Lösungen ein:

• Wildwuchs bei IP-Adressen.
• Gewährleistung der Netzwerkisolierung.
• Dynamische containerisierte Workloads.

Wildwuchs bei IP-Adressen

Der Netzwerk-Namespace eines Hosts weist den Containern nach der Erstellung eindeutige IP-Adressen zu. Mit zunehmender Komplexität der Anwendung benötigt diese unter Umständen mehr Container. Sie braucht daher mehr IP-Adressen. Container sind von Natur aus dynamisch (das heißt, sie werden häufig erstellt und gelöscht), was zu einer schnellen Zuweisung und Freigabe von IP-Adressen führt. Dies kann schnell außer Kontrolle geraten und zu IP-Engpässen und Subnetzüberschneidungen beitragen.

Diese Herausforderungen erschweren es Netzwerktechnikern, den Überblick über Container zu behalten und sie zu verwalten, insbesondere in großen Infrastrukturen. Letztlich führt dies zu einer schlechten Netzwerk-Performance und Kommunikationsstörungen.

Lösung

Eine Möglichkeit, dieses Problem zu beheben, ist der Einsatz von Cilium, das die IP-Adressverwaltung unterstützt. Cilium bietet IP-Pooling, clusterweite IP-Adressierung und subnetzspezifische Zuweisung. Alle diese Funktionen minimieren eine mögliche Fragmentierung. Auf diese Weise lassen sich IP-Engpässe, Subnetzkonflikte und IP-Überschneidungen in Kubernetes-Umgebungen mit hohem Durchsatz und mehreren Clustern vermeiden. Cilium integriert zudem IP-Bereiche von virtuellen Private Clouds (VPC), Echtzeit-Monitoring und automatisches IP-Recycling.

Gewährleistung der Netzwerkisolierung

Alle Container, die auf demselben Host-Netzwerk laufen, teilen sich die zugrunde liegenden Netzwerkressourcen und die Infrastruktur. Wenn sie nicht korrekt konfiguriert sind, können Benutzer versehentlich auf die Daten anderer Container zugreifen, die eigentlich isoliert sein sollten. Dies stellt eine Bedrohung durch Lateral Movement dar, bei dem Angreifer einen Container kompromittieren könnten. Netzwerktechniker müssen für eine ordnungsgemäße Konfiguration sorgen, damit nur die beabsichtigte Kommunikation zwischen Containern stattfindet – ohne dass die Performance beeinträchtigt wird.

Lösung

In Kubernetes-Umgebungen hilft die Implementierung der Kubernetes Network Policies auf Containerebene dabei, Workloads zu isolieren. Cilium kann noch einen Schritt weiter gehen und die standardmäßige Spezifikation der Kubernetes Network Policies durch eigene Richtlinien erweitern.

Diese Richtlinien arbeiten identitätsbasiert und implementieren feingranulare Regeln auf Layer 3, 4 und 7 des OSI-Modells. Sobald sie implementiert sind, ermöglichen sie die Kontrolle über die Kommunikation zwischen Containern, indem sie explizit festlegen, wer kommunizieren darf, etwa ein Pod, eine Gruppe von Pods (mit den gleichen Labeln), Namespaces oder Cluster. Wenn der Anwendungs-Layer eine Service-zu-Service-Isolierung erfordert, empfiehlt es sich, die Richtlinien in ein Service-Mesh zu integrieren,

Dynamische containerisierte Workloads

Da Container von Natur aus flexibel und kurzlebig sind, ist es eine Herausforderung, stabile Networking-Verbindungen zwischen Services aufrechtzuerhalten. Die Services kennen möglicherweise nicht die aktuellen IP-Adressen anderer Geräte, wodurch die Kommunikation unterbrochen wird.

Lösung

Nutzen Sie Mechanismen zur Serviceerkennung, wenn sich die IP-Adresse eines Containers ändert, damit andere Dienste ihn weiterhin über einen festen DNS-Namen erreichen können. Load Balancer können auch dabei helfen, den Traffic unabhängig von der IP-Adresse an den richtigen Container zu leiten.

Tools für Container-Networking

Die folgenden Container-Networking-Tools sind für Netzwerktechniker geeignet.

Cilium

Bei Cilium handelt es sich um eine eBPF-basierte Containernetzwerkschnittstelle für Kubernetes, die 2015 von Isovalent, jetzt Teil von Cisco, entwickelt wurde. Das Tool ist Teil der CNCF-Landschaft und als Open-Source-Version sowie als kostenpflichtiges Abonnement verfügbar. Es deckt zahlreiche Anwendungsfälle ab und bietet unter anderem:

• Die Möglichkeit, als Service-Mesh zu fungieren.
• Load Balancing zwischen Services, zum Beispiel Express-Data-Path-basiertes Load Balancing für niedrige Latenz.
• Verschlüsselung.
• Ein Layer-3-Netzwerk, das auch Layer-7-Protokolle berücksichtigt und Netzwerkrichtlinien auf Layer 3, 4 und 7 durchsetzt.
• Einen Ersatz für kube-proxy.
• Ein Bandbreitenmanagement.

Calico

Calico ist ein Netzwerk- und Sicherheits-Tool für Kubernetes, das mehrere Netzwerkmodelle unterstützt. Durch seinen Layer-3-Networking-Ansatz lässt sich Calico in großen verteilten Systemen, in denen der Layer-2-Broadcast-Verkehr nicht zu managen ist, in hohem Maße skalieren. Darüber hinaus nutzt es eBPF, um den Overhead zu reduzieren und den Durchsatz für ein schnelleres Networking zu steigern.

Die Netzwerkrichtlinie von Calico kann andere Containerorchestratoren wie OpenShift unterstützen. Aus Sicherheitsgründen unterstützt Calico das IPsec- und WireGuard-Protokoll zur Verschlüsselung der Daten während der Übertragung.

Flannel

Flannel ist ein schlankes Overlay-Netzwerk-Tool für Kubernetes, das nur eine minimale Einrichtung erfordert und eine geringe operative Komplexität aufweist. Es ist bewusst einfach gehalten, so dass seine grundlegenden Networking-Funktionen einen idealen Ausgangspunkt für kleine bis mittelgroße Bereitstellungen darstellen. Somit fehlen erweiterte Features, die für große Umgebungen erforderlich sind, beispielsweise Netzwerkrichtlinien und Verschlüsselung.

Wenn ihre Anforderungen wachsen, können Unternehmen später auf funktionsreichere Optionen umsteigen.

Istio

Istio ist ein Open-Source-Service-Mesh, um die Service-zu-Service-Kommunikation in Microservices zu verwalten. Istio konzentriert sich auf Traffic-Management, Sicherheit und Observability. Das Tool umfasst unter anderem folgende Funktionen:

• Automatisches Load Balancing.
• Traffic-Management.
• Eine erweiterbare Richtlinienschicht.
• Umfassende Observability und Überwachung mit minimalen oder gar keinen Änderungen am Servicecode.

Istio eignet sich ideal für komplexe Architekturen und arbeitet mit anderen Containernetzwerkschnittstellen zusammen, um eine umfangreichere Netzwerkstrategie zu ermöglichen.

Die Performance von Container-Networking

Traffic Monitoring ist ausschlaggebend für die Zuverlässigkeit und Leistung von Containernetzwerken. Sichtbarkeit ist notwendig, um Engpässe und potenzielle Netzwerkausfälle zu erkennen, die die Produktion beeinträchtigen könnten. Tools wie Prometheus und Grafana können den Traffic überwachen sowie Latenz und Bandbreitennutzung im Auge behalten.

Um die Quality of Service (QoS) zu gewährleisten, empfiehlt es sich, Richtlinien anzuwenden, die kritische Services gegenüber weniger wichtigem Datenverkehr priorisieren. Mit einer effizienten Ressourcenzuweisung kann man Performance-Einbußen vermeiden.