Dein LoadBalancer ist nicht der einzige Eingang: Der NodePort, den niemand zugemacht hat

Kurze Antwort: Ja, dein LoadBalancer-Service ist in aller Regel auch über einen NodePort erreichbar. Kubernetes vergibt ihn standardmäßig mit, und zwar auf jedem Node. Ob da draußen jemand durchkommt, hängt vor allem an deiner Plattform und deiner Firewall.

Wer das nicht weiß, schließt die Haustür ab und lässt das Kellerfenster auf. Mit Hausnummer dran: irgendwas ab 30000.

Der dritte Eingang

Im Einführungstraining war ein Teilnehmer felsenfest überzeugt: Der LoadBalancer ist der einzige Weg in den Cluster. Tür zu, fertig.

Dann tauchte ein dritter Zugriffsweg auf. Einer, den es laut seinem Plan gar nicht geben durfte.

Die Auflösung: Er hatte die alte NodePort-Variante parallel noch laufen. Damit war seine Anwendung zusätzlich über die externe IP der VM plus NodePort erreichbar. Gewollt hatte das keiner. Zugemacht auch nicht.

Und genau das ist die Gefahr im echten Betrieb: Irgendwo nimmt jemand „mal eben“ einen Service vom Typ NodePort, weil’s schneller geht. Und der bleibt.

Der LoadBalancer bringt seinen NodePort gleich mit

Jetzt wird’s fies. Auch ohne vergessene Altlast hast du einen NodePort. Laut Kubernetes-Doku baut Kubernetes für einen LoadBalancer-Service typischerweise erst mal dasselbe wie für einen NodePort-Service. Der Cloud-Load-Balancer davor schickt den Verkehr dann genau auf diesen Port.

Der NodePort ist also der Lieferanteneingang. Nur kommt durch diese Tür nicht bloß der Lieferant. Wer sonst noch reinkommt, entscheidet vor allem die Firewall vor den Nodes, nicht der Load Balancer. Und diesen Eingang hat nicht nur der Node, auf dem dein Pod läuft. Den hat jeder.

Bei MetalLB ist es noch schräger: MetalLB braucht den Lieferanteneingang gar nicht. Ich habe es im Oktober 2026 noch einmal auf einem kind-Cluster mit Kubernetes 1.37.0 und MetalLB 0.16.0 getestet: Ein Service ohne NodePort ist über die LoadBalancer-IP genauso erreichbar. In der MetalLB-Doku steht dazu aktuell nichts, die Seiten zu Konzepten und Layer 2 sagen nur, dass kube-proxy den Verkehr an die Pods verteilt. Kubernetes baut ihn trotzdem. Standard ist Standard.

NodePort zeige ich im Training, damit das Prinzip sitzt. Dazu sage ich klar: In der Produktion macht der 0,0 Sinn. Keinem Kunden mutest du einen Port jenseits der 30000 zu, der beim Neuanlegen des Service auch noch wechselt, solange du ihn nicht festnagelst. Genau deshalb denkt keiner mehr an ihn. Er ist trotzdem da.

Ob die Tür offen ist, hängt an deiner Plattform

Jetzt kommt der Teil, bei dem ich selbst was gelernt habe. Ich führe im Training den Zugriff über NodePort vor, voller Selbstbewusstsein. Und Teilnehmer melden: Bei uns ging das nie.

Des Rätsels Lösung: die Plattform. Bei DigitalOcean kam über den NodePort des LoadBalancer-Service keiner rein. Bei Vanilla-Kubernetes mit kubeadm und MetalLB sperrt keiner was. So klar war mir das vorher ehrlich gesagt nicht.

DigitalOcean hat nämlich einen Hausmeister. Laut DigitalOcean-Doku legt die Plattform für jeden Cluster eigene Firewalls an und verwaltet die Regeln für die NodePorts selbst. Die Lieferantentür eines LoadBalancer-Service lässt der Hausmeister zu, der Load Balancer kommt ja übers private Netz rein. Hängst du aber ein Schild „Service vom Typ NodePort“ an eine Tür, macht er dir die brav auf. Für alle.

