Kubernetes Services

Pod - > Deployment - > Services →

Why services ?

what happens

| → Is your your application IP address you to share with your test team you have to share with your other project who is using these applications or thought as server

If No Services Concepts

Here 10 requests are coming from here it will just ok send 10 request here so this is one problem without servies you would have faced.

Application you will not work for certain people when the application goes down

SVC advantage →

1, Load Balancing

2, Services Discovery

3,Expose to external world

Why Do We Need Kubernetes Services?

In Kubernetes, Pods are ephemeral – they come and go, get rescheduled, and their IPs constantly change. So how do we reliably connect to these ever-changing pods?

That’s where Kubernetes Services (SVC) come in.

A Service provides a stable endpoint (IP + DNS name) to access a dynamic set of Pods. It acts as a permanent door to a group of pods that are performing the same function (e.g., all instances of your backend).

Without Services:

• You’d have to track every pod’s IP manually

• No consistent way for internal or external traffic to access your app

With Services:

• Auto-discovery of pods via labels

• Load balancing across healthy pods

• Seamless communication inside and outside the cluster

🛠️ What Happens When You Create a Service?

Here’s the flow when you kubectl apply -f service.yaml:

1. Kubernetes reads your YAML definition.

2. It registers a new Service with a ClusterIP (default type).

3. Behind the scenes, it creates iptables rules (or uses kube-proxy/IPVS) to route traffic from the Service IP to the selected Pods.

4. If the type is NodePort or LoadBalancer, it exposes the service to external users too.

This means you don’t need to worry about pod IPs. Just target the Service name, and Kubernetes handles the rest.

---

Labels and Selectors – The Matchmakers

Services don’t just route to any pod – they route to specific pods using labels and selectors.

Example:

yamlCopyEditmetadata:
  labels:
    app: frontend

yamlCopyEditspec:
  selector:
    app: frontend

If a Pod has the label app: frontend, and a Service’s selector is also app: frontend, that pod is part of the service. Simple and powerful.

Pro tip: Keep your labeling consistent across deployments. Services rely heavily on this matching mechanism.

---

Sample YAML – ClusterIP Service

yamlCopyEditapiVersion: v1
kind: Service
metadata:
  name: my-app-svc
spec:
  selector:
    app: my-app
  ports:
    - port: 80       # The port the service exposes
      targetPort: 8080  # The port the pod listens on
  type: ClusterIP     # Default, internal only

This creates an internal service available via my-app-svc.default.svc.cluster.local

---

Service Types: ClusterIP vs NodePort vs LoadBalancer

Example – NodePort Service:

yamlCopyEditapiVersion: v1
kind: Service
metadata:
  name: my-nodeport-svc
spec:
  selector:
    app: my-app
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30036

Now accessible via <node-ip>:30036

---

Example – LoadBalancer (Cloud-Only)

yamlCopyEditapiVersion: v1
kind: Service
metadata:
  name: my-lb-svc
spec:
  selector:
    app: my-app
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

If you're on AWS, GCP, or Azure, Kubernetes will provision a cloud load balancer pointing to your service. Super useful for production deployments!

---

Final Thoughts

Kubernetes Services are essential glue in your architecture:

• They abstract away pod management

• Enable communication and exposure

• Work seamlessly with labels and selectors

Enter: Labels & Selectors

Labels = metadata tags on resources (Pods, Services, Deployments, etc.)

Think of labels like sticky notes:

yamlCopyEditlabels:
  app: frontend
  tier: web
  env: production

You can assign multiple labels to a resource to describe its role, environment, version, etc.

---

Selectors = filter mechanism to choose resources based on labels

A Service (or Deployment, or Job) uses selectors to find and group matching Pods.

Example:

yamlCopyEditselector:
  app: frontend

This means: "find all Pods with the label app=frontend".

---

Why This Matters

1. Dynamic Grouping

As Pods come and go, the Service keeps tracking the right set automatically, as long as they match the labels.

2. Decoupling

Services don’t need to know Pod names or IPs — only labels. This creates loose coupling, which is vital for scalable systems.

3. Powerful Queries

You can use labels and selectors to:

• Deploy updates to specific environments (env=staging)

• Monitor a subset of services (tier=backend)

• Roll out canary versions (version=canary)

---

Quick Analogy

Imagine you're at a conference. Every attendee has a badge with tags: "developer", "speaker", "JavaScript", "sponsor".

Now, if the organizer says:

“I need all JavaScript speakers on stage”

They just select based on language=JavaScript and role=speaker.

That's exactly what Kubernetes does using Labels & Selectors.

---

TL;DR – Why Labels and Selectors?