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

Kubernetes vergibt temporäre IPs an Pods und verwendet dann Services, um einen stabilen Zugriff auf sie zu ermöglichen. Innerhalb des Clusters ist ein normaler ClusterIP-Service oft ausreichend. Die Frage wird interessanter, wenn etwas außerhalb des Clusters eine Verbindung herstellen muss.

Die drei am häufigsten genannten Begriffe sind NodePort, LoadBalancer und Ingress. Sie sind verwandt, aber nicht austauschbar. NodePort öffnet einen Port auf jedem Knoten. LoadBalancer fordert vom Infrastrukturanbieter einen externen Load Balancer an. Ingress definiert HTTP-Routing-Regeln und benötigt einen Ingress-Controller, um diese Regeln umzusetzen.

1. Service-Expositionstyp: NodePort

Der NodePort-Servicetyp ist die einfachste und grundlegendste Methode, einen Service extern verfügbar zu machen. Wenn Sie einen Service als NodePort definieren, öffnet Kubernetes einen bestimmten statischen Port auf jedem Knoten im Cluster. Jeglicher Datenverkehr, der auf diesen Port auf einem beliebigen Knoten gerichtet ist, wird direkt an den Service weitergeleitet.

Wie NodePort funktioniert

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

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

Anwendungsfälle und Einschränkungen

Merkmal	Beschreibung
Anwendungsfall	Entwicklungs-, Testumgebungen oder wenn externes Load Balancing von einem externen, nicht in der Cloud befindlichen Gerät übernommen wird.
Komplexität	Sehr gering.
Kosten	Null (wenn man die zugrunde liegenden VM-Kosten ignoriert).
Einschränkung	Erfordert manuelle Verwaltung 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: NodePort angeben, sonst wird automatisch einer ausgewählt
      # nodePort: 30001

Warnung: NodePort macht den Service über Knoten-IPs und einen hohen Port zugänglich. Es kann hinter einem eigenen externen Load Balancer nützlich sein, insbesondere auf Bare Metal, ist aber als öffentliche Schnittstelle für eine Produktions-Webanwendung umständlich.

2. Service-Expositionstyp: LoadBalancer

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

Wenn ein Service als LoadBalancer definiert wird, fordert Kubernetes die Load-Balancer-Integration des Clusters auf, einen externen Load Balancer bereitzustellen. In verwalteten Cloud-Clustern bedeutet das oft einen Cloud-L4-Load-Balancer. In Bare-Metal-Clustern könnte es ein Projekt wie MetalLB oder eine andere lokale Integration bedeuten. Das Ergebnis ist in der Regel eine stabile externe Adresse, die Datenverkehr an den Service weiterleitet.

Cloud-Provider-Integration

Das entscheidende Unterscheidungsmerkmal von LoadBalancer ist die tiefe Integration in die zugrunde liegende Cloud-Infrastruktur. Der Cloud-Provider übernimmt den Lebenszyklus des Load Balancers, die Health Checks und das Routing.

Anwendungsfälle und Kostenauswirkungen

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 (konfigurationsseitig).
Kosten	In Cloud-Umgebungen oft höher, da jeder Service eine separate Load-Balancer-Ressource erstellen kann.
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 (im Service-Status sichtbar), 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 HTTP und HTTPS (Layer 7).

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

Die Rolle des Ingress-Controllers

Damit Ingress-Regeln funktionieren, müssen Sie zunächst einen Ingress-Controller bereitstellen, z. B. ingress-nginx, Traefik, HAProxy oder einen Cloud-Provider-Controller. Service Meshes wie Istio können ebenfalls Gateway-ähnliches Traffic-Management bieten, sind aber nicht dasselbe wie die grundlegende Kubernetes-Ingress-API.

Der Ingress-Controller selbst wird in der Regel über einen einzelnen LoadBalancer- oder NodePort-Service verfügbar gemacht.

Erweiterte Funktionen von Ingress

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

Kostenoptimierung: Verwenden Sie einen einzigen Cloud-Load-Balancer (um den Controller verfügbar zu machen), anstatt einen Load-Balancer pro Anwendungsdienst.
Virtuelles Hosting: Leiten Sie Datenverkehr basierend auf Hostnamen weiter (api.example.com geht an Dienst A; www.example.com geht an Dienst B).
Pfadbasiertes Routing: Leiten Sie Datenverkehr basierend auf URL-Pfaden weiter (/v1/users geht an Dienst A; /v2/posts geht an Dienst B).
SSL/TLS-Terminierung: Verwalten Sie Zertifikate und Entschlüsselung zentral.

Beispiel für eine Ingress-Ressource

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

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

4. Vergleich und Auswahlhilfe

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

Funktionsvergleichstabelle

