Skip to main content

Kubernetes Services Explained: ClusterIP, NodePort & LoadBalancer

Calculating read time…

Imagine you built a brilliant AI model that predicts tomorrow's weather 🌤️. You packed it into a container and deployed it on Kubernetes. Now the big question: how does the world actually talk to your app?

That is exactly what Kubernetes Services solve! Think of a Service like the reception desk of a big apartment building 🏢. No matter which room a person moves to, you always go to reception and say "I want to reach John" — and reception finds John for you.

In Kubernetes, Pods die and restart all the time. Each restart gives a Pod a brand-new IP address. Without a Service, your app breaks every time a Pod restarts. A Service gives a stable, permanent address to reach your Pods — forever.




The Three Types — Big Picture

There are exactly three types of Kubernetes Services:

  • ClusterIP → Private, internal-only. Only things inside the cluster can reach it.
  • NodePort → Opens a port on every Node. Anyone who knows the IP + port can reach it.
  • LoadBalancer → Gets a real cloud IP. The production-grade, internet-facing option.

💡 Think of it like doors to a building: ClusterIP is a private internal door 🔒. NodePort is a side door with a number painted on it 🚪. LoadBalancer is the grand main entrance with a proper address 🏦.

Here is a quick comparison before we dive deep:

  • ClusterIP → Internal only · No external IP · Free · Best for databases and ML models
  • NodePort → Node IP + port · Range 30000–32767 · Free · Best for dev and testing
  • LoadBalancer → Real cloud IP · Any port · Costs cloud money · Best for production apps

Type 1 — ClusterIP (The Private Telephone Line)

Imagine your school has an internal phone system 🏫. You can call any classroom from inside the school — but nobody from outside can dial in. That is exactly what ClusterIP does.

💡 ClusterIP is the default service type in Kubernetes. When you create a Service without specifying a type, you automatically get ClusterIP.

It creates an internal virtual IP address that only things inside the cluster can reach. Perfect for keeping your database or AI model safe from the open internet.

How ClusterIP Works — Step by Step

  1. You deploy your AI model as a Pod inside the cluster.
  2. You create a ClusterIP Service with a YAML file.
  3. Kubernetes assigns a stable virtual IP (like 10.96.0.1) to that Service.
  4. Any other Pod inside the cluster can now reach your model at that IP.
  5. Even if the model Pod restarts with a new IP, the Service IP stays the same. ✅

YAML Example — ClusterIP

# clusterip-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: weather-api-service
spec:
  type: ClusterIP          # this is also the default!
  selector:
    app: weather-ai        # connects to Pods with this label
  ports:
    - protocol: TCP
      port: 80             # port the Service listens on
      targetPort: 8080     # port your Pod is actually running on

kubectl Commands — ClusterIP

# Apply the service
kubectl apply -f clusterip-service.yaml

# View your service
kubectl get svc weather-api-service

Expected output:

NAME                  TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)
weather-api-service   ClusterIP   10.96.0.1    <none>        80/TCP

See the EXTERNAL-IP column says <none>? That means it's safely private. Nobody from outside can reach it. 🔒

✅ DO: Use ClusterIP for all internal services — databases, AI models, caches, auth services. Always start internal and only expose externally when you actually need to.

❌ DON'T: Try to access a ClusterIP from outside the cluster — it simply won't work. Don't expose your database using NodePort or LoadBalancer — ClusterIP keeps it private and safe.

Type 2 — NodePort (The Secret Side Door)

Imagine your apartment building has a secret side door with a specific number painted on it 🚪. Visitors who know that door number can walk in from outside. In Kubernetes, that door number is always between 30000 and 32767.

NodePort opens a specific port on every single Node (server) in your cluster. Anyone from outside who knows the Node IP and the port number can reach your app.

How NodePort Works — Step by Step

  1. You create a Service with type: NodePort in your YAML.
  2. Kubernetes picks a port between 30000–32767 (or you choose one yourself).
  3. Kubernetes opens that port on every Node in the cluster automatically.
  4. It also creates a ClusterIP internally — NodePort builds on top of ClusterIP!
  5. Anyone from outside can now hit: http://<any-node-ip>:30080 ✅

YAML Example — NodePort

# nodeport-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: weather-app-nodeport
spec:
  type: NodePort
  selector:
    app: weather-dashboard
  ports:
    - protocol: TCP
      port: 80           # ClusterIP port (inside cluster)
      targetPort: 8080   # your Pod's actual port
      nodePort: 30080    # external port (must be 30000-32767)

kubectl Commands — NodePort

