DevOps Wissensdatenbank
DevOps Wissensdatenbank

NodePort vs. LoadBalancer vs. Ingress: Die Wahl der besten Dienstbereitstellung

Treffen Sie die entscheidende Wahl, Kubernetes-Dienste extern zugänglich zu machen, indem Sie NodePort, LoadBalancer und Ingress vergleichen. Dieser Leitfaden beschreibt die Architektur, die Betriebsschicht (L4 vs. L7), Anwendungsfälle und die wichtigsten Unterschiede in Bezug auf Kosten und Komplexität für jede Methode. Erfahren Sie, wann Sie den einfachen NodePort für Tests, den dedizierten LoadBalancer für einzelne Dienste oder den leistungsstarken Ingress für zentralisiertes, kostengünstiges Layer-7-Routing und komplexe Multi-Service-Umgebungen verwenden sollten.

32 Aufrufe

NodePort vs. LoadBalancer vs. Ingress: Die beste Service-Exposition wählen

Kubernetes Services sind grundlegende Objekte, die eine stabile Netzwerkkonnektivität für eine dynamische Gruppe von Pods bereitstellen. Während Services die interne Cluster-Kommunikation handhaben, erfordert die externe Exposition dieser Services – also die Ermöglichung der Interaktion von Benutzern oder externen Anwendungen mit ihnen – eine spezielle Konfiguration. Die Wahl der richtigen Expositionsmethode ist entscheidend und beeinflusst Sicherheit, Kosten und Komplexität.

Dieser Artikel bietet einen Expertenvergleich der drei primären Methoden zur Exposition von Kubernetes Services: NodePort, LoadBalancer und Ingress. Wir analysieren die Mechanismen, geeignete Anwendungsfälle und praktische Faktoren, um Sie bei der Auswahl der optimalen Lösung für Ihre containerisierten Anwendungen zu unterstützen.

1. Service-Expositionstyp: NodePort

Der NodePort-Servicetyp ist die einfachste und primitivste Methode, einen Service extern zu exponieren. Wenn Sie einen Service als NodePort definieren, öffnet Kubernetes einen bestimmten statischen Port auf jedem Knoten im Cluster. Jeder Traffic, der an diesen Port auf einem beliebigen Knoten gerichtet ist, wird direkt an den Service weitergeleitet.

So funktioniert NodePort

  1. Ein zufälliger Port innerhalb eines definierten Bereichs (Standard: 30000-32767) wird automatisch ausgewählt.
  2. Dieser Port wird auf allen Cluster-Knoten geöffnet.
  3. Der Service lauscht auf diesem NodePort und leitet den Traffic an die entsprechenden Pods weiter.

Um auf die Anwendung zuzugreifen, verwenden Sie http://<Knoten_IP>:<NodePort>.

Anwendungsfälle und Einschränkungen

Merkmal Beschreibung
Anwendungsfall Entwicklungs-, Testumgebungen oder wenn die externe Lastverteilung von einem externen Nicht-Cloud-Appliance gehandhabt wird.
Komplexität Sehr gering.
Kosten Null (wenn man die zugrunde liegenden VM-Kosten ignoriert).
Einschränkung Erfordert manuelles Management externer Firewall-Regeln. Knoten-IPs sind oft dynamisch. Portbereichsbeschränkung (30000-32767).

NodePort-Beispiel

apiVersion: v1
kind: Service
metadata:
  name: my-app-nodeport
spec:
  type: NodePort
  selector:
    app: my-web-app
  ports:
    - port: 80
      targetPort: 8080
      # Optional: einen NodePort angeben, ansonsten wird automatisch einer gewählt
      # nodePort: 30001

⚠️ Warnung: NodePort exponiert den Service über alle Knoten. Wenn ein Knoten entfernt wird oder seine IP sich ändert, bricht der externe Zugriff ab. Dies wird im Allgemeinen nicht für Produktionsumgebungen empfohlen, die auf Stabilität angewiesen sind.

2. Service-Expositionstyp: LoadBalancer

Der LoadBalancer-Servicetyp ist die Standardmethode, um Anwendungen in Cloud-Umgebungen (AWS EKS, GCP GKE, Azure AKS) im öffentlichen Internet verfügbar zu machen.

Wenn ein Service als LoadBalancer definiert ist, stellt Kubernetes automatisch einen dedizierten Layer-4 (L4) Cloud-Load-Balancer (z. B. AWS Classic ELB/NLB, Azure Load Balancer, GCP Network Load Balancer) bereit. Dies bietet eine stabile, hochverfügbare externe IP-Adresse, die den Traffic direkt an die Service-Pods weiterleitet.

Cloud-Provider-Integration

Das entscheidende Unterscheidungsmerkmal von LoadBalancer ist die tiefe Integration mit der zugrunde liegenden Cloud-Infrastruktur. Der Cloud-Provider kümmert sich um den Lebenszyklus des Load-Balancers, um Health Checks und um das Routing.

Anwendungsfälle und Kostenimplikationen

Merkmal Beschreibung
Anwendungsfall Einfache, öffentlich zugängliche Anwendungen, die eine dedizierte, stabile IP-Adresse benötigen. Geeignet für Nicht-HTTP/S-Protokolle (TCP/UDP).
Komplexität Gering (bezüglich der Konfiguration).
Kosten Hoch. Jeder LoadBalancer-Service stellt eine dedizierte Cloud-Ressource bereit, was oft zu stundenweisen Gebühren führt.
Vorteil Bietet sofortige Hochverfügbarkeit und automatische Health Checks.