Bei kubeadm gibt es keinen Hausmeister. Weder kubeadm noch MetalLB machen dir irgendeine Firewall zu. Steht keine vor den Nodes, ist die Tür offen. Der Hausmeister bist du.

Das Gemeine daran: Wer auf einer Plattform lernt, die den NodePort des LoadBalancers zumacht, hält ihn für harmlos. Und nimmt das mit in den eigenen Cluster, wo keiner abschließt.

Abschalten, aber richtig

Klar, es gibt einen Schalter dafür: spec.allocateLoadBalancerNodePorts: false. Dann bekommen die Ports des LoadBalancer-Service keinen NodePort mehr. Problem gelöst? Denkste.

Der Schalter ist laut Kubernetes-Doku nur für Load Balancer gedacht, die ohne NodePorts auskommen. MetalLB ist so einer, das steht schon im ursprünglichen Kubernetes-Vorschlag zu dem Feld. Was für deinen Cloud-Load-Balancer gilt, steht in der Doku deiner Plattform. Nicht in deinem Bauchgefühl.

Bei einem neuen Service gibst du den Schalter gleich mit, dann entsteht gar kein NodePort:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer
  allocateLoadBalancerNodePorts: false
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

Und jetzt die eigentliche Falle. Du legst den Schalter bei einem Service um, der schon läuft? Dann bleiben seine NodePorts einfach stehen. Den nodePort-Eintrag musst du in jedem Port selbst rauswerfen. Sonst ist der Lichtschalter aus, und die Lampe brennt weiter. Du meinst, du hast es abgeschaltet. Hast du nicht.

So wirst du einen vorhandenen NodePort los: Schalter setzen und den nodePort-Eintrag jedes Ports entfernen. Bei mehreren Ports brauchst du pro Port einen Eintrag, statt 0 steht dann 1, 2 und so weiter.

kubectl patch svc web --type=json \
  -p '[{"op":"remove","path":"/spec/ports/0/nodePort"}]'

Das gilt auch, wenn du einen NodePort-Service auf LoadBalancer umstellst. Das habe ich im Oktober 2026 ebenfalls auf einem kind-Cluster mit Kubernetes 1.37.0 getestet:

Mit kubectl apply allein klappt das nicht, wenn dein Manifest den nodePort nie enthielt. Dann steht er nur im Cluster, und apply lässt ihn in Ruhe. Bei meinem Nachbau war der alte Port nach dem Entfernen wenige Sekunden später zu. kube-proxy gleicht die Regeln nicht sofort ab.

So findest du deine offenen NodePorts

Glaub nicht deinem Konzept, schau nach. Erst die Liste: Welche Services haben überhaupt einen NodePort?

kubectl get svc -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,NODEPORTS:.spec.ports[*].nodePort'

Steht bei NODEPORTS eine Zahl, ist das ein möglicher Eingang. Egal, ob daneben NodePort oder LoadBalancer steht. Ob er wirklich offen ist, zeigt dir erst der nächste Schritt.

Dann der Test von außen. Nimm einen Rechner außerhalb des Clusters. Also da, wo auch ein Angreifer stünde. Probier die externe IP eines Nodes plus Port: curl http://<node-ip>:<nodeport>/. Antwortet deine Anwendung, ist die Tür offen. Egal, was im Konzept steht.

Danach aufräumen. Vergessene NodePort-Services löschen. allocateLoadBalancerNodePorts: false setzen, wo dein Load Balancer das hergibt, und die alten Einträge gleich mit rauswerfen. Und in deiner eigenen Firewall vor den Nodes den Bereich 30000 bis 32767 für alles zumachen, was nicht dein Load Balancer ist. Verwaltet die Plattform die Firewall selbst, wie DigitalOcean, gilt deren Doku.

Meine klare Ansage

Ein LoadBalancer-Service ist ein Eingang mit Hintertür, bis du das Gegenteil geprüft hast. Zählen tut nicht, was im Konzept steht, sondern was von außen antwortet.

Wie Services, NodePorts und MetalLB zusammenspielen und wo die Löcher sitzen, schauen wir uns im Kubernetes Networking Training am Live-Cluster an.