Chapter 19: Kubernetes Services, Ingress and Volumes

19.3 NodePort — a port on the node, for a lab

By Ravindra Bagale · Last updated: 25 October 2026

Why: the problem

You built an app on a kind cluster and want to open it in your browser. A ClusterIP will not work, because your laptop is outside the cluster. The fastest way out is a NodePort Service. Kubernetes opens the same port, from 30000 to 32767, on every node. Any traffic that reaches that port on any node is sent to the Service and then to a Pod. On a small lab, on bare-metal servers, or behind your own load balancer, this is enough. But it has limits: odd port numbers, you must know a node IP, and if that node dies the address dies with it. That is why public apps at companies like Flipkart use a LoadBalancer or an Ingress in front. In this lesson you will create a NodePort, reach it from your laptop through kind, pick a fixed port, and see that every node answers, even one with no Pod.

What we will build

You will make a kind cluster with a port mapping, expose the whoami Pods as a NodePort on port 30080, open it from your laptop with curl, and check that every node answers.

What: every term in plain English

• NodePort — A Service type that opens one port on every node.
• Port range — By default NodePorts use 30000 to 32767.
• nodePort — The port on the node. You can set it or let Kubernetes pick.
• extraPortMappings — A kind setting that maps a laptop port to a port on a node container.
• externalTrafficPolicy — Cluster (default) sends traffic to any node's Pods; Local only to Pods on the node that got the traffic.
• Source IP — The IP of the real client. Cluster policy hides it; Local keeps it.

How: step by step

1. Write a kind config with a port mapping

   cat kind-np.yaml
   

   What it does: Maps laptop port 30080 to node port 30080.

   Output

   kind: Cluster
   apiVersion: kind.x-k8s.io/v1alpha4
   nodes:
   - role: control-plane
     extraPortMappings:
     - containerPort: 30080
       hostPort: 30080
   - role: worker
   

2. Create the cluster

   kind create cluster --name lab --config kind-np.yaml
   

   What it does: Two nodes; the control plane forwards 30080.

   Output

   Set kubectl context to "kind-lab"
   

3. Run the whoami Deployment

   kubectl apply -f who.yaml && kubectl rollout status deploy/who
   

   What it does: Same three Pods as lesson 19.1.

   Output

   deployment "who" successfully rolled out
   

4. Create the NodePort Service

   kubectl apply -f who-np.yaml && kubectl get svc who-np
   

   What it does: The PORT(S) column shows 80:30080.

   Output

   NAME     TYPE       CLUSTER-IP     PORT(S)        AGE
   who-np   NodePort   10.96.33.7     80:30080/TCP   2s
   

5. Open it from your laptop

   curl -s localhost:30080 | grep Hostname
   

   What it does: Laptop to node port to Service to Pod.

   Output

   Hostname: who-6c8f7d9b5-9xw7m
   

Example 1: A NodePort Service with a fixed port

Stack. kind, Kubernetes 1.30

Goal. A NodePort Service with a fixed port.

who-np.yaml

apiVersion: v1
kind: Service
metadata:
  name: who-np
spec:
  type: NodePort
  selector:
    app: who
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080

What each line does

• type: NodePort — Open a port on every node.
• port: 80 — The ClusterIP port. A NodePort is also a ClusterIP.
• targetPort: 80 — The Pod port.
• nodePort: 30080 — The fixed node port. Leave it out to get a random one.

Green output

$ kubectl describe svc who-np | grep -E "Type|NodePort|Endpoints"
Type:                     NodePort
NodePort:                 unset  30080/TCP
Endpoints:                10.244.1.4:80,10.244.1.5:80,10.244.1.6:80

Expected result. The Service now listens on port 30080 of every node.

Example 2: Every node answers, even without a Pod on it

Stack. kube-proxy, Docker network kind

Goal. Every node answers, even without a Pod on it.

terminal

kubectl get pods -o wide -l app=who
CP=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' lab-control-plane)
W=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' lab-worker)
docker run --rm --network kind curlimages/curl:8.8.0 -s $CP:30080 | grep Hostname
docker run --rm --network kind curlimages/curl:8.8.0 -s $W:30080 | grep Hostname

What each line does

• get pods -o wide — All Pods run on lab-worker (the control plane is tainted).
• docker inspect ... IPAddress — Gets each node container IP.
• --network kind — Runs curl on the same Docker network as the nodes.
• $CP:30080 — The control plane has no who Pod but still answers.

Green output

NAME                  NODE
who-6c8f7d9b5-4kq2x   lab-worker
who-6c8f7d9b5-9xw7m   lab-worker
who-6c8f7d9b5-tm2zr   lab-worker
Hostname: who-6c8f7d9b5-tm2zr
Hostname: who-6c8f7d9b5-4kq2x