LoadBalancer-Beispiel

apiVersion: v1
kind: Service
metadata:
  name: my-app-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: my-api-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Nach der Erstellung weist der Cluster eine externe IP-Adresse zu (sichtbar im Service-Status), die vom Cloud-Provider verwaltet wird.

3. Kubernetes Ingress: Layer-7-Routing

Ingress unterscheidet sich grundlegend von NodePort und LoadBalancer. Ingress ist kein Service-Typ, sondern ein API-Objekt, das Regeln für den externen Zugriff definiert, typischerweise für HTTP und HTTPS (Layer 7).

Ingress fungiert als zentraler Eintrittspunkt und ermöglicht anspruchsvolles Routing basierend auf Hostnamen und URL-Pfaden. Dieser Ansatz ist unerlässlich für die Verwaltung mehrerer Services hinter einer einzigen IP-Adresse.

Die Rolle des Ingress Controllers

Damit Ingress-Regeln funktionieren, müssen Sie zuerst einen Ingress Controller (z. B. Nginx, Traefik, Istio) bereitstellen. Der Controller beobachtet die Ingress-Ressourcendefinitionen und konfiguriert basierend auf diesen Regeln einen zugrunde liegenden Reverse-Proxy/L7-Load-Balancer.

Entscheidend ist, dass der Ingress Controller selbst normalerweise über einen einzigen LoadBalancer- oder NodePort-Service exponiert wird.

Erweiterte Funktionen von Ingress

Ingress glänzt, wenn Sie erweiterte Traffic-Management-Funktionen benötigen:

  1. Kostenoptimierung: Verwenden Sie einen einzigen Cloud-Load-Balancer (zur Exposition des Controllers) anstelle eines Load-Balancers pro Anwendungsservice.
  2. Virtuelles Hosting: Leiten Sie Traffic basierend auf Hostnamen weiter (api.example.com geht zu Service A; www.example.com geht zu Service B).
  3. Pfadbasiertes Routing: Leiten Sie Traffic basierend auf URL-Pfaden weiter (/v1/users geht zu Service A; /v2/posts geht zu Service B).
  4. SSL/TLS-Terminierung: Verwalten und entschlüsseln Sie Zertifikate zentral.

Ingress-Ressourcen-Beispiel

Dieses Beispiel leitet Traffic für api.example.com/v1 an den my-api-v1-Service weiter.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: nginx # Den verwendeten Controller angeben
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: my-api-v1
            port:
              number: 80
  # ... weitere Regeln für andere Services/Hosts

4. Vergleich und Auswahlhilfe

Die Wahl der optimalen Methode beinhaltet die Abwägung von Faktoren wie Umgebung, Komplexität, Funktionsumfang und Betriebskosten.

Vergleichstabelle der Funktionen

Merkmal NodePort LoadBalancer Ingress
Ebene L4 (TCP/UDP) L4 (TCP/UDP) L7 (HTTP/S)
Stabilität (IP) Instabil (verwendet Knoten-IP) Stabil (Dedizierte Cloud-IP) Stabil (verwendet IP des Controllers)
Kosten Gering (Operativer Overhead hoch) Hoch (Ressourcenkosten pro Service) Moderat (Ein LoadBalancer für den Controller)
Routing-Logik Einfache Portweiterleitung Einfache Portweiterleitung Hostname, Pfad, SSL-Terminierung
Cloud-Abhängigkeit Keine Hoch Hoch (benötigt Controller, der durch LoadBalancer exponiert wird)
Produktionsreif Nein Ja (Einfache Apps) Ja (Komplexe Apps)

Entscheidungskriterien: Wahl Ihrer Expositionsmethode

  1. Nur für interne oder Testzwecke: Wenn Sie einfach nur die Konnektivität innerhalb Ihres Clusters testen müssen oder wenn Sie das externe Netzwerk selbst verwalten (z. B. in einer Bare-Metal-Umgebung), verwenden Sie NodePort.

  2. Für einfache, dedizierte L4-Exposition: Wenn Ihre Anwendung Nicht-HTTP-Protokolle (wie benutzerdefinierte TCP-Protokolle oder UDP) verwendet oder wenn Sie nur eine einzige öffentliche Anwendung haben, die sofortigen, dedizierten L4-Zugriff benötigt, verwenden Sie LoadBalancer.

  3. Für komplexe L7-Exposition mit mehreren Services: Wenn Sie mehrere Services exponieren müssen, pfad- oder hostnamensbasiertes Routing benötigen, eine zentrale SSL-Terminierung wünschen oder Cloud-Kosten durch die gemeinsame Nutzung einer einzigen externen IP minimieren möchten, verwenden Sie Ingress.

Best Practice: Für Produktionsbereitstellungen in verwalteten Cloud-Umgebungen ist Ingress im Allgemeinen die bevorzugte Wahl. Es bietet die erforderliche Komplexität, zentrale Sicherheit und Kosteneffizienz für die Verwaltung einer wachsenden Anzahl von Microservices.

Fazit

Kubernetes bietet ein Spektrum an Lösungen für die Service-Exposition, das vom grundlegenden L4 NodePort über den Cloud-integrierten L4 LoadBalancer bis hin zu den anspruchsvollen L7-Routing-Fähigkeiten von Ingress reicht. Durch das Verständnis der Betriebsebene, des Kostenmodells und der erforderlichen Routing-Logik jeder Methode können Ingenieure Netzwerktopologien entwerfen, die für ihre Produktions-Workloads skalierbar, sicher und kostengünstig sind.