NodePort (K8s Service)

YAML:

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  ports:
    - port: 80 (Service Port)
      targetPort: 8080 (Pod Port)
      nodePort: 30007 (Der Port außen!)
  selector:
    app: my-app

Jetzt ist deine App erreichbar unter: http://node1-ip:30007 http://node2-ip:30007 Egal welche Node-IP du nimmst, Kubernetes (kube-proxy) routet es intern richtig weiter.

1. Der High-Port-Bereich

Standardmäßig erlaubt K8s nur Ports 30000-32767. Warum nicht Port 80? Weil Port 80 auf dem Node oft schon vom Ingress Controller oder dem Node-OS belegt ist. Du kannst diesen Bereich im API-Server ändern (--service-node-port-range), aber das führt oft zu Konflikten mit Host-Prozessen.

2. Performance (ExternalTrafficPolicy)

Ein Paket kommt an Node A (Port 30007) an. Der Pod läuft aber auf Node B. Node A muss SNAT machen und das Paket zu Node B schicken. Das kostet 2 Hops und verschleiert die Client-IP. Mit externalTrafficPolicy: Local zwingst du Traffic nur auf Nodes, die den Pod haben. Wenn du Node C (ohne Pod) aufrufst, wird die Verbindung abgelehnt (Connection Refused / Timeout). Dafür hast du auf Node B die echte Client-IP.

3. "Poor Man's Load Balancer"

NodePort ist die Basis für alles andere. Ein Cloud LoadBalancer (type: LoadBalancer) ist technisch nur ein Automatismus, der einen NodePort anlegt und ihn in den AWS LB einträgt. Auch Ingress Controller laufen oft als NodePort Service (NodePort 80/443 über HostNetwork oder MetalLB getunnelt).

1. Kube-Proxy und iptables

Was passiert technisch, wenn du NodePort 30007 anfragst? Ein unsichtbarer Kubernetes-Daemon namens kube-proxy läuft auf jedem Worker-Node. Wenn du den NodePort Service erstellst, schreibt kube-proxy im Hintergrund nackte Linux Netfilter-Regeln (iptables oder IPVS) auf dem Host-OS: iptables -t nat -A PREROUTING -p tcp --dport 30007 -j DNAT --to-destination 10.244.1.5:8080 Trifft ein TCP-Paket am physischen Interface (eth0) des Nodes ein, grätscht der Linux-Kernel tief unten ein, tauscht die Ziel-IP auf das interne Calico/Flannel Pod-Netz aus und routet das Paket in den Container. NodePort ist keine "Software", es sind reine Kernel-Regeln.

2. Das Hairpinning-Dilemma (Loopback)

Stell dir vor, Pod A macht einen CURL auf seinen eigenen NodePort über die externe IP des Nodes. Das Paket verlässt den Pod, erreicht das Node-Interface, wird der iptables DNAT-Regel unterzogen und sofort wieder zum Pod A gespiegelt (Hairpinning). Ohne extra SNAT Source-Regeln sähe Pod A in seinem Socket, dass er selbst sich just angefragt hat (Source-IP = Ziel-IP). Der Return-Traffic würde asymmetrisch failen. Kube-proxy muss bei Hairpinning per "Masquerading" die Source-IP des Senders künstlich umschreiben, damit die Loopback-Netze sauber schließen (Vermeidung des Asymmetric Routing Blackholes).

3. LoadBalancer als Abstraktion

Ein type: LoadBalancer Service (in AWS) ist schlicht ein Wrapper um den NodePort. Erzeugst du den Service, gibt Kubernetes deiner App intern den NodePort 31445. Daraufhin wendet sich der K8s "Cloud Controller Manager" an die AWS API: "Baue mir einen Network Load Balancer und füge absolut jeden EC2-Worker von uns hinter dem NLB ein, routend auf Port 31445". Die "NodePort" Direktive ist also faktisch unausweichlich für physische Inbound-Pfade von Provider-Hardware auf Overlay-Netze.