Module 9: Kubernetes 101 — From Docker Compose to Kubernetes

⏱️ Estimated Time: 6 hours 📋 Prerequisites: Track 2 — Docker & Production Hardening 🎯 Level: Intermediate

Introduction

In the previous modules, you learned how to run multi-container applications with Docker Compose and how to harden those containers for production.

Docker Compose is excellent for running an application stack on a single machine.

But what happens when your application grows?

Imagine you have:

• 10 application containers
• multiple servers
• thousands of requests
• containers that crash unexpectedly
• changing traffic throughout the day
• deployments that must happen without downtime

Manually managing all of this quickly becomes difficult.

This is where Kubernetes enters the picture.

Kubernetes is a container orchestration platform designed to automate the deployment, scaling, networking, and management of containerized applications.

1. Docker Compose vs Kubernetes

A useful way to understand Kubernetes is to compare it with what you already know.

Docker Compose

textCopy
1             Docker Compose
2                    │
3        ┌───────────┼───────────┐
4        ▼           ▼           ▼
5      Nginx       Django      PostgreSQL
6        │           │           │
7        └───────────┼───────────┘
8                    │
9                 Server

You define the services and Docker runs them.

Kubernetes

textCopy
1                    Kubernetes
2                        │
3        ┌───────────────┼───────────────┐
4        ▼               ▼               ▼
5      Worker          Worker          Worker
6      Node 1          Node 2          Node 3
7        │               │               │
8     ┌──┴──┐         ┌──┴──┐         ┌──┴──┐
9     │Pod  │         │Pod  │         │Pod  │
10     │Pod  │         │Pod  │         │Pod  │
11     └─────┘         └─────┘         └─────┘

Kubernetes can decide where workloads run, restart failed containers, maintain the desired number of replicas, and provide service discovery.

2. The Restaurant Headquarters Analogy

Think of Docker Compose as a single restaurant manager.

The manager knows:

• which employees work there
• where the kitchen is
• which services are running
• what resources the restaurant needs

Now imagine a corporation operating 100 restaurants.

You need a headquarters that can:

• decide where employees should work
• replace employees who become unavailable
• open additional branches during busy periods
• distribute customers between branches
• coordinate many locations
• monitor the entire organization

That is similar to Kubernetes.

textCopy
1Docker Compose
2      │
3      ▼
4Single restaurant
5      │
6      ▼
7One machine / environment

versus:

textCopy
1Kubernetes
2      │
3      ▼
4Restaurant headquarters
5      │
6      ├── Restaurant 1
7      ├── Restaurant 2
8      ├── Restaurant 3
9      └── Restaurant N

3. What Is Kubernetes?

Kubernetes is an open-source container orchestration system.

It provides mechanisms for:

• container deployment
• scheduling
• service discovery
• load balancing
• scaling
• self-healing
• rolling updates
• configuration management
• secret management
• storage orchestration

Instead of telling Kubernetes exactly how to perform every operation, you usually describe the desired state.

For example:

yamlCopy
1replicas: 3

means:

"I want three instances of this workload running."

Kubernetes continuously works toward that desired state.

4. Declarative Infrastructure

This is one of the biggest conceptual changes when moving from Docker Compose to Kubernetes.

With an imperative command:

bashCopy
1kubectl scale deployment django --replicas=3

you tell Kubernetes what action to perform.

With a Kubernetes manifest:

yamlCopy
1spec:
2  replicas: 3

you describe the desired state.

Kubernetes then continuously reconciles the actual state with the desired state.

textCopy
1Desired State
2replicas = 3
3      │
4      ▼
5 Kubernetes Controller
6      │
7      ▼
8Actual State
9replicas = 2
10      │
11      ▼
12Create another Pod
13      │
14      ▼
15Actual State = 3

This reconciliation model is fundamental to Kubernetes.

5. Kubernetes Architecture

A Kubernetes cluster generally consists of a control plane and one or more worker nodes.

