Chapter 6.2: Container Orchestration (Kubernetes)

Part 3: The Kubernetes Object Model (YAML)

How do you tell the kube-apiserver what you want? You don't send an email. You send a **YAML** file.
In Kubernetes, *everything* is an **Object** (or "Resource"). A container, a deployment, a network rule... it's all an object defined in YAML. This is the **"declarative"** model. You write a YAML file that describes your "desired state" and send it to the API server.

Every Kubernetes YAML file has **four** required fields:

# 1. apiVersion: Which K8s API to use (e.g., v1, apps/v1)
apiVersion: v1
# 2. kind: What *kind* of object is this?
kind: Pod
# 3. metadata: Data *about* the object (its name, labels)
metadata:
  name: my-first-pod
  labels:
    app: my-app
# 4. spec: The "desired state" - the *real* configuration
spec:
  containers:
  # ... (spec for the Pod goes here)

We will now learn the most important kinds of objects.

Part 4: Core Workloads (Running Your App)

These objects are responsible for running your containers.

1. `Pod` (The Smallest Unit)

A **Pod** is the *smallest, most basic deployable unit* in Kubernetes. A Pod is **not** a container. It is a **wrapper around one or more containers**.

A Pod represents a single, co-located "instance" of your app. All containers inside one Pod share the same network (IP address) and storage (Volumes). 99% of the time, your Pod will just have **one container** in it (e.g., your web app).

You almost *never* create a Pod by itself. Why? Because if the Pod crashes, it's dead. K8s won't restart it. Instead, you use a `Deployment` to manage your Pods.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.25
    ports:
    - containerPort: 80

2. `ReplicaSet` (The "Ensurer")

A ReplicaSet's job is simple: to ensure that a specified number of "replicas" (copies) of a Pod are running at all times.

You tell it: replicas: 3. It will create 3 Pods. If you manually delete one, the ReplicaSet's controller will see "desired=3, current=2" and *immediately* create a new one.

You almost *never* create a ReplicaSet by itself either. You use a `Deployment`.

3. `Deployment` (The "Manager" - CRITICAL)

This is the object you will use **99% of the time** to deploy your app. A Deployment is a high-level manager that controls `ReplicaSet`s, which in turn control `Pod`s.

The Deployment adds the one feature ReplicaSets don't have: **rolling updates**.

When you edit a Deployment (e.g., change image: v1 to image: v2), the Deployment performs a controlled rolling update:

1. It creates a *new* ReplicaSet for v2.
2. It scales up the v2 ReplicaSet (e.g., to 1 Pod).
3. It waits for that v2 Pod to be "healthy."
4. It scales down the *old* v1 ReplicaSet (e.g., to 2 Pods).
5. It repeats this process, one-by-one, until all Pods are v2 and the v1 ReplicaSet is at 0.

This ensures you have zero downtime during an update.

Example: A Full Deployment YAML

apiVersion: apps/v1 # Note the different apiVersion
kind: Deployment
metadata:
  name: my-nginx-deployment
spec:
  # 1. We want 3 copies (replicas) of our app
  replicas: 3
  
  # 2. The 'selector' tells the Deployment which Pods it "owns"
  # This MUST match the Pods' labels
  selector:
    matchLabels:
      app: my-nginx
      
  # 3. This is the 'template' for creating the Pods
  template:
    metadata:
      # 4. The Pods' labels (must match the selector)
      labels:
        app: my-nginx
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.25
        ports:
        - containerPort: 80

Part 5: Networking (Services & Ingress)

We have a problem. We have 3 Nginx Pods running. But Pods are ephemeral:
1. If a Pod crashes, it gets a **new IP address** when it restarts.
2. If a `Backend` app wants to talk to a `Database` app, which of the 3 `Database` Pod IPs should it talk to?
We need a **stable address** for a group of Pods. This is what a **Service** is.

1. `Service` (The "Internal Load Balancer")

A **Service** is a K8s object that provides a **single, stable IP address** and **DNS name** for a group of Pods (e.g., all Pods with the label app: my-nginx). It acts as an internal load balancer, distributing traffic to all the healthy Pods behind it.

Example: A Service for our Nginx Deployment

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-service
spec:
  # 1. This 'selector' finds the Pods to send traffic to.
  # It MUST match the Pods' labels (app: my-nginx)
  selector:
    app: my-nginx
  
  # 2. 'ports' defines how traffic is routed
  ports:
  - protocol: TCP
    port: 80        # The Service's port (what other Pods connect to)
    targetPort: 80  # The container's port (from the Dockerfile)
    
  # 3. 'type' (discussed below)
  type: ClusterIP

Now, any *other* Pod in your cluster can simply connect to http://my-nginx-service and Kubernetes will automatically route their request to one of the 3 healthy Nginx Pods.

Service Types (How to Expose Your App)

• ClusterIP (Default): Exposes the Service *only* on an internal IP inside the cluster. This is perfect for databases or backend APIs that should *not* be open to the internet.
• NodePort: Exposes the Service on a static port (e.g., 30080) on *every single Worker Node*. This is good for testing, as you can go to http://[Any_Node_IP]:30080.
• LoadBalancer (The Cloud Way): This is the one you use in production. When you set this type, Kubernetes *automatically* tells your cloud provider (AWS, GCP) to provision a **real, external Load Balancer** (like an AWS ELB). This gives you a *public IP address* for your app, which you can point your domain (codewithmsmaxpro.me) to.

