Introduction to Kubernetes and Orchestration¶

Overview¶

Running one container with docker run is straightforward. Running five hundred containers across fifty servers — with zero-downtime deploys, automatic restarts, rolling updates, secret rotation, and traffic shifting — requires orchestration. Kubernetes (often abbreviated K8s) is the dominant open-source container orchestrator. It schedules workloads, heals failed containers, exposes services on stable network endpoints, and provides a declarative API that teams version in Git.

This tutorial establishes your mental model: what orchestration means, why Kubernetes emerged after Docker, how it compares to Docker Swarm and managed platforms, and where it sits in the cloud-native stack alongside CI/CD, observability, and infrastructure as code.

This is Tutorial 1 in Module 1: Foundations of the REBASH Academy Kubernetes series. Complete the Docker track first — especially From Docker to Kubernetes, which maps Docker concepts to Kubernetes objects. This tutorial follows our documentation standards.

Prerequisites¶

• Completion of the Docker track, especially:
• Introduction to Containers and Docker
• Docker Compose Fundamentals (or equivalent Compose experience)
• From Docker to Kubernetes
• Comfort using a terminal on Linux, macOS, or WSL2
• Basic understanding of Introduction to Networking — IPs, DNS, ports, load balancing
• Familiarity with Git — manifests and Helm charts are version-controlled like Dockerfiles

Learning Objectives¶

By the end of this tutorial, you will be able to:

• Explain why container orchestration is needed beyond a single Docker host
• Describe the core problems Kubernetes solves: scheduling, scaling, self-healing, and service discovery
• Articulate the declarative reconciliation model (desired state vs actual state)
• Compare Kubernetes to Docker Swarm, Nomad, and managed orchestrators at a high level
• Map Kubernetes to the CNCF cloud-native landscape and DevOps toolchain
• Identify when Kubernetes is the right tool — and when simpler alternatives suffice
• Outline the learning path for the REBASH Academy Kubernetes track

Architecture Diagram¶

The diagram below shows where Kubernetes sits between your container images and production infrastructure. Images still come from the same registries you used with Docker; Kubernetes adds a control plane that continuously reconciles cluster state with your declared manifests.

flowchart TB
    subgraph DEV["Developer Workflow"]
        GIT["Git Repository<br/>manifests / Helm"]
        CI["CI/CD Pipeline"]
        REG["Container Registry<br/>Docker Hub / ECR / GCR"]
    end

    subgraph CP["Kubernetes Control Plane"]
        API["API Server"]
        ETCD["etcd — cluster state"]
        SCHED["Scheduler"]
        CM["Controller Manager"]
        API --> ETCD
        SCHED --> API
        CM --> API
    end

    subgraph DATA["Data Plane — Worker Nodes"]
        KUBELET["kubelet"]
        RUNTIME["container runtime<br/>containerd / CRI-O"]
        POD1["Pod"]
        POD2["Pod"]
        KUBELET --> RUNTIME
        RUNTIME --> POD1
        RUNTIME --> POD2
    end

    GIT --> CI
    CI --> REG
    CI --> API
    REG --> RUNTIME
    API --> KUBELET

Theory¶

Why Orchestration Exists¶

A single Docker host handles docker run, bridge networks, and named volumes well. Production microservices introduce problems that multiply with every new service:

Orchestration turns imperative operations ("run this container on host-3") into declarative intent ("I want three replicas of this image, always healthy").

What Is Kubernetes?¶

Kubernetes is an open-source container orchestration platform originally designed by Google, based on lessons from internal systems Borg and Omega. The Cloud Native Computing Foundation (CNCF) hosts the project. Kubernetes:

• Schedules Pods onto nodes based on CPU, memory, affinity, and taints
• Maintains desired replica counts via controllers (Deployment, StatefulSet, DaemonSet)
• Exposes workloads through Services, Ingress, and Gateway API
• Stores configuration in etcd and serves it through a REST API
• Integrates with cloud load balancers, persistent disks, and identity systems

Kubernetes runs the same OCI images you built for Docker. The runtime layer changed (containerd, CRI-O instead of dockerd as the default), but your Dockerfile and registry workflow stay the same.

The Declarative Reconciliation Model¶

Kubernetes follows a control loop pattern:

1. You submit desired state — YAML manifest or kubectl apply
2. The API server persists objects in etcd
3. Controllers watch for changes and act — create Pods, update Endpoints, attach volumes
4. The scheduler assigns unscheduled Pods to suitable nodes
5. The kubelet on each node pulls images and starts containers via the CRI runtime

If a Pod crashes, the ReplicaSet controller notices the mismatch (desired: 3, actual: 2) and creates a replacement. This is self-healing without custom scripts.

flowchart LR
    USER["Engineer / CI"]
    YAML["Desired State<br/>YAML manifest"]
    API["API Server"]
    CTRL["Controllers"]
    ACTUAL["Actual State<br/>running Pods"]

    USER --> YAML
    YAML --> API
    API --> CTRL
    CTRL --> ACTUAL
    ACTUAL --> CTRL
    CTRL --> API

Kubernetes vs Other Orchestrators¶

If you completed Docker Swarm Orchestration Basics, think of Kubernetes as Swarm with a larger API surface, stronger community tooling (Helm, Argo CD, Prometheus operators), and a steeper learning curve — justified when you need portability and ecosystem depth.

The Cloud-Native Stack¶

Kubernetes is one layer in the CNCF cloud-native landscape:

Learning Kubernetes after Docker follows the natural DevOps progression documented in From Docker to Kubernetes: package with containers, orchestrate with Kubernetes, automate with GitOps.

Key Concepts Preview¶

You will dive deep into these in later tutorials; for now, know the names:

When to Adopt Kubernetes¶

Most organizations adopt managed Kubernetes (EKS, GKE, AKS) rather than self-hosting the control plane. Local tools like minikube and kind (covered in Installing Kubernetes and kubectl) replicate the API for learning.

Hands-on Lab¶

These steps build intuition without requiring a cluster yet. If you already have kubectl configured, skip to Step 5.

Step 1 – Confirm Docker and container knowledge¶

Command:

docker --version 2>/dev/null || echo "Docker optional for this lab"
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" 2>/dev/null | head -5

Explanation: Kubernetes schedules containers, not Docker-specific objects. Your Docker skills transfer directly. If Docker is not installed, you can still complete the conceptual parts of this lab.

Expected output:

Docker version 27.x.x, build ...
NAMES     STATUS    PORTS

Step 2 – Explore orchestration vocabulary¶

Command:

cat <<'EOF' > /tmp/k8s-vocab.txt
Orchestrator  — software that schedules and manages containers at scale
Control plane — brain of the cluster (API, scheduler, controllers, etcd)
Data plane    — worker nodes running your application Pods
Declarative   — describe WHAT you want; system figures out HOW
Imperative    — describe exact commands (kubectl run — learning only)
Reconciliation — loop comparing desired vs actual state
EOF
cat /tmp/k8s-vocab.txt

Explanation: Internalize these terms before reading architecture docs. They appear in every Kubernetes conversation and interview.

Step 3 – Read the Docker-to-K8s mapping¶

Command:

echo "Open docs/docker/from-docker-to-kubernetes.md and review the mapping table"
echo "Key mappings: container→Pod, docker compose→Deployment+Service, volume→PVC"

Explanation: The mapping table in From Docker to Kubernetes is your Rosetta Stone. Re-read it whenever a Kubernetes object feels unfamiliar.

Step 4 – Survey the CNCF landscape¶

Command:

curl -sfL https://landscape.cncf.io/data/full.json 2>/dev/null | head -c 200 \
  || echo "Visit https://landscape.cncf.io/ — find Kubernetes in the Orchestration row"

Explanation: Kubernetes sits at the center of hundreds of complementary projects. You do not need to learn them all at once — focus on kubectl, Deployments, Services, and Ingress first.

Step 5 – Check if kubectl is available¶

Command:

command -v kubectl && kubectl version --client 2>/dev/null || echo "kubectl not installed — Tutorial 3 covers installation"
command -v minikube && minikube version 2>/dev/null || true
command -v kind && kind version 2>/dev/null || true

Explanation: Local cluster tools come in Tutorial 3. Knowing what is missing now helps you plan lab time.

Step 6 – Draft your first declarative manifest (do not apply yet)¶

Command:

mkdir -p ~/k8s-lab/manifests
cat <<'EOF' > ~/k8s-lab/manifests/hello-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: hello-k8s
  labels:
    app: hello