# Apply the service
kubectl apply -f nodeport-service.yaml

# Get all services
kubectl get svc

# Get node IP address
kubectl get nodes -o wide

# Access from browser or terminal
curl http://<NODE-IP>:30080

# On Minikube — auto-open in browser
minikube service weather-app-nodeport --url

Expected output:

NAME                   TYPE       EXTERNAL-IP   PORT(S)
weather-app-nodeport   NodePort   <none>        80:30080/TCP

The 80:30080 means: internal port 80, external node port 30080. 🎯

⚠️ Important : NodePort is great for development and local testing. Avoid it in production because it exposes Node IPs directly, which is less secure. On cloud environments, always prefer LoadBalancer or Ingress for public traffic.

✅ DO: Use NodePort for local Kubernetes (Minikube, kind) during development. It's great for quick demos, hackathons, or testing your ML model endpoint fast.

❌ DON'T: Use NodePort for internet-facing production apps. Don't expose databases via NodePort — that's a major security risk!

Type 3 — LoadBalancer (The Grand Main Entrance)

Now imagine your apartment building became a 5-star hotel 🏨. Instead of a sketchy side door, you have a grand main entrance with a proper address. A professional traffic manager (the Load Balancer) stands outside and sends visitors evenly across all available staff (Pods).

💡 LoadBalancer gives you a real, stable public IP address provided by your cloud (AWS, GCP, Azure). It smartly distributes traffic across all your Pods. This is the production-grade way to expose your app to the internet..

How LoadBalancer Works — Step by Step

  1. You create a Service with type: LoadBalancer in your YAML.
  2. Kubernetes automatically talks to your cloud provider (AWS, GCP, Azure).
  3. The cloud creates a real Load Balancer (like AWS ELB or GCP GLB) in minutes.
  4. You get a real public IP address (like 203.0.113.42) or a domain name.
  5. All internet traffic flows through that IP → load balancer → your Pods. ✅
  6. Kubernetes also creates a ClusterIP and NodePort internally — LoadBalancer stacks on top of both!

YAML Example — LoadBalancer (Production Style)

# loadbalancer-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: weather-app-lb
  annotations:
    # AWS: use Network Load Balancer for ML workloads (faster)
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  selector:
    app: weather-dashboard
  externalTrafficPolicy: Local   # preserves real client IP in your logs
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 8080
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443

kubectl Commands — LoadBalancer

# Apply the service
kubectl apply -f loadbalancer-service.yaml

# Watch until EXTERNAL-IP is assigned (may take 1-3 minutes on cloud)
kubectl get svc weather-app-lb -w

# Test it once IP appears
curl http://203.0.113.42

Expected output (after cloud provisions the IP):

NAME             TYPE           EXTERNAL-IP    PORT(S)
weather-app-lb   LoadBalancer   203.0.113.42   80:31234/TCP

See the real IP in EXTERNAL-IP? That's your app live on the internet! 🌍

⚠️ Important : Each LoadBalancer Service gets its own cloud IP — which costs money 💰. If you have many services, use one Ingress controller + ClusterIP instead of one LoadBalancer per service. This saves significant cloud costs.

✅ DO: Use LoadBalancer for production internet-facing ML model APIs and web apps. Combine with an Ingress controller to route multiple services under one LoadBalancer. Add readiness probes so the LB only sends traffic to healthy Pods.

❌ DON'T: Create one LoadBalancer per microservice — it will cost a fortune! Don't use LoadBalancer on local clusters without MetalLB — it will stay in "Pending" forever. Don't forget to delete unused LoadBalancer services — cloud providers keep billing you even when nobody uses them.

How the 3 Types Stack on Each Other

Here is something most beginners never realize: these three service types are actually layered on top of each other!

  • ClusterIP → The foundation. Always created. Internal virtual IP.
  • NodePort → Adds a port on every Node, on top of ClusterIP.
  • LoadBalancer → Adds a cloud IP on top of NodePort (which sits on top of ClusterIP).

Think of it like a building 🏗️. The foundation (ClusterIP) is always there. NodePort adds a side entrance on top of that. LoadBalancer adds a grand front entrance on top of everything.

When you create a LoadBalancer Service, Kubernetes automatically creates a NodePort and a ClusterIP behind the scenes. You get all three in one!

Real MLOps Example — All 3 Services Working Together

Let's ground this with a real ML system — an AI weather prediction platform 🌦️. Here is how all three services work together in one production system:

  • User browser → LoadBalancer → Frontend Dashboard Pod
  • Frontend Dashboard → ClusterIP → AI Model API Pod
  • AI Model API → ClusterIP → PostgreSQL Database Pod
  • Dev engineer testing locally → NodePort → Dev/Test API Pod on Minikube

