From Docker Compose to Kubernetes

Part 1: Kubernetes Fundamentals

A hands-on workshop for developers
Transitioning from docker-compose.yml to Kubernetes

Workshop Overview

Part 1: Fundamentals (4 hours)

• Environment Setup
• Core Resources: Pods, Deployments, Services
• Configuration: ConfigMaps & Secrets
• Storage: Volumes & Persistence
• Organization: Namespaces & Management
• Final Integration Lab

Part 2: Advanced Topics (4 hours)

• Ingress, Helm, GitOps
• Monitoring, Security, Autoscaling

Prerequisites

Required Knowledge:

• Docker and docker-compose experience
• Basic Linux command line
• YAML syntax
• Container concepts

What You'll Learn:

• Kubernetes core concepts
• Migrating from Compose to K8s
• kubectl and k9s tools
• Best practices for K8s manifests

Environment Setup

Tools Used:

• Podman (container runtime)
• kind (Kubernetes in Docker)
• kubectl (K8s CLI)
• k9s (Terminal UI)
• Workshop container with pre-installed tools

Cluster Setup:

$ kind create cluster --name workshop --config=kind-simple.yaml
$ kubectl cluster-info

Why Kubernetes?

Docker Compose:

• Simple, single-host deployments
• Great for dev environments
• Limited scaling and orchestration

Kubernetes:

• Multi-node, production-ready
• Self-healing and auto-scaling
• Advanced networking and storage
• Declarative configuration
• Industry standard for container orchestration

Kubernetes Architecture

Control Plane:

• API Server (entry point)
• Scheduler (pod placement)
• Controller Manager (desired state)
• etcd (cluster data store)

Worker Nodes:

• kubelet (pod management)
• kube-proxy (networking)
• Container runtime

Part 1.1: Introduction to Kubernetes

Key Concepts:

• Declarative vs. Imperative
• Desired state reconciliation
• Labels and Selectors
• Namespaces

First Command:

$ kubectl get nodes
$ kubectl cluster-info

Part 1.2: Environment Setup

Workshop Container:

$ podman run -it --name kind-workshop \
  --privileged \
  -v ${PWD}:/workspace \
  fedora:39 bash

Cluster Types:

• Simple: 1 control-plane + 1 worker
• Multi-node: 1 control-plane + 3 workers
• HA: 3 control-planes + 3 workers

Part 1.3: Pods - The Smallest Unit

What is a Pod?

• One or more containers
• Shared network namespace
• Shared storage volumes
• Ephemeral by nature

Docker Compose Service:

services:
  app:
    image: nginx:1.25-alpine

Pods - Kubernetes Equivalent

apiVersion: v1
kind: Pod
metadata:
  name: app
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.25-alpine
    ports:
    - containerPort: 80

Create Pod:

$ kubectl apply -f pod.yaml
$ kubectl get pods

Multi-Container Pods

Sidecar Pattern:

spec:
  containers:
  - name: app
    image: myapp:latest
  - name: logger
    image: fluentd:latest

Use Cases:

• Logging sidecars
• Proxy/service mesh
• Initialization helpers

Part 1.4: Deployments

Why Deployments?

• Manage ReplicaSets
• Rolling updates
• Rollback capability
• Scaling
• Self-healing

Compose Equivalent:

deploy:
  replicas: 3

Deployment Operations

Scaling:

$ kubectl scale deployment web --replicas=5

Updates:

$ kubectl set image deployment/web nginx=nginx:1.26-alpine

Rollback:

$ kubectl rollout history deployment/web
$ kubectl rollout undo deployment/web

Update Strategies

RollingUpdate (Default):

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

Recreate:

strategy:
  type: Recreate

Part 1.5: Services

Service Types:

1. ClusterIP - Internal only (default)
2. NodePort - External access via node IP
3. LoadBalancer - Cloud load balancer
4. Headless - Direct pod access (StatefulSets)

Purpose: Stable networking for pods

Service Example

Docker Compose:

services:
  web:
    ports:
      - "8080:80"

Kubernetes:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
  - port: 8080
    targetPort: 80
  type: ClusterIP

Service Discovery

DNS Resolution:

<service-name>.<namespace>.svc.cluster.local

Example:

$ kubectl run test --image=busybox -it --rm -- sh
/ $ wget -O- http://web:8080
/ $ wget -O- http://web.default.svc.cluster.local:8080

Docker Compose Equivalent:
Simply use service name as hostname

Part 1.6: ConfigMaps & Secrets

ConfigMaps: Non-sensitive configuration
Secrets: Sensitive data (base64 encoded)

Docker Compose:

environment:
  - DATABASE_URL=postgres://db:5432/db
  - SECRET_KEY=mysecret

Part 1.7: Storage

Volume Types:

• emptyDir - Temporary, pod lifetime
• hostPath - Node filesystem (dev only)
• PersistentVolume - Cluster-level storage
• PersistentVolumeClaim - Request for storage
• StorageClass - Dynamic provisioning

Volume Comparison

Docker Compose:

volumes:
  - db-data:/var/lib/postgresql/data
volumes:
  db-data:

Kubernetes:

volumeMounts:
- name: db-data
  mountPath: /var/lib/postgresql/data
volumes:
- name: db-data
  persistentVolumeClaim:
    claimName: db-data-pvc

PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-data-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: local-path

Access Modes:

• ReadWriteOnce (RWO) - Single node
• ReadWriteMany (RWX) - Multiple nodes
• ReadOnlyMany (ROX) - Multiple nodes, read-only

StatefulSets for Stateful Apps

Features:

• Stable pod identities
• Ordered deployment/scaling
• Stable network IDs
• Persistent storage per pod

Use Cases:

• Databases
• Message queues
• Distributed systems requiring stable identity

Part 1.8: Namespaces

Purpose:

• Logical cluster subdivision
• Resource isolation
• Access control boundaries
• Multi-tenancy

Default Namespaces:

• default - Default for user resources
• kube-system - Control plane components
• kube-public - Public resources
• kube-node-lease - Node heartbeats

Working with Namespaces

Create Namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: development

Use Namespace:

$ kubectl create -f manifest.yaml -n development
$ kubectl get pods -n development

Set Default:

$ kubectl config set-context --current --namespace=development

Cross-Namespace Communication

DNS Format:

<service>.<namespace>.svc.cluster.local

Example:

# From frontend namespace to backend namespace
$ curl http://api.backend.svc.cluster.local:3000

NetworkPolicies can restrict cross-namespace access

Part 1.9: kubectl Essentials

Get Resources:

$ kubectl get pods
$ kubectl get pods -o wide
$ kubectl get pods -o yaml
$ kubectl get all

Describe Resources:

$ kubectl describe pod nginx
$ kubectl describe node kind-worker

kubectl - Logs & Exec

View Logs:

$ kubectl logs pod-name
$ kubectl logs pod-name -f  # Follow
$ kubectl logs pod-name -c container-name
$ kubectl logs -l app=nginx --all-containers

Execute Commands:

$ kubectl exec pod-name -- ls /etc
$ kubectl exec -it pod-name -- sh

kubectl - Apply & Delete

Apply Manifests:

$ kubectl apply -f manifest.yaml
$ kubectl apply -f ./directory/
$ kubectl apply -k ./kustomize/

Delete Resources:

$ kubectl delete pod nginx
$ kubectl delete -f manifest.yaml
$ kubectl delete all -l app=nginx

k9s - Terminal UI

Launch:

$ k9s

Key Features:

• Real-time cluster view
• Resource navigation
• Log viewing
• Shell access
• Port forwarding
• YAML editing

Part 1.10: Manifest Best Practices

Organization:

• Separate files by resource type
• Use meaningful names
• Group related resources

Labeling:

metadata:
  labels:
    app: web
    version: v1
    tier: frontend
    environment: production

Resource Management

Always Set:

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

Requests: Guaranteed resources
Limits: Maximum resources

Health Checks

Liveness Probe:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

Readiness Probe:

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5

Part 1.11: Final Integration Lab

Objective:
Convert 3-tier Docker Compose application to Kubernetes

Components:

• PostgreSQL database (StatefulSet + PVC)
• Backend API (Deployment + Service)
• Frontend web app (Deployment + Service)

Concepts Integrated:

• Namespaces, Secrets, ConfigMaps
• Services, Deployments, StatefulSets
• Persistent storage, Health checks

Key Conversion Points

Docker Compose:

• Single file
• Automatic networking
• Simple volumes
• Environment variables
• Service discovery via names

Kubernetes:

• Multiple manifests
• Explicit Services
• PVC + StorageClass
• ConfigMaps + Secrets
• DNS-based discovery

Best Practices Recap

1. Always use labels for organization
2. Set resource requests/limits on all containers
3. Implement health checks (liveness + readiness)
4. Use namespaces for logical separation
5. Separate secrets from configuration
6. Use declarative manifests (not imperative commands)
7. Version your images (avoid latest)
8. Test in dev cluster before production

Key Differences: Compose vs K8s

Workshop Resources

Documentation:

• kubectl cheatsheet
• k9s shortcuts reference
• Docker Compose to K8s mapping guide

Examples:

• Complete examples for each concept
• Hands-on labs with solutions
• Final integration lab

Next Steps:

• Part 2: Advanced topics
• Practice on your own clusters
• Explore official Kubernetes docs

Questions & Discussion

Common Questions:

• When to use Deployments vs StatefulSets?
• How to handle secrets securely?
• Best namespace organization strategy?
• Resource limits recommendations?
• Development vs Production differences?

Open Discussion:

• Share your use cases
• Challenges you anticipate
• What excites you about Kubernetes?

Feedback & Next Session

Today's Feedback:

• What worked well?
• What needs clarification?
• Pace okay?
• Lab difficulty appropriate?

Before Part 2:

• Complete any unfinished labs
• Review cheatsheets
• Practice kubectl commands
• Prepare questions

See you in Part 2!

Thank You!

Workshop Materials:

• All examples available in repository
• Labs with complete solutions
• Cheatsheets and reference guides

Support:

• GitHub issues for questions
• Workshop community discussions
• Office hours (if applicable)

Keep Learning!