textCopy
1                  Kubernetes Cluster
2                         │
3          ┌──────────────┴──────────────┐
4          │                             │
5          ▼                             ▼
6    Control Plane                    Worker Nodes
7          │                             │
8    ┌─────┼─────┐             ┌─────────┼─────────┐
9    ▼     ▼     ▼             ▼         ▼         ▼
10   API  Scheduler Controller  Pod       Pod       Pod
11  Server Manager

Control Plane

The control plane manages the cluster.

Important components include:

API Server

The Kubernetes API Server is the primary interface to the cluster.

When you execute:

bashCopy
1kubectl get pods

kubectl communicates with the Kubernetes API.

Scheduler

The scheduler determines where newly created Pods should run.

It considers factors such as:

• available resources
• scheduling constraints
• node conditions
• affinity rules
• taints and tolerations

Controller Manager

Controllers continuously observe the cluster and attempt to make the actual state match the desired state.

For example:

textCopy
1Desired:
23 Pods
3
4Actual:
52 Pods
6
7Controller:
8Create another Pod

etcd

etcd stores Kubernetes cluster state and configuration.

You normally do not interact with it directly in beginner Kubernetes workflows.

6. Worker Nodes

Worker nodes run your workloads.

A simplified node looks like:

textCopy
1Worker Node
2┌─────────────────────────────┐
3│                             │
4│   kubelet                   │
5│                             │
6│   Container Runtime         │
7│                             │
8│   ┌───────┐   ┌───────┐    │
9│   │ Pod   │   │ Pod   │    │
10│   └───────┘   └───────┘    │
11│                             │
12└─────────────────────────────┘

The kubelet communicates with the control plane and ensures the Pods assigned to that node are running.

7. What Is a Pod?

A Pod is the smallest deployable unit in Kubernetes.

A Pod can contain one or more containers.

For a simple Django application:

textCopy
1Pod
2┌──────────────────────┐
3│                      │
4│  Django Container    │
5│                      │
6└──────────────────────┘

A more advanced Pod might contain:

textCopy
1Pod
2┌──────────────────────────┐
3│ Django Application       │
4│                          │
5│ ┌────────┐  ┌─────────┐ │
6│ │ Django │  │ Sidecar │ │
7│ └────────┘  └─────────┘ │
8│                          │
9└──────────────────────────┘

Containers inside the same Pod share certain resources, including the Pod's network namespace.

Important Rule

Do not think of a Pod as simply "a Docker container."

A Pod is a Kubernetes abstraction that can contain one or more tightly coupled containers.

8. What Is a Deployment?

A Deployment manages replicated application Pods.

For example:

textCopy
1Deployment
2    │
3    ├── Pod 1
4    ├── Pod 2
5    └── Pod 3

If one Pod crashes:

textCopy
1Before:
2
3Deployment
4 ├── Pod 1
5 ├── Pod 2
6 └── Pod 3
7
8Pod 2 crashes

The Deployment's underlying controller mechanisms work to restore the desired replica count:

textCopy
1After:
2
3Deployment
4 ├── Pod 1
5 ├── Pod 3
6 └── Pod 4

The exact lifecycle can involve ReplicaSets and replacement Pods, but the key beginner concept is:

A Deployment manages the desired number and rollout state of application Pods.

9. What Is a Kubernetes Service?

Pods are temporary.

Their IP addresses can change when Pods are recreated.

Therefore, applications should not depend directly on individual Pod IP addresses.

A Kubernetes Service provides a stable network endpoint for a group of Pods.

textCopy
1             Service
2                │
3       ┌────────┼────────┐
4       ▼        ▼        ▼
5     Pod 1    Pod 2    Pod 3

The Service selects Pods using labels.

This provides stable service discovery and load distribution across matching Pods.

10. Compose → Kubernetes Translation

The concepts you learned in Docker Compose map approximately to Kubernetes concepts.

The mapping is not always one-to-one.

Kubernetes often provides more sophisticated mechanisms than the corresponding Compose feature.

11. Install a Local Kubernetes Cluster

For learning, you do not need a cloud Kubernetes cluster.

You can run Kubernetes locally with:

• kind
• Minikube

Both are useful for learning.

For this module, we'll use kind as the primary example.

Check Docker:

bashCopy
1docker --version

Check whether kind is installed:

bashCopy
1kind version

Check Kubernetes CLI:

