Introduction

A Kubernetes NodePort service exposes an application on the IP address of every node using a fixed port. If you need a specific port instead of one assigned automatically, set spec.ports[].nodePort explicitly in the Service manifest.

Define the Service as NodePort

A NodePort service needs three important pieces:

• 'type: NodePort'
• a service port exposed inside Kubernetes
• a chosen nodePort value inside the cluster's allowed range

1apiVersion: v1
2kind: Service
3metadata:
4  name: demo-web
5spec:
6  type: NodePort
7  selector:
8    app: demo-web
9  ports:
10    - protocol: TCP
11      port: 80
12      targetPort: 8080
13      nodePort: 30080

Apply it with kubectl apply -f service.yaml, then verify it:

kubectl get service demo-web
kubectl describe service demo-web

Traffic sent to node-ip:30080 is forwarded to the matching pods on container port 8080.

Know the Port Mapping

The three ports in the manifest have different jobs:

• 'targetPort is the port your container actually listens on'
• 'port is the port exposed inside the cluster for clients using the Service name'
• 'nodePort is the port opened on every node for external access'

Confusing these values is a common source of broken connectivity. If the pod listens on 8080, then setting only port: 80 does not magically change the container. targetPort must still match the application.

The Port Must Be Allowed by the Cluster

By default, Kubernetes reserves a range such as 30000 through 32767 for NodePort values. The API server can be configured differently, but most clusters keep the default range.

If you request a port outside the allowed range, the Service creation fails. If you request a port already in use by another NodePort service, the API server also rejects it.

That means the safest workflow is:

• choose a port in the cluster's NodePort range
• make sure no existing service already uses it
• apply the manifest and verify with kubectl get svc -A

End-to-End Example

Assume you already have a deployment running an HTTP app on 8080.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: demo-web
5spec:
6  replicas: 2
7  selector:
8    matchLabels:
9      app: demo-web
10  template:
11    metadata:
12      labels:
13        app: demo-web
14    spec:
15      containers:
16        - name: web
17          image: nginx:1.27
18          ports:
19            - containerPort: 8080

If the container really serves traffic on 8080, the earlier Service manifest exposes it externally on 30080. You can then test with:

curl http://NODE_IP:30080

If the request fails, inspect the pod, service, and endpoints rather than assuming the NodePort itself is wrong.

When NodePort Is the Right Choice

NodePort is most useful in simple environments:

• local clusters such as Minikube or Kind
• lab environments
• bare-metal setups with an external reverse proxy
• debugging situations where you want a predictable node-level port

For production internet traffic, LoadBalancer or Ingress is usually a better abstraction. Those options handle routing and edge concerns more cleanly than exposing a raw port on every node.

Firewall and Network Rules Still Matter

Kubernetes opening the service does not guarantee the port is reachable from your laptop. Node firewalls, cloud security groups, on-prem network ACLs, or corporate VPN rules can still block the traffic.

In cloud environments, confirm both levels:

• Kubernetes has created the NodePort service
• the infrastructure firewall allows inbound traffic to that node port

If one is missing, the application remains inaccessible.

Common Pitfalls

The most common mistake is setting nodePort correctly but leaving targetPort wrong. The Service exists, but traffic goes nowhere useful.

Another mistake is assuming NodePort exposes the application on only one node. It opens the chosen port on every node in the cluster.

Teams also forget infrastructure firewalls. A correct manifest does not override cloud security groups or host firewalls.

Finally, avoid choosing NodePort for internet-facing production traffic by default. It works, but it is usually not the cleanest or safest exposure model.

Summary

• Set type: NodePort and specify spec.ports[].nodePort to choose the exact port.
• Keep port, targetPort, and nodePort conceptually separate.
• Use a value inside the cluster's allowed NodePort range.
• Verify both Kubernetes objects and external firewall rules.
• Prefer LoadBalancer or Ingress for most production-facing workloads.