2. `Ingress` (The "Smart Router")

A LoadBalancer service is expensive (you pay for a new public IP for *every* app). What if you have 10 apps on your cluster? You don't want 10 Load Balancers.

An **Ingress** is a Layer 7 "smart router" that sits in front of *all* your services. You create **one** LoadBalancer for your Ingress, and then the Ingress routes traffic to the correct *internal* ClusterIP service based on the URL.

Example: An Ingress for Two Apps

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  # Rule 1: Send 'codewithmsmaxpro.me' to the blog service
  - host: "codewithmsmaxpro.me"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-blog-service
            port:
              number: 80
  
  # Rule 2: Send 'api.codewithmsmaxpro.me' to the API service
  - host: "api.codewithmsmaxpro.me"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-api-service
            port:
              number: 8080

Part 6: ConfigMaps, Secrets, and Storage

`ConfigMap` (For Non-Secret Data)

You should *never* hard-code configuration (like a DATABASE_URL) into your Docker image. To change it, you'd have to rebuild the entire image.
A **ConfigMap** is a K8s object that stores non-sensitive configuration data as key-value pairs. You can then "inject" this data into your Pods as environment variables or files.

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-config
data:
  DATABASE_URL: "postgres://user@db-service"
  LOG_LEVEL: "DEBUG"

`Secret` (For Sensitive Data)

A **Secret** is *exactly* like a ConfigMap, but it's used for sensitive data (API keys, database passwords). The data is stored in **Base64** encoding (which is *not* encryption, just obsfucation). Its main power is that you can apply stricter access control (RBAC) to it.

# Create a secret from the command line (safer)
$ kubectl create secret generic my-db-secret \
    --from-literal=DB_PASSWORD='super-secret-pass-123'

How to Use ConfigMaps/Secrets in a Pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api-deployment
spec:
  ... (replicas, selector) ...
  template:
    ... (metadata) ...
    spec:
      containers:
      - name: api-container
        image: my-api:v1
        # Inject the data as Environment Variables
        env:
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: my-app-config # Name of the ConfigMap
              key: LOG_LEVEL
        - name: DATABASE_PASSWORD
          valueFrom:
            secretKeyRef:
              name: my-db-secret # Name of the Secret
              key: DB_PASSWORD

`PersistentVolume` (Persistent Storage)

Just like Docker, a Pod's filesystem is **ephemeral**. If a Pod (like your database) crashes and restarts, all its data is GONE.
To save data permanently, we use **PersistentVolumes**. The concept is a bit complex:

1. PersistentVolume (PV): The "storage" itself. This is the actual physical (or cloud) disk (e.g., an AWS EBS Volume). A cluster admin usually creates this.
2. PersistentVolumeClaim (PVC):** The "request" for storage. A developer's Pod *claims* (requests) storage.
3. StorageClass:** The "automatic" way. You just ask for "10GB of fast-ssd," and the StorageClass automatically provisions a PV for you.

# 1. Create the "request" (PVC)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-db-data-claim
spec:
  accessModes:
    - ReadWriteOnce # Can be mounted by one Pod at a time
  resources:
    requests:
      storage: 5Gi # I need 5 Gigabytes of space
  storageClassName: "standard-ssd" (Tells the cloud provider to make an SSD)

--- # (This just separates YAML files)

# 2. Create the Deployment that *uses* the claim
apiVersion: apps/v1
kind: Deployment
...
spec:
  template:
    ...
    spec:
      containers:
      - name: postgres
        image: postgres:15
        ports:
        - containerPort: 5432
        # 3. Mount the volume into the container
        volumeMounts:
        - name: db-storage
          mountPath: /var/lib/postgresql/data # Postgres's data path
      
      # 4. Tell the Pod *which* PVC to use for "db-storage"
      volumes:
      - name: db-storage
        persistentVolumeClaim:
          claimName: my-db-data-claim

# Create or update all objects defined in my deployment.yml file
$ kubectl apply -f deployment.yml

deployment.apps/my-nginx-deployment created

# Get all pods
$ kubectl get pods

NAME                                   READY   STATUS    RESTARTS   AGE
my-nginx-deployment-7f5d7d5f4f-abcde   1/1     Running   0          5m
my-nginx-deployment-7f5d7d5f4f-ghijk   1/1     Running   0          5m
my-nginx-deployment-7f5d7d5f4f-xyz12   1/1     Running   0          5m


# Get all services and deployments
$ kubectl get service,deployment

# Find out why my pod is broken
$ kubectl describe pod my-nginx-deployment-7f5d7d5f4f-abcde

Name:         my-nginx-deployment-7f5d7d5f4f-abcde
Namespace:    default
Status:       Pending
...
Events:
  Type     Reason            Age    From               Message
  ----     ------            ----   ----               -------
  Warning  FailedScheduling  2m    default-scheduler  0/3 nodes are available: 3 Insufficient cpu.

$ kubectl delete -f deployment.yml

deployment.apps "my-nginx-deployment" deleted

# Show logs from a pod (like 'docker logs')
$ kubectl logs my-nginx-deployment-7f5d7d5f4f-abcde

# Follow the logs in real-time
$ kubectl logs -f my-nginx-deployment-7f5d7d5f4f-abcde

# Get a shell *inside* a running container (like 'docker exec')
$ kubectl exec -it my-nginx-deployment-7f5d7d5f4f-abcde -- /bin/bash