Each service type plays a specific role in a real ML platform:

  • Trained model (inference API) → ClusterIP → Only the frontend should call it
  • Database (PostgreSQL / Redis) → ClusterIP → Never expose a DB to the internet!
  • User-facing web app → LoadBalancer → Needs a real internet-accessible IP
  • Dev / test ML API → NodePort → Quick local access on Minikube or kind
  • Monitoring (Grafana / Prometheus) → ClusterIP → Access internally via kubectl proxy
  • Public ML model API (production) → LoadBalancer → Scale to handle real-world traffic

When Should I Use Which? — Decision Guide

Ask yourself these four questions to pick the right service type every time:

  • Should ONLY Pods inside the cluster reach this? → Yes → Use ClusterIP. Done. ✅
  • Need quick external access for local testing on Minikube? → Yes → Use NodePort. Quick and free. ✅
  • Need a real public IP for production on cloud? → Yes → Use LoadBalancer. Reliable and scalable. ✅
  • Running many services and want to save cloud costs? → Use one LoadBalancer + Ingress to route to many ClusterIP services. This is the recommended pattern. ✅

Practice Challenges — From Beginner to Hero 🏆

You have learned the theory — now get your hands dirty! 💪

🟢 Beginner Challenge

 # Step 1: Start Minikube
minikube start

# Step 2: Run a simple nginx Pod
kubectl run nginx --image=nginx

# Step 3: Expose it as ClusterIP
kubectl expose pod nginx --port=80 --type=ClusterIP

# Step 4: View the service
kubectl get svc nginx

# Step 5: Exec into another Pod and verify
kubectl run test-pod --image=busybox --rm -it -- wget -qO- http://nginx

Confirm you see the nginx welcome page from inside the cluster. ClusterIP works internally! ✅

🟡 Intermediate Challenge

# Expose the same nginx as NodePort
kubectl expose pod nginx --port=80 --type=NodePort --name=nginx-nodeport

# Get the auto-assigned port
kubectl get svc nginx-nodeport

# On Minikube — open in browser automatically
minikube service nginx-nodeport --url

# Compare the two services side by side
kubectl describe svc nginx
kubectl describe svc nginx-nodeport

Open the URL in your browser and see nginx live! Then compare the describe output — notice how NodePort has everything ClusterIP has, plus the extra nodePort field. 🎉

🔵 Advanced Challenge

# On a cloud cluster (AWS EKS / GCP GKE / Azure AKS free tier)

# Create a deployment first
kubectl create deployment weather-model --image=nginx --replicas=3

# Expose as LoadBalancer
kubectl expose deployment weather-model --type=LoadBalancer --port=80

# Watch the cloud provision a real IP (takes 1-3 minutes)
kubectl get svc weather-model -w

# Once EXTERNAL-IP appears, test from your phone browser!
curl http://<EXTERNAL-IP>

When you see a real IP appear and can open it from your phone — congratulations, you just deployed to production! 🚀

The Ultimate Cheat Sheet 📋

One-line commands to expose any deployment:

# ClusterIP (internal only — default)
kubectl expose deployment myapp --type=ClusterIP --port=80

# NodePort (external via node IP)
kubectl expose deployment myapp --type=NodePort --port=80

# LoadBalancer (cloud external IP)
kubectl expose deployment myapp --type=LoadBalancer --port=80

Essential debug commands:

kubectl get svc                    # list all services
kubectl describe svc <name>        # full details of a service
kubectl get svc -w                 # watch for IP changes live
kubectl get endpoints              # see which Pods are targeted
kubectl delete svc <name>          # remove a service
kubectl get nodes -o wide          # get Node IPs for NodePort access

Quick Summary 📝

What we learned today:

  • Why Services exist → Pods get new IPs when they restart. Services give a stable address.
  • ClusterIP → Private, internal only. Default type. Use it for databases, ML models, caches.
  • NodePort → External access via Node IP + port (30000–32767). Use it for dev and testing.
  • LoadBalancer → Real cloud IP. Production-ready. Costs cloud money.
  • They stack → ClusterIP is the base. NodePort adds external port. LoadBalancer adds cloud IP on top.
  • Best practice → Most teams use ClusterIP + one Ingress controller backed by a single LoadBalancer to save cloud costs.

Keep experimenting with your own deployments!. Happy learning! ☸️✨

Labels:

Comments

Post a Comment