bashCopy
1kubectl version --client

12. Create Your First Kubernetes Cluster

Create a cluster:

bashCopy
1kind create cluster --name deploymart

Check the cluster:

bashCopy
1kind get clusters

You should see:

textCopy
1deploymart

Now verify Kubernetes:

bashCopy
1kubectl cluster-info

Check nodes:

bashCopy
1kubectl get nodes

Expected output will look similar to:

textCopy
1NAME                     STATUS   ROLES           AGE
2deploymart-control-plane Ready    control-plane   1m

Congratulations.

You now have a Kubernetes cluster running locally.

13. Understanding kubectl

kubectl is the command-line client used to communicate with Kubernetes.

Think of it as:

textCopy
1kubectl
2   │
3   ▼
4Kubernetes API Server
5   │
6   ├── Pods
7   ├── Deployments
8   ├── Services
9   ├── ConfigMaps
10   └── Secrets

Useful commands include:

bashCopy
1kubectl get nodes
2kubectl get pods
3kubectl get deployments
4kubectl get services
5kubectl describe pod <pod-name>
6kubectl logs <pod-name>

14. Your First Deployment

Create a Django deployment:

bashCopy
1kubectl create deployment django \
2  --image=myapp:v1

Check it:

bashCopy
1kubectl get deployments

You should see:

textCopy
1NAME     READY   UP-TO-DATE   AVAILABLE
2django   1/1     1            1

Now check Pods:

bashCopy
1kubectl get pods

You should see something similar to:

textCopy
1NAME                      READY   STATUS    RESTARTS
2django-xxxxxxxxxx-xxxxx   1/1     Running   0

The generated name is controlled by Kubernetes.

15. Deployment vs Pod

A common beginner mistake is treating a Pod and Deployment as the same thing.

They are different.

textCopy
1Deployment
2     │
3     ▼
4 ReplicaSet
5     │
6     ├── Pod
7     ├── Pod
8     └── Pod

You generally manage the application through the Deployment.

The Deployment then manages the Pods.

16. Expose the Django Application

Create a Kubernetes Service:

bashCopy
1kubectl expose deployment django \
2  --port=80 \
3  --target-port=8000

Check Services:

bashCopy
1kubectl get services

You should see:

textCopy
1NAME     TYPE        CLUSTER-IP      PORT(S)
2django   ClusterIP   10.x.x.x        80/TCP

The important distinction is:

textCopy
1port: 80
2targetPort: 8000

The Service listens on port 80 while forwarding traffic to the application container's port 8000.

17. Service Networking

The Service provides a stable endpoint even when Pods change.

textCopy
1             django Service
2                   │
3          ┌────────┼────────┐
4          ▼        ▼        ▼
5        Pod A    Pod B    Pod C

If Pod B is deleted:

textCopy
1             django Service
2                   │
3          ┌────────┴────────┐
4          ▼                 ▼
5        Pod A             Pod C

A replacement Pod can later join the Service automatically when its labels match the Service selector.

18. Scale the Application

Now scale Django to three replicas:

bashCopy
1kubectl scale deployment django --replicas=3

Check:

bashCopy
1kubectl get pods

You should see three Pods.

textCopy
1django-xxxxx   Running
2django-yyyyy   Running
3django-zzzzz   Running

Check the Deployment:

bashCopy
1kubectl get deployment django

Expected:

textCopy
1NAME     READY   UP-TO-DATE   AVAILABLE
2django   3/3     3            3

This is your first Kubernetes scaling exercise.

19. Self-Healing

Kubernetes can replace failed Pods managed by a Deployment.

Find a Pod:

bashCopy
1kubectl get pods

Delete one:

bashCopy
1kubectl delete pod <pod-name>

Immediately check:

bashCopy
1kubectl get pods

You may briefly see:

textCopy
13 running
21 terminating
31 creating

Then eventually:

textCopy
13 running

The desired state is three replicas.

Kubernetes works to restore that state.

This is called self-healing.

20. Why This Is Different from Docker Compose

With Docker Compose, you can restart services and use restart policies.

Kubernetes extends this model into a cluster-wide orchestration system.