Expected result. Both nodes answer. kube-proxy forwards the traffic to a Pod on another node.

Example 3: Keep the real client IP with externalTrafficPolicy: Local

Stack. Service externalTrafficPolicy

Goal. Keep the real client IP with externalTrafficPolicy: Local.

terminal

kubectl patch svc who-np -p '{"spec":{"externalTrafficPolicy":"Local"}}'
docker run --rm --network kind curlimages/curl:8.8.0 -s -m 3 $CP:30080 || echo "no local Pod on control plane"
docker run --rm --network kind curlimages/curl:8.8.0 -s $W:30080 | grep -E "Hostname|RemoteAddr"

What each line does

• externalTrafficPolicy: Local — Only Pods on the receiving node serve the traffic.
• $CP:30080 — No Pod there, so the call fails.
• $W:30080 — A local Pod answers.
• RemoteAddr — Now shows the real client IP, not a node IP.

Green output

service/who-np patched
no local Pod on control plane
Hostname: who-6c8f7d9b5-9xw7m
RemoteAddr: 172.18.0.5:51234

Expected result. Local keeps the client IP and avoids an extra hop, but nodes without Pods stop answering. Cloud load balancers use health checks to skip those nodes.

Verify: did it work?

1. Check the NodePort

   kubectl get svc who-np -o jsonpath="{.spec.ports[0].nodePort}"
   

   What it does: Prints the node port.

   Output

   30080
   

2. Check the policy

   kubectl get svc who-np -o jsonpath="{.spec.externalTrafficPolicy}"
   

   What it does: Prints Local after Example 3.

   Output

   Local
   

When it is red 1

The Service "who-np" is invalid: spec.ports[0].nodePort: Invalid value: 8080: provided port is not in the valid range. The range of valid ports is 30000-32767

Cause. You picked a nodePort outside the allowed range.

Fix, step by step

1. Use a port between 30000 and 32767.
2. Or leave nodePort out to get a random one.

When it is red 2

curl: (7) Failed to connect to localhost port 30080

Cause. The kind cluster was created without extraPortMappings.

Fix, step by step

1. Delete the cluster.
2. Create it again with kind-np.yaml.
3. Or use kubectl port-forward svc/who-np 8080:80.

When it is red 3

provided port is already allocated

Cause. Another Service already uses that nodePort.

Fix, step by step

1. Run kubectl get svc -A | grep 30080.
2. Pick another port.

Cleanup

1. Delete the Service

   kubectl delete svc who-np
   

   What it does: Closes the node port on all nodes.

   Output

   service "who-np" deleted
   

2. Delete the lab cluster

   kind delete cluster --name lab
   

   What it does: Removes the whole cluster container. On minikube use: minikube delete.

   Output

   Deleting cluster "lab" ...
   Deleted nodes: ["lab-control-plane"]
   

Practice tasks

Homework: try at home

Recap

• NodePort opens one port (30000-32767) on every node.
• Any node forwards to a ready Pod.
• A NodePort Service is also a ClusterIP Service.
• externalTrafficPolicy Local keeps the client IP but needs a Pod on that node.
• Good for labs and bare metal; use LoadBalancer or Ingress for public apps.

FAQ

Can I use port 80 as a NodePort?

Not by default. The range is 30000-32767. Use Ingress or a load balancer for port 80.

Do I need a security group rule?

Yes on AWS, for the NodePort range or the one port.

What is the difference from port-forward?

port-forward is a temporary tunnel from your laptop. NodePort is a real open port on nodes.

Which node IP should I use?

Any node. Better, put a load balancer in front of all of them.

Does a LoadBalancer use NodePorts?

Yes, by default the cloud load balancer sends traffic to the NodePort on each node.

Interview questions

1. What is a NodePort Service?

   A Service that opens the same high port on every node and forwards it to the Service's Pods.

2. What is externalTrafficPolicy?

   Cluster sends traffic to any Pod and hides the client IP; Local sends only to local Pods and keeps the client IP.

3. Why is NodePort rarely used for production web apps?

   Non-standard ports, no TLS, single-node addressing; LoadBalancer or Ingress is better.

4. How does a LoadBalancer relate to NodePort?

   A LoadBalancer Service builds on NodePort; the cloud LB targets those node ports.

5. How do you reach a ClusterIP Service from your laptop for debugging?

   kubectl port-forward svc/NAME LOCAL:PORT.

Samajla ka?

Ravi Sir's Cards for this lesson

Revision cardInterview card

मराठी cards