Service Wiring Basics

When you deploy applications in Kubernetes, you quickly run into a fundamental problem: Pods are temporary. They can be created, destroyed, or rescheduled at any moment, and each time a Pod is created, it gets a new IP address. If your application needs to communicate with other Pods, how can it keep track of constantly changing IP addresses? The answer is Services. A Service provides a stable endpoint — a consistent way to reach a group of Pods, even as those Pods come and go. In this lesson, we'll explore the core mechanism that makes Services work: labels and selectors. This is the foundation that powers all Service types in Kubernetes.

You've already learned about labels — those key-value pairs you attach to Kubernetes objects like Pods. As a quick reminder, labels are tags that describe what a Pod is or what it does (like app: web or tier: frontend). They appear in your Deployment YAML under the Pod template's metadata section, and when a Deployment creates Pods, it stamps each one with the labels you've defined.

Now we'll see how labels become the foundation of Kubernetes networking through selectors. A selector is a set of matching criteria that a Service uses to find Pods. When you create a Service, you specify a selector that describes which labels you're looking for. The Service then continuously queries Kubernetes for all Pods that have matching labels, and it routes traffic to those Pods.

Here's the critical insight: Services are NOT bound to specific Pods. They don't remember individual Pod names or IP addresses. Instead, they dynamically select any Pod that matches their selector criteria. This means if a Pod dies and a new one is created with the same labels, the Service automatically starts routing traffic to the new Pod. If you scale your Deployment up or down, the Service adapts immediately.

The matching process is straightforward. A Service's selector specifies one or more key-value pairs, and a Pod must have ALL of those labels to be selected. For example, if a Service selector says app: wired-demo and tier: web, then only Pods with both of those exact labels will receive traffic from that Service.

Let's see how selectors appear in a Service definition:

apiVersion: v1
kind: Service
metadata:
  name: web-wired
  labels:
    app: wired-demo
spec:
  type: ClusterIP
  selector:
    app: wired-demo
    tier: web
  ports:
    - name: http
      port: 80
      targetPort: 80

The selector section is where the magic happens. This Service is looking for Pods with the labels app: wired-demo AND tier: web. Any Pod that has both of these labels will be included in the Service's routing pool. The Service doesn't care about the Pod's name, its IP address, or when it was created — it only cares about the labels.