The important idea is:

textCopy
1Docker Compose:
2"Run these services."
3
4Kubernetes:
5"Maintain this desired state."

That distinction becomes increasingly important as deployments become larger.

21. Kubernetes Labels

Labels are fundamental to Kubernetes.

Example:

yamlCopy
1metadata:
2  labels:
3    app: django

A Service can select:

yamlCopy
1selector:
2  app: django

The relationship becomes:

textCopy
1Service
2 selector: app=django
3        │
4        ▼
5┌──────────────────────┐
6│ Pods                 │
7│ app=django            │
8└──────────────────────┘

Labels allow Kubernetes resources to identify and organize workloads.

22. Create Your First YAML Manifest

Commands are useful for learning, but production Kubernetes configurations are normally defined declaratively in YAML.

Create:

textCopy
1django-deployment.yaml

Example:

yamlCopy
1apiVersion: apps/v1
2kind: Deployment
3
4metadata:
5  name: django
6
7spec:
8  replicas: 3
9
10  selector:
11    matchLabels:
12      app: django
13
14  template:
15    metadata:
16      labels:
17        app: django
18
19    spec:
20      containers:
21        - name: django
22          image: myapp:v1
23
24          ports:
25            - containerPort: 8000

Apply it:

bashCopy
1kubectl apply -f django-deployment.yaml

Check:

bashCopy
1kubectl get deployment django

23. Create the Service YAML

Create:

textCopy
1django-service.yaml

yamlCopy
1apiVersion: v1
2kind: Service
3
4metadata:
5  name: django
6
7spec:
8  selector:
9    app: django
10
11  ports:
12    - port: 80
13      targetPort: 8000
14
15  type: ClusterIP

Apply:

bashCopy
1kubectl apply -f django-service.yaml

Check:

bashCopy
1kubectl get service django

24. Why YAML Is Important

Instead of remembering commands:

bashCopy
1kubectl create deployment ...
2kubectl expose deployment ...
3kubectl scale deployment ...

you can store your desired infrastructure in Git:

textCopy
1k8s/
2├── deployment.yaml
3├── service.yaml
4├── configmap.yaml
5├── secret.yaml
6└── ingress.yaml

Now your Kubernetes configuration becomes version-controlled infrastructure.

This is an important foundation for Infrastructure as Code and GitOps workflows.

25. ConfigMaps

Docker Compose uses environment variables.

Kubernetes provides ConfigMaps for non-sensitive configuration.

Example:

yamlCopy
1apiVersion: v1
2kind: ConfigMap
3
4metadata:
5  name: django-config
6
7data:
8  DJANGO_SETTINGS_MODULE: config.settings.production
9  LOG_LEVEL: INFO

A Deployment can consume these values:

yamlCopy
1envFrom:
2  - configMapRef:
3      name: django-config

Do not put passwords or private keys into ConfigMaps.

26. Kubernetes Secrets

Sensitive configuration belongs in Secrets.

Example:

yamlCopy
1apiVersion: v1
2kind: Secret
3
4metadata:
5  name: django-secret
6
7type: Opaque
8
9stringData:
10  SECRET_KEY: change-me
11  DATABASE_PASSWORD: change-me

Then:

yamlCopy
1envFrom:
2  - secretRef:
3      name: django-secret

Important Security Note

Kubernetes Secrets are not automatically equivalent to a dedicated external secret manager.

In production, protect access to the Kubernetes API and consider stronger secret-management solutions, encryption-at-rest configuration, and external secret managers depending on your environment.

27. Health Checks in Kubernetes

Docker Compose has:

yamlCopy
1healthcheck:

Kubernetes provides probes.

Readiness Probe

A readiness probe answers:

"Can this Pod receive traffic?"

Example:

yamlCopy
1readinessProbe:
2  httpGet:
3    path: /health/
4    port: 8000
5
6  initialDelaySeconds: 10
7  periodSeconds: 10

If the application is not ready, Kubernetes can remove the Pod from Service endpoints.

28. Liveness Probe

A liveness probe answers:

"Is this container still functioning?"

Example:

yamlCopy
1livenessProbe:
2  httpGet:
3    path: /health/
4    port: 8000
5
6  initialDelaySeconds: 30
7  periodSeconds: 20

If the liveness check repeatedly fails, Kubernetes can restart the container.

Remember

textCopy
1Readiness = Should receive traffic?
2
3Liveness = Should remain running?

These are related but not interchangeable.

29. Compose depends_on vs Kubernetes

In Docker Compose you might write:

yamlCopy
1depends_on:
2  - db

Beginners often expect Kubernetes to provide an identical mechanism.

It does not.

Kubernetes encourages applications to tolerate dependencies becoming temporarily unavailable.

For initialization tasks, you can use:

yamlCopy
1initContainers:

Example:

yamlCopy
1initContainers:
2  - name: wait-for-db
3    image: busybox
4    command:
5      - sh
6      - -c
7      - "until nc -z db 5432; do sleep 2; done"

However, do not use init containers as a substitute for proper application retry and readiness behavior in every situation.

Production applications should generally handle transient dependency failures gracefully.

30. Ingress — Public HTTP Routing

A Service provides internal or cluster-level access.

For HTTP/HTTPS routing from outside the cluster, Kubernetes commonly uses an Ingress or, in newer architectures, a Gateway API implementation.

A conceptual flow is:

textCopy
1Internet
2   │
3   ▼
4Ingress
5   │
6   ▼
7Service
8   │
9   ├── Pod
10   ├── Pod
11   └── Pod

For this module, focus on understanding the architecture.

You will build more advanced Ingress and TLS configurations in later modules.

31. Scaling: Manual vs Automatic

Manual scaling:

bashCopy
1kubectl scale deployment django --replicas=5

Automatic scaling can be handled using the Horizontal Pod Autoscaler (HPA).

Conceptually:

textCopy
1Low traffic
2    │
3    ▼
42 Pods
5
6High traffic
7    │
8    ▼
95 Pods

The HPA can adjust the number of replicas based on metrics such as CPU utilization and, with suitable metrics infrastructure, custom application metrics.

You will explore HPA in a later module.

32. Kubernetes Namespaces

Namespaces provide logical separation within a cluster.

For example:

textCopy
1Kubernetes Cluster
2│
3├── development
4├── staging
5└── production

Create one:

bashCopy
1kubectl create namespace deploymart

Then:

bashCopy
1kubectl get pods -n deploymart

Namespaces become particularly useful as environments and teams grow.

33. Useful kubectl Commands

Learn these commands well.

Cluster

bashCopy
1kubectl cluster-info
2kubectl get nodes

Pods

bashCopy
1kubectl get pods
2kubectl get pods -o wide
3kubectl describe pod <pod-name>
4kubectl logs <pod-name>

Deployments

bashCopy
1kubectl get deployments
2kubectl describe deployment django

Services

bashCopy
1kubectl get services
2kubectl describe service django

Apply configuration

bashCopy
1kubectl apply -f deployment.yaml

Delete resources

bashCopy
1kubectl delete -f deployment.yaml

Inspect everything

bashCopy
1kubectl get all

34. Debugging Kubernetes

When something does not work, do not immediately delete everything.

Use the debugging workflow:

textCopy
1Pod not working
2      │
3      ▼
4kubectl get pods
5      │
6      ▼
7kubectl describe pod
8      │
9      ▼
10kubectl logs
11      │
12      ▼
13Check Service
14      │
15      ▼
16Check endpoints
17      │
18      ▼
19Check configuration

For example:

bashCopy
1kubectl get pods

If a Pod shows:

textCopy
1CrashLoopBackOff

inspect it:

bashCopy
1kubectl describe pod <pod-name>

Then:

bashCopy
1kubectl logs <pod-name>

The error message usually provides the next clue.

35. Common Kubernetes Pod States

You will frequently encounter:

Pending

The Pod has not been successfully scheduled or started.

Possible causes include:

• insufficient resources
• scheduling constraints
• image pull problems
• storage requirements

Running

The Pod is running.

CrashLoopBackOff

The container repeatedly starts and crashes.

Check:

bashCopy
1kubectl logs <pod-name>

ImagePullBackOff

Kubernetes cannot pull the specified image.