Merkmal	NodePort	LoadBalancer	Ingress
Schicht	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	Niedrig (Hoher Betriebsaufwand)	Hoch (Ressourcenkosten pro Dienst)	Mittel (Ein LoadBalancer für den Controller)
Routing-Logik	Einfache Portweiterleitung	Einfache Portweiterleitung	Hostname, Pfad, SSL-Terminierung
Cloud-Abhängigkeit	Keine	Hängt von der Provider-Integration ab	Hängt vom Controller und der Expositionsmethode ab
Produktionstauglich	Manchmal, normalerweise hinter einem anderen Load Balancer	Ja für einfache L4-Exposition	Ja für HTTP/S-Routing

Entscheidungskriterien: Auswahl Ihrer Expositionsmethode

Nur für interne Zwecke oder Tests: Wenn Sie lediglich die Konnektivität innerhalb Ihres Clusters testen müssen oder wenn Sie das externe Networking selbst verwalten (z. B. in einer Bare-Metal-Umgebung), verwenden Sie NodePort.
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.
Für komplexe, Multi-Service-L7-Exposition: Wenn Sie mehrere Dienste verfügbar machen müssen, pfadbasiertes oder Hostname-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.

Für viele Produktions-HTTP/S-Anwendungen ist Ingress die übliche Wahl, da es Zertifikate und Routing zentralisiert. Für Datenbanken, Message Broker, Spieleserver, reine TCP-Dienste oder alles, was nicht wirklich HTTP ist, kann ein LoadBalancer-Service klarer sein. Für Bare-Metal-Cluster kann NodePort immer noch Teil des Designs sein, wird aber normalerweise hinter einem geeigneten externen Load Balancer oder einer Firewall-Regel platziert.

Wie sie in echten Clustern zusammenpassen

Ein verwirrender Aspekt ist, dass diese Optionen übereinander gestapelt werden können. Ein Ingress-Objekt setzt selbst keine Pakete frei. Der Controller empfängt Datenverkehr auf irgendeine Weise, und dieses "Irgendwie" ist in einem Cloud-Cluster oft ein LoadBalancer-Service:

Internet
  -> Cloud Load Balancer
  -> Service type LoadBalancer für ingress-nginx
  -> Ingress-Controller-Pods
  -> Ingress-Regel
  -> ClusterIP-Service
  -> Anwendungs-Pods

Auf Bare Metal könnte der Pfad stattdessen NodePort verwenden:

Internet oder Büronetzwerk
  -> Externer Load Balancer / Firewall
  -> NodeIP:NodePort
  -> Ingress-Controller-Pods
  -> Anwendungs-Service

Deshalb ist die Aussage "Verwenden Sie Ingress anstelle von LoadBalancer" etwas ungenau. Ingress verwendet oft immer noch einen Load Balancer, ermöglicht aber vielen HTTP-Anwendungen, einen einzigen Einstiegspunkt zu teilen.

Praktische Beispiele

Verwenden Sie NodePort, wenn Sie einen Labor-Cluster debuggen, einen Service vorübergehend für ein privates Netzwerk verfügbar machen oder in eine von Ihnen bereits verwaltete Load-Balancing-Hardware integrieren. Lassen Sie Benutzer nicht https://app.example.com:31427 merken, es sei denn, es handelt sich wirklich um ein internes Tool.

Verwenden Sie LoadBalancer, wenn ein Dienst eine stabile externe Adresse benötigt und L4-Weiterleitung ausreicht. Eine öffentliche TCP-API, ein UDP-Dienst oder ein einzelner interner Admin-Endpunkt können auf diese Weise einfacher sein. Es ist auch nützlich, wenn das Anwendungsprotokoll nicht in das normale HTTP-Host/Pfad-Routing passt.

Verwenden Sie Ingress, wenn Sie Webanwendungen haben. Wenn api.example.com, docs.example.com und app.example.com alle im selben Cluster leben, gibt Ihnen Ingress einen Ort, um Host-Routing und TLS zu verwalten. Fügen Sie cert-manager hinzu, und die Zertifikatserneuerung kann zu einem normalen Cluster-Workflow werden, anstatt zu einer manuellen Serveraufgabe.

Sicherheits- und Betriebsprüfungen

Das Expositionsobjekt ist nur ein Teil der Produktionsentscheidung. Sie müssen auch fragen, wer den Endpunkt erreichen kann, wo TLS terminiert wird, wie Quell-IPs erhalten bleiben und wie Fehler beobachtet werden.

Überprüfen Sie bei NodePort sorgfältig die Firewall-Regeln. Kubernetes öffnet möglicherweise den Port auf jedem Knoten, aber Ihr Netzwerk entscheidet immer noch, ob die Außenwelt ihn erreichen kann. In Cloud-Umgebungen müssen Sicherheitsgruppen oder Firewall-Regeln oft den NodePort-Bereich zulassen. Auf Bare Metal kann dieselbe Sorge in einer Perimeter-Firewall liegen. Wenn Sie beabsichtigen, dass ein privates Admin-Tool nur über ein VPN erreichbar ist, erzwingen Sie dies sowohl außerhalb als auch innerhalb von Kubernetes.

