Services, Service Types, and Load Balancing

In Kubernetes, a Pod is the smallest deployable unit: it runs your container. But Pods are temporary. They can crash, be deleted, or get rescheduled onto a different worker node, which gives them a new IP address every time. If another Pod or an external user tries to reach a Pod using its IP, it will fail as soon as that Pod moves. A Service solves this by providing a stable, virtual IP address and hostname that never changes, no matter how often the Pods behind it come and go.

A Service is a Kubernetes resource, just like a Pod or a Deployment. You define it in a YAML file. The key fields are the selector (which Pods to target) and the ports (which network port to listen on). The Service continuously watches the cluster for Pods whose labels match the selector. It then updates its internal list of endpoints — the actual IP addresses of the matching Pods. This is called the endpoint slice.

When traffic arrives at the Service's stable IP, the kube-proxy component running on every node intercepts the request and forwards it to one of the healthy Pods. By default, it uses round-robin load balancing, meaning each new connection goes to the next Pod in the list. This spreads the work evenly and prevents one Pod from being overwhelmed.

There are four main Service types, each controlling who can reach the Service:

Why does this matter? Before Services, every time you deployed a new version of your app, the Pod IPs changed, and every client had to update their configuration. Services decouple the client from the Pods. The client only needs to know the Service name. Kubernetes handles the rest: it watches for Pod changes, updates the endpoint list, and forwards traffic to healthy Pods only. This makes your application resilient to failures and rolling updates.

Load balancing is automatic. You do not need to configure a separate load balancer inside the cluster most of the time. kube-proxy handles it using iptables rules or IPVS. However, if you need session affinity (sticky sessions, where the same client always goes to the same Pod), you can set sessionAffinity: ClientIP on the Service.

To see your Services, use kubectl get svc. To describe a Service, use kubectl describe svc my-service. When trouble arises, check that the selector labels match the Pod labels exactly. A common mistake is a typo in the label: kubectl get pods --show-labels helps you verify.

You work as a junior DevOps engineer for 'QuickCart', an e-commerce startup. The team has just containerised the backend API with a Deployment running three replicas. The API listens on port 8080. Management wants the public internet to access it. Here is exactly what you do.

First, you create a LoadBalancer Service. Your YAML looks like this:

apiVersion: v1 kind: Service metadata: name: quickcart-api spec: type: LoadBalancer selector: app: quickcart tier: backend ports: - protocol: TCP port: 80 targetPort: 8080

The selector matches Pods that have both labels app: quickcart and tier: backend. Your Deployment template must include those exact labels. The port 80 is what external clients see; targetPort 8080 is what the Pod actually listens on.

You apply the file: kubectl apply -f service.yaml. Within a minute, the cloud provider (AWS, GCP, or Azure) provisions a load balancer and gives you an external IP. You run kubectl get svc quickcart-api and see the EXTERNAL-IP column populated, for example, 203.0.113.42.

Now you test it. You open a browser and visit http://203.0.113.42. The request hits the load balancer, which forwards it to one of your worker nodes on the NodePort (Kubernetes automatically assigned one, say 31456). The node's kube-proxy intercepts the port 80 traffic (because the LoadBalancer's target is port 80 on the node) and sends it to a healthy Pod running on port 8080. Your API responds.

A week later, you deploy a new version of the API. You update the Deployment image. Kubernetes performs a rolling update. Old Pods are terminated, new Pods start. Their IPs change. But your Service never skips a beat because it constantly watches the Pod labels and updates its endpoints in real time. Users keep accessing http://203.0.113.42 and everything works.

What happens in production? - The cloud load balancer performs health checks by hitting the NodePort on each node. If a node goes down, the load balancer stops sending traffic to it. - kube-proxy on each node maintains iptables rules that rewrite the destination IP from the Service IP to a Pod IP. This is fast and efficient. - If a Pod becomes unhealthy (its readiness probe fails), Kubernetes removes it from the Service's endpoint list. Traffic stops going to it immediately, without manual intervention. - If traffic spikes, you can scale your Deployment to 10 replicas. The Service automatically discovers the new Pods and load balances across them.

You also set up a second Service of type ClusterIP for internal communication between the frontend and the API. The frontend Deployment uses the DNS name quickcart-api.default.svc.cluster.local to reach the API. This never changes, so developers can hard-code it in their config.

When debugging, you use: - kubectl describe svc quickcart-api — shows endpoints and selector. - kubectl get endpoints quickcart-api — lists actual Pod IPs the Service is sending traffic to. - kubectl exec -it some-pod -- curl http://quickcart-api — tests connectivity from within the cluster.

A common real-world issue: you update a Deployment but the selector labels do not match. You wonder why the Service shows no endpoints. You run kubectl get pods --show-labels and compare them to the YAML selector. Once you fix the labels, the endpoint list populates immediately.