Common causes:

• incorrect image name
• private registry authentication
• missing image
• registry connectivity problem

36. Local Image Problem with kind

When using kind, your local Docker image may not automatically exist inside the kind node's container runtime.

If your image is:

textCopy
1myapp:v1

build it:

bashCopy
1docker build -t myapp:v1 .

Then load it into kind:

bashCopy
1kind load docker-image myapp:v1 --name deploymart

Now Kubernetes can use the image from the kind node.

This is an important difference between local Docker and a Kubernetes cluster.

37. Complete Local Deployment

A basic workflow looks like:

bashCopy
1# Build application
2docker build -t myapp:v1 .
3
4# Create cluster
5kind create cluster --name deploymart
6
7# Load image into kind
8kind load docker-image myapp:v1 --name deploymart
9
10# Apply Kubernetes configuration
11kubectl apply -f k8s/
12
13# Check deployments
14kubectl get deployments
15
16# Check Pods
17kubectl get pods
18
19# Check Services
20kubectl get services

38. Port Forwarding for Local Testing

Because a ClusterIP Service is normally internal to the cluster, you can use port forwarding for local testing.

bashCopy
1kubectl port-forward service/django 8080:80

Now access:

textCopy
1http://localhost:8080

Traffic flows approximately as:

textCopy
1Browser
2   │
3   ▼
4localhost:8080
5   │
6   ▼
7kubectl port-forward
8   │
9   ▼
10django Service :80
11   │
12   ▼
13Django Pod :8000

This is convenient for development and debugging.

39. Docker Compose to Kubernetes Mental Model

When converting an application, think in terms of responsibilities.

Docker Compose

textCopy
1docker-compose.yml
2      │
3      ├── app
4      ├── database
5      ├── redis
6      └── nginx

Kubernetes

textCopy
1Kubernetes
2│
3├── Deployment
4│     └── Django Pods
5│
6├── Service
7│     └── Django networking
8│
9├── ConfigMap
10│     └── Application configuration
11│
12├── Secret
13│     └── Sensitive configuration
14│
15├── PersistentVolumeClaim
16│     └── Persistent storage
17│
18└── Ingress
19      └── HTTP/HTTPS routing

The major change is that Kubernetes separates application concerns into specialized resources.

40. Production Architecture You Are Working Toward

By the end of the Kubernetes track, your architecture will evolve toward something like:

textCopy
1                         Internet
2                            │
3                            ▼
4                       Load Balancer
5                            │
6                            ▼
7                     Ingress / Gateway
8                            │
9              ┌─────────────┴─────────────┐
10              ▼                           ▼
11        Django Service              Next.js Service
12              │                           │
13       ┌──────┼──────┐             ┌──────┼──────┐
14       ▼      ▼      ▼             ▼      ▼      ▼
15      Pod    Pod    Pod            Pod    Pod    Pod
16       │      │      │
17       └──────┼──────┘
18              ▼
19          PostgreSQL

This is the foundation for scalable cloud-native applications.

41. Mini Project — DeployMart v3.0

Now convert DeployMart from Docker Compose to Kubernetes.

Objective

Deploy the Django application into your local Kubernetes cluster.

Your project should include:

textCopy
1deploymart/
2│
3├── Dockerfile
4│
5├── k8s/
6│   ├── namespace.yaml
7│   ├── deployment.yaml
8│   ├── service.yaml
9│   ├── configmap.yaml
10│   └── secret.yaml
11│
12└── application/

Requirements

DeployMart v3.0 must:

• Run inside a local Kubernetes cluster
• Use a Deployment
• Run at least 3 replicas
• Use a ClusterIP Service
• Use labels and selectors correctly
• Store non-sensitive configuration in ConfigMap
• Store sensitive configuration in Secret
• Include a readiness probe
• Include a liveness probe
• Demonstrate Pod self-healing
• Demonstrate manual scaling
• Use a locally built Docker image
• Load the image into kind
• Access the application through port forwarding

42. Mini Project Tasks

Task 1 — Create the cluster

bashCopy
1kind create cluster --name deploymart

Task 2 — Build the image

bashCopy
1docker build -t deploymart:v1 .

Task 3 — Load the image

bashCopy
1kind load docker-image deploymart:v1 --name deploymart

Task 4 — Create namespace

bashCopy
1kubectl create namespace deploymart

Task 5 — Deploy Django

bashCopy
1kubectl apply -f k8s/deployment.yaml

Task 6 — Create Service

bashCopy
1kubectl apply -f k8s/service.yaml

Task 7 — Verify

bashCopy
1kubectl get pods -n deploymart
2kubectl get deployments -n deploymart
3kubectl get services -n deploymart

Task 8 — Scale

bashCopy
1kubectl scale deployment django \
2  --replicas=3 \
3  -n deploymart

Task 9 — Test self-healing

Delete one Pod:

bashCopy
1kubectl delete pod <pod-name> -n deploymart

Then:

bashCopy
1kubectl get pods -n deploymart

Confirm that Kubernetes creates a replacement.

Task 10 — Test the application

bashCopy
1kubectl port-forward \
2  service/django \
3  8080:80 \
4  -n deploymart

Open:

textCopy
1http://localhost:8080

43. Module 9 Checkpoint

Your checkpoint is complete when you can explain and demonstrate all of the following:

textCopy
1✓ Create a local Kubernetes cluster
2✓ Explain control plane vs worker nodes
3✓ Explain what a Pod is
4✓ Explain what a Deployment does
5✓ Explain what a Service does
6✓ Create a Deployment
7✓ Create a Service
8✓ Scale a Deployment
9✓ Demonstrate self-healing
10✓ Use labels and selectors
11✓ Use ConfigMaps
12✓ Understand Kubernetes Secrets
13✓ Understand readiness probes
14✓ Understand liveness probes
15✓ Debug Pods with kubectl
16✓ Load local images into kind
17✓ Use port-forwarding
18✓ Translate common Compose concepts to Kubernetes

Useful verification commands:

bashCopy
1kubectl get nodes
2kubectl get pods -n deploymart
3kubectl get deployments -n deploymart
4kubectl get services -n deploymart
5kubectl get all -n deploymart

44. Key Takeaways

The most important concepts from this module are:

Pod

The smallest deployable Kubernetes unit.

textCopy
1Pod
2 └── Container(s)

Deployment

Manages the desired state of replicated application Pods.

textCopy
1Deployment
2 └── ReplicaSet
3      ├── Pod
4      ├── Pod
5      └── Pod

Service

Provides stable networking to a group of Pods.

textCopy
1Service
2 ├── Pod
3 ├── Pod
4 └── Pod

ConfigMap

Stores non-sensitive configuration.

Secret

Stores sensitive configuration, with appropriate cluster access controls and protection.

Ingress

Provides HTTP/HTTPS routing into cluster services when an Ingress implementation is installed.

HPA

Automatically adjusts replicas based on metrics.

45. The Kubernetes Mindset

The biggest thing to learn is not the kubectl commands.

It is the Kubernetes mindset.

Instead of thinking:

"Start three containers."

Think:

"I want three healthy application replicas."

Instead of:

"Restart this container."

Think:

"The desired state is three replicas, and Kubernetes should maintain it."

Instead of:

"Connect directly to this Pod IP."

Think:

"Connect to the Service representing this application."

Instead of:

"Run this container on this machine."

Think:

"Kubernetes should schedule this workload onto an appropriate node."

That mindset is what separates basic Docker knowledge from Kubernetes orchestration knowledge.

What's Next?

In Module 10, you'll go deeper into Kubernetes networking and service discovery.

You'll learn how Pods communicate with each other, how Services discover Pods, how DNS works inside Kubernetes, and how to expose applications safely.

The architecture will evolve from:

textCopy
1Docker Compose
2      │
3      ▼
4Kubernetes Deployment
5      │
6      ▼
7Kubernetes Service

into:

textCopy
1Internet
2   │
3   ▼
4Ingress
5   │
6   ▼
7Service
8   │
9   ├── Pod
10   ├── Pod
11   └── Pod
12        │
13        ▼
14   Internal Services

🚀 Next Module: Kubernetes Networking & Service Discovery