Überprüfen Sie bei LoadBalancer die providerspezifischen Annotationen. Sie steuern oft, ob der Load Balancer intern oder internetgerichtet ist, welches Protokoll er verwendet, welchen Health-Check-Pfad er prüft und ob er die Client-Quell-IP beibehält. Diese Details variieren je nach Anbieter, gehen Sie also nicht davon aus, dass ein aus einer Cloud kopiertes Manifest sich in einer anderen gleich verhält.

Bei Ingress verlagert sich der Betriebsschwerpunkt auf den Controller. Sie benötigen Protokolle und Metriken von den Controller-Pods, nicht nur von den Anwendungs-Pods. Wenn eine Route fehlschlägt, können der Service und die Pods gesund sein, während der Controller die Regel abgelehnt hat, die falsche Ingress-Klasse verwendet hat, ein TLS-Geheimnis verpasst hat oder an den falschen Backend-Pfad weitergeleitet hat. Eine schnelle Checkliste hilft:

kubectl get ingress
kubectl describe ingress example-ingress
kubectl get svc -n ingress-nginx
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

Seien Sie auch klar in Bezug auf TLS. Ingress terminiert HTTPS häufig am Controller und sendet HTTP an den Backend-Service. Das ist für viele interne Cluster in Ordnung, aber einige Teams verlangen eine Verschlüsselung bis zum Anwendungs-Pod. Wenn das Ihre Anforderung ist, konfigurieren Sie Backend-TLS absichtlich, anstatt anzunehmen, dass Ingress es automatisch bereitstellt.

Häufige Fehlermodi

Wenn ein NodePort von einem Knoten, aber nicht von einem anderen funktioniert, überprüfen Sie, ob kube-proxy oder das Cluster-CNI auf dem fehlerhaften Knoten gesund ist. Überprüfen Sie auch, ob die externe Firewall Datenverkehr zu jeder Knoten-IP zulässt, die Sie verwenden möchten.

Wenn ein LoadBalancer-Service im Status Pending bleibt, kann der Cluster wahrscheinlich keinen externen Load Balancer bereitstellen. In verwaltetem Kubernetes kann dies bedeuten, dass die Cloud-Controller-Integration, Berechtigungen, Subnetz-Tags, Kontingente oder providerspezifische Einstellungen fehlen. In Bare-Metal-Kubernetes bedeutet es normalerweise, dass keine Load-Balancer-Implementierung installiert ist.

Wenn ein Ingress eine Standard-Backend-Seite oder einen 404 vom Controller zurückgibt, hat die Anfrage den Controller erreicht, aber Ihre Host- oder Pfadregel nicht getroffen. Überprüfen Sie DNS, den Host-Header, ingressClassName, den Pfadtyp und ob der Service-Name und -Port korrekt sind. Wenn Sie ein TLS-Zertifikat für den falschen Hostnamen erhalten, überprüfen Sie das vom Ingress referenzierte Secret und ob eine andere Ingress-Regel denselben Host beansprucht.

Eine einfache Entscheidungsabkürzung

Beginnen Sie mit dem Protokoll. Wenn es sich um HTTP oder HTTPS handelt und mehr als eine App möglicherweise irgendwann den Einstiegspunkt teilt, verwenden Sie Ingress. Wenn es sich um reines TCP oder UDP handelt und eine stabile externe Adresse benötigt wird, verwenden Sie LoadBalancer. Wenn Sie testen, in Ihre eigene Netzwerkausrüstung integrieren oder einen Bare-Metal-Pfad aufbauen, kann NodePort Teil der Antwort sein.

Überprüfen Sie dann das Betriebsmodell. Ein kleines Team, das eine einzige öffentliche API betreibt, bevorzugt möglicherweise einen LoadBalancer, weil er offensichtlich und einfach zu debuggen ist. Ein Plattformteam, das Dutzende von Webdiensten hostet, wird normalerweise Ingress bevorzugen, weil gemeinsames Routing, Zertifikate und Richtlinien wichtiger sind als die zusätzliche Controllerschicht.

Abschließende Anmerkungen

Wählen Sie basierend auf Protokoll und Betrieb, nicht danach, welches Objekt fortschrittlicher klingt. NodePort ist ein Baustein. LoadBalancer ist unkomplizierter externer L4-Zugriff. Ingress ist HTTP/S-Routing durch einen Controller. In einem kleinen Cluster können alle drei im selben Design vorkommen, und das ist in Ordnung, solange jeder eine klare Aufgabe hat.