Expose a Pod as a Service

You've done the hard work of building container images, configuring Pods with health checks, and understanding how they live and die in Kubernetes. Yet a Pod has no stable address—its IP changes on restart, and unless you're debugging inside the cluster, you can't reach it at all. That's where expose a pod as a service comes in. Services are the permanent front door that decouples clients from individual Pods, giving you a stable IP, DNS name, and built-in load balancing.

The problem this lesson solves

Without a Service, a Pod is an island. Clients must know its ephemeral cluster IP (which vanishes on restart) and no load distribution occurs when you scale replicas. Consider a web app Pod running on 10.244.1.5:8080:

• The Node fails → Pod is recreated on 10.244.2.7:8080.
• Any client hard‑coding 10.244.1.5 is now broken.
• Even if you scale to three replicas, each has a different IP — how does a front‑end or ingress reach all of them?

Services solve this exact pain. They provide a stable endpoint (ClusterIP) and a selector that automatically tracks healthy Pods. As Pods come and go, the Service keeps its IP and routes traffic only to ready Pods.

Core concept / mental model

Think of a Kubernetes Service as a virtual IP with a label‑based switchboard. It never runs as a container — it's an API object that programs routing rules into every node's iptables or IPVS. The mental model has two parts:

• Selector – a set of labels the Service watches. Any Pod possessing those labels becomes a backend.
• Endpoints – the actual list of Pod IP + port pairs. The Service controller automatically populates an Endpoints object (or EndpointSlice in newer clusters) behind the scenes.

When a client sends traffic to the Service's ClusterIP, kube‑proxy intercepts it and forwards to one of the live Pods. The client never knows about individual Pod IPs — and doesn't need to.

Pro tip: Services use round‑robin by default when multiple Pods match the selector, giving you basic load balancing without any extra config.

How it works step by step

1. Label the Pod(s) you want to expose

Every Pod you want behind the Service must carry the labels your Service selector will match. For example, a web Pod might have app: web and tier: frontend.

2. Create the Service manifest

The Service YAML defines:

• apiVersion: v1 (Services are core resources)
• kind: Service
• metadata.name – a DNS name for cluster‑internal use
• spec.selector – the labels to match against Pods
• spec.ports – one or more port mappings (port, targetPort, optional nodePort)
• spec.type – ClusterIP (default), NodePort, LoadBalancer, or ExternalName

3. The controller does the rest

Once you apply the YAML:

1. The Service controller creates an Endpoints object with all Pod IPs that match selector and are ready.
2. kube‑proxy on every node updates routing rules so traffic to ClusterIP:port is load‑balanced.
3. If Pods are added or removed, the Endpoints list updates automatically — usually within seconds.

Hands-on walkthrough

We'll create a simple nginx Pod and a Service to expose it. You need a running cluster (minikube or kind works fine).

Step A: Launch a Pod with labels

# pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    ports:
    - containerPort: 80

kubectl apply -f pod-nginx.yaml

Step B: Create the Service

# service-nginx.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: myapp
    tier: frontend
  ports:
  - protocol: TCP
    port: 80         # Service port
    targetPort: 80    # Pod container port
  type: ClusterIP

kubectl apply -f service-nginx.yaml

Step C: Verify everything works

# Check the Service and its ClusterIP
kubectl get svc nginx-svc
# NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
# nginx-svc   ClusterIP   10.96.123.45   <none>        80/TCP    10s

# Inspect the automatically created Endpoints
kubectl get endpoints nginx-svc
# NAME        ENDPOINTS      AGE
# nginx-svc   10.244.1.5:80  10s

# Access the Pod via the Service from a temporary Pod
kubectl run test --image=curlimages/curl --rm -it --restart=Never -- curl http://nginx-svc:80
# Returns nginx welcome page

Expected output: the curl inside the test Pod reaches the nginx welcome page via the service name nginx-svc — no hard‑coded IP needed.

Scaling the backend

Add a second Pod with the same labels and watch the Endpoints list expand:

# pod-nginx-2.yaml (same labels, different name)
apiVersion: v1
kind: Pod
metadata:
  name: nginx-2
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    ports:
    - containerPort: 80

kubectl apply -f pod-nginx-2.yaml
kubectl get endpoints nginx-svc
# NAME        ENDPOINTS                     AGE
# nginx-svc   10.244.1.5:80,10.244.2.8:80   20s

The Service now load‑balances between two nginx Pods.

Compare options / when to choose what

Services offer four type fields. Here's when to use each:

When to choose ClusterIP: This is your default for internal traffic. Use it for backend services, APIs consumed by other Pods, or any workload that doesn't need direct external exposure. Combine with an Ingress if external access is needed later.

Troubleshooting & edge cases

❌ Service created but Endpoints list is empty

Most common cause: selector labels don't match. Check labels on your Pod:

kubectl get pods --show-labels

Then verify the Service selector:

kubectl describe svc nginx-svc | grep -i selector

If they mismatch, edit the Service selector or relabel the Pod.

❌ Curl from inside the cluster times out

• Ensure the Pod's targetPort matches the container's containerPort.
• Verify the Pod is Running and ReadinessProbe passes (if set). Services only forward to ready Pods.
• Test with a temporary Pod in the same namespace: kubectl run tmp --image=busybox -it --rm -- wget -qO- http://nginx-svc.

❌ NodePort not reachable from outside

1. Confirm the NodePort is in range 30000–32767.
2. Check firewall / security groups on the node (cloud VMs often block the high ports).
3. Use the correct node IP, not the pod or service IP: curl <NodeIP>:<NodePort>.

Edge case: Service with no selector

You can create a Service without selector and manually manage an Endpoints object. This is useful for routing traffic to an external resource (e.g., a database running on bare metal).

What you learned & what's next

You now know how to expose a pod as a service: the core concept of a stable virtual IP with label‑based backend selection, how ClusterIP differs from NodePort and LoadBalancer, and how to verify it works with a simple test. You've mastered the key abstraction that every real‑world Kubernetes deployment relies on.

Next step: Now that your app has a stable internal address, the natural progression is to route external traffic with an Ingress controller — a smarter, HTTP‑aware gateway that sits in front of your Service and handles TLS termination, path‑based routing, and virtual hosts.