How Deployment, Service, and Ingress Work Together in Kubernetes

When you deploy an application in Kubernetes, three key components work together to expose your API to users:

1. Deployment → Creates and manages your Pods

2. Service → Provides stable network access to the Pods

3. Ingress → Provides external access (HTTP/HTTPS) to the Service

Understanding how these three connect is essential for deploying any microservice.

---

1. Deployment → Creates Pods

A Deployment manages your application Pods:

• Ensures the right number of replicas

• Performs rolling updates

• Restarts Pods if they crash

Example:

Deployment  
   └── Pod (application)
   └── Pod (application)
   └── Pod (application)

Each Pod has its own IP, which changes when pods restart.
That’s why we cannot access Pods directly — the IPs are not stable.

---

 2. Service → Stable Access to Pods

A Service (usually ClusterIP) sits in front of the Pods:

• Provides a fixed stable IP inside the cluster

• Load-balances requests to the Pods

• Selects Pods using labels

Example:

selector:
  app: myservice

Any Pod with this label becomes part of the service.

---

3. Ingress → External Access via HTTP/HTTPS

A Service is only accessible inside the cluster.
If you need external access, you create an Ingress resource.

Ingress:

• Maps URLs/domains → to services

• Works through an Ingress Controller (nginx, traefik, AWS ALB)

• Supports TLS/SSL

Example:

https://api.mycompany.com/myservice → service → pods

---

Full Connectivity Flow (Simple Diagram)

          ┌──────────────────────────────────┐
          │             Client                │
          │    (Browser / Mobile / API)       │
          └──────────────────┬────────────────┘
                             │ HTTP/HTTPS
                             ▼
                 ┌─────────────────────┐
                 │      Ingress        │
                 │  (Domain & Routing) │
                 └───────────┬─────────┘
                             │
                             ▼
                 ┌───────────────────────┐
                 │        Service         │
                 │ (Stable ClusterIP LB)  │
                 └──────────┬────────────┘
                            │
              ┌─────────────┴───────────────┐
              ▼                               ▼
     ┌─────────────────┐            ┌─────────────────┐
     │      Pod 1      │            │     Pod 2       │
     │ (Your backend)  │            │ (Your backend)  │
     └─────────────────┘            └─────────────────┘

---

🔁 Step-by-Step Request Flow

1️⃣ A user calls:

https://api.mycompany.com/status

2️⃣ Ingress receives the request

Matches a rule:

paths:
  - path: /
    backend:
      service:
        name: myservice
        port:
          number: 8080

3️⃣ Ingress forwards to Service

This is internal routing.

4️⃣ Service load balances to Pods

Based on labels.

5️⃣ Pod handles the request

Returns response → Service → Ingress → Client.

---

🧩 How They Connect in YAML

Deployment → Pods

metadata:
  labels:
    app: myservice

Service selects Pods

selector:
  app: myservice

Ingress sends traffic to Service

backend:
  service:
    name: myservice
    port:
      number: 8080

This label-chain is how they connect.

---

Text Diagram of Logical Mapping

Deployment → Pods (labeled "app=myservice")
                ▲
                │ label selector
                ▼
          Service (ClusterIP)
                ▲
                │ Ingress backend
                ▼
             Ingress

If labels don’t match → service will have 0 pods → no traffic.

---

Why Kubernetes Uses All 3 Layers?

Component	Purpose
Deployment	Run & manage your application containers
Service	Stable network endpoint inside cluster + load balancing
Ingress	Public HTTP/HTTPS access + routing +