# Day 24 - Kubernetes – Deployments, and ReplicaSets

## 🧱 1. From Docker Containers to Kubernetes

You can create containers using any platform — for example, **Docker**.

### In Docker:

You usually run a container using commands like:

```plaintext
docker run -it image_name
docker run -d -p 8080:80 -v /data:/app --network mynet nginx
```

Here you specify options such as:

* `-p` → port mapping
    
* `-v` → volumes
    
* `--network` → network type
    

This is the **command-line specification** for running a container.

---

## ⚙️ 2. Kubernetes Simplifies This – YAML Manifest

Kubernetes introduced an **enterprise-level approach** to manage containers.

Instead of writing long commands, Kubernetes allows you to define everything in a **YAML manifest file** (for example, `pod.yaml`).

In the YAML file, you define:

* Container image name
    
* Ports to expose
    
* Volumes
    
* Network details
    

This YAML file acts as a **running specification** for your container.

So:

> 🟩 **Pod YAML = Declarative specification to run your container in Kubernetes**

---

## 📦 3. What is a Pod?

A **Pod** is the **smallest deployable unit** in Kubernetes.  
It’s a wrapper around one or more containers.

A Pod defines *how the container should run* — image, ports, volumes, and other configurations.

---

### 🧩 Single vs Multiple Containers in a Pod

* A **Pod can contain a single container** (most common).
    
* It can also contain **multiple containers** if they are tightly coupled — for example:
    
    * One main application container
        
    * One sidecar container (for logging, proxy, API gateway, etc.)
        

### 🕸️ Why multiple containers in a Pod?

Because:

* They **share the same network** (can communicate using [`localhost`](http://localhost))
    
* They **share the same storage volumes**
    

📘 Example use case:  
**Service Mesh** — one main app container and one sidecar container for service routing.

---

## ⚡ 4. Why Do We Need Deployments?

Now that you can deploy an app using a Pod, the next question is:

> Why move from Pod to Deployment?

Because **Pods cannot auto-heal or auto-scale**.

Kubernetes provides features like:

* **Auto-healing** → restart failed Pods automatically
    
* **Auto-scaling** → increase/decrease Pods based on load
    

Pods alone **cannot** do this.  
To achieve these behaviors, Kubernetes uses a **Deployment**.

---

## 🚀 5. What is a Deployment?

A **Deployment** is a higher-level resource that manages Pods.

When you create a Deployment, it:

1. Creates an internal resource called a **ReplicaSet**
    
2. The ReplicaSet then creates and manages **Pods**
    

🧠 **Flow:**  
`Deployment → ReplicaSet → Pod`

---

### 📄 Deployment YAML (simplified example)

```plaintext
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
```

Here:

* `replicas: 2` → desired number of Pods
    
* `template:` → defines the Pod specification
    

---

## 🧩 6. What is a ReplicaSet?

A **ReplicaSet** is a **Kubernetes controller** that ensures the desired number of Pods are always running.

If you delete or lose a Pod:

* The ReplicaSet will **immediately recreate** it.
    

### Example:

If Deployment says `replicas: 2`:

* ReplicaSet ensures 2 Pods are **always running**.
    
* If one is deleted, a new one is automatically created.
    

→ This is called **auto-healing**.

---

## 🔁 7. How Deployments Enable Zero Downtime

If you update the `replicas` value from 2 → 3 in your YAML and apply it again:

```plaintext
kubectl apply -f deployment.yaml
```

Kubernetes:

* Notices the change
    
* Automatically creates one new Pod (via ReplicaSet)
    
* Keeps existing Pods running
    

✅ This ensures **zero downtime** and **smooth scaling**.

---

## 🧠 8. Controller Concept in Kubernetes

A **Controller** in Kubernetes maintains the **desired state** of the cluster.

For example:

* If Deployment YAML says 3 replicas → the controller ensures 3 Pods are always running.
    

Controllers constantly **watch and reconcile**:

> Desired State (YAML) = Actual State (cluster)

Examples of controllers:

* **ReplicaSet Controller**
    
* **Deployment Controller**
    
* **DaemonSet Controller**
    
* **Custom Controllers** (like ArgoCD, Admission Controllers)
    

---

## 🧩 9. Pod vs Container vs Deployment (Interview Key Question)

| Concept | Description | Key Feature |
| --- | --- | --- |
| **Container** | Basic runtime unit (e.g., Docker) | Runs app processes |
| **Pod** | Wrapper around one or more containers | Adds networking & storage sharing |
| **Deployment** | Manages Pods via ReplicaSet | Adds auto-healing & scaling |

**Summary:**

> Container → Pod → Deployment  
> Each layer adds management capability on top of the previous one.

---

## 🧩 10. Deployment vs ReplicaSet

| Concept | Description | Role |
| --- | --- | --- |
| **Deployment** | High-level abstraction | Defines desired replicas & updates |
| **ReplicaSet** | Kubernetes Controller | Actually creates & maintains Pods |

📘 Think of it like this:  
Deployment = Manager  
ReplicaSet = Worker ensuring Pods match Deployment instructions

---

## 🧩 11. Real-Time Demo Behavior (as explained)

* `kubectl apply -f pod.yaml` → creates one Pod
    
* If you `kubectl delete pod <name>` → Pod is gone; app stops
    

❌ No auto-healing in a Pod.

---

### ✅ With Deployment:

* `kubectl apply -f deployment.yaml` → creates Deployment → ReplicaSet → Pod
    
* If you delete one Pod:
    
    ```plaintext
    kubectl delete pod <name>
    ```
    
    Immediately, ReplicaSet recreates a new Pod (auto-healing)
    
* If you increase replicas from 1 → 3:
    
    ```plaintext
    kubectl apply -f deployment.yaml
    ```
    
    ReplicaSet creates two new Pods (scaling)
    

→ All without downtime.

---

## ⚙️ 12. Common kubectl Commands

| Action | Command |
| --- | --- |
| Create Pod/Deployment | `kubectl apply -f <file>.yaml` |
| List Pods | `kubectl get pods` |
| List Deployments | `kubectl get deploy` |
| List ReplicaSets | `kubectl get rs` |
| Delete Pod | `kubectl delete pod <name>` |
| Watch live events | `kubectl get pods -w` |
| Describe a resource | `kubectl describe pod <name>` |

---

## 📈 13. Zero Downtime Example Summary

* Deleted Pod → instantly recreated (auto-healing)
    
* Increased replicas → new Pods created automatically (scaling)
    
* All without affecting users → **zero downtime**
    

---

## 🧩 14. Practical Assignment

* Create a Deployment YAML with your own image
    
* Apply it to cluster
    
* Delete a Pod → observe auto-healing
    
* Increase replicas → observe scaling
    
* Use `kubectl get rs` to verify ReplicaSet creation
    

---

## 🧠 15. Key Interview Questions

1. Difference between **Container**, **Pod**, and **Deployment**
    
2. Difference between **Deployment** and **ReplicaSet**
    
3. What is a **Controller** in Kubernetes?
    
4. How does **auto-healing** work in Kubernetes?
    
5. What ensures **desired vs actual state**?
    

---

## ✅ 16. Summary of Key Concepts

| Component | Function | Example Resource |
| --- | --- | --- |
| **Container** | Runs app process | Docker |
| **Pod** | Runs 1 or more containers | pod.yaml |
| **ReplicaSet** | Ensures desired Pod count | rs |
| **Deployment** | Manages Pods via ReplicaSet | deployment.yaml |
| **Controller** | Maintains desired state | ReplicaSet Controller |

🟢 **Final Flow:**  
`Deployment → ReplicaSet → Pod → Container`