spec:
  containers:
    - name: nginx
      image: nginx:1.27-alpine
      ports:
        - containerPort: 80
  restartPolicy: Never
EOF
cat ~/k8s-lab/manifests/hello-pod.yaml

Explanation: This Pod manifest declares desired state. After installing a cluster, you will apply it with kubectl apply -f. Notice there is no host specified — the scheduler decides.

Step 7 – Document your learning baseline¶

Command:

echo "=== Kubernetes Learning Baseline ==="
echo "Docker track: from-docker-to-kubernetes completed (Y/N)"
echo "kubectl: $(command -v kubectl >/dev/null && kubectl version --client -o yaml 2>/dev/null | grep gitVersion | head -1 || echo 'not installed')"
echo "Local cluster: $(command -v minikube >/dev/null && echo minikube || command -v kind >/dev/null && echo kind || echo 'none yet')"
echo "Next tutorial: kubernetes-architecture-and-components.md"

Explanation: Capture your starting point. Include this in personal notes when tracking progress through the Kubernetes track.

Commands & Code¶

Orchestration readiness checklist script¶

Save as ~/bin/k8s-preflight.sh:

#!/usr/bin/env bash
# k8s-preflight.sh — verify readiness for Kubernetes learning labs
set -euo pipefail

section() { printf '\n=== %s ===\n' "$1"; }

section "Container foundation"
if command -v docker >/dev/null 2>&1; then
  docker --version
else
  echo "Docker not found — optional for K8s labs using containerd directly"
fi

section "Kubernetes CLI"
if command -v kubectl >/dev/null 2>&1; then
  kubectl version --client 2>/dev/null | head -3
else
  echo "kubectl not installed — complete Tutorial 3"
fi

section "Local cluster tool"
if command -v minikube >/dev/null 2>&1; then
  echo "minikube: $(minikube version --short 2>/dev/null || minikube version | head -1)"
elif command -v kind >/dev/null 2>&1; then
  kind version
else
  echo "Neither minikube nor kind found — install in Tutorial 3"
fi

section "System resources"
echo "CPUs:  $(nproc 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null || echo 'unknown')"
echo "RAM:   $(free -h 2>/dev/null | awk '/Mem:/{print $2}' || echo 'check Activity Monitor')"
echo "Recommend: 4+ GB RAM free for local cluster"

Make executable: chmod +x ~/bin/k8s-preflight.sh && ~/bin/k8s-preflight.sh

Common Mistakes¶

Best Practices¶

Troubleshooting¶

Summary¶

• Container orchestration automates scheduling, scaling, healing, and networking across many hosts — problems that docker run alone cannot solve at scale
• Kubernetes is the dominant orchestrator, using a declarative reconciliation model: you declare desired state; controllers continuously align reality
• Kubernetes runs the same OCI images from your Docker CI pipeline; it adds a control plane (API, etcd, scheduler, controllers) and worker nodes (kubelet, runtime, Pods)
• Compare alternatives (Swarm, ECS, Nomad) honestly — Kubernetes shines for multi-service, multi-team, portable platforms
• The REBASH Kubernetes track builds on the Docker track, starting with architecture, installation, kubectl, and Pods
• Next: Kubernetes Architecture and Components

Interview Questions¶

1. What is container orchestration, and why is it needed?
2. Explain Kubernetes' declarative reconciliation model in your own words.
3. What are the main components of the Kubernetes control plane?
4. How does Kubernetes relate to Docker? Do you still use Dockerfiles?
5. What is a Pod, at a high level?
6. Compare Kubernetes to Docker Swarm. When would you choose each?
7. What is etcd's role in a Kubernetes cluster?
8. Name three problems Kubernetes solves that a single Docker host does not.
9. What is the CNCF, and why does it matter for Kubernetes?
10. When would you not adopt Kubernetes?

Related Tutorials¶

• Kubernetes – Category Overview
• From Docker to Kubernetes — recommended prerequisite
• Docker – Category Overview
• Kubernetes Architecture and Components (next in Module 1)
• Learning Paths – DevOps Engineer

References¶

• Kubernetes – What is Kubernetes?
• Kubernetes – Components
• CNCF – Cloud Native Definition
• CNCF Landscape
• Kubernetes – Declarative Management
• REBASH Academy – Docker Overview
• REBASH Academy – Documentation Standards