Introduction to Orchestration: Kubernetes

Docker Swarm (File 16) is excellent for simplicity, but Kubernetes (K8s) is the undisputed industry standard for container orchestration. Born at Google and now managed by the CNCF, it powers the majority of large-scale container deployments in the world.

Kubernetes is not just a tool for running containers; it is a platform for building platforms. It offers a much richer, more extensible feature set than Swarm, but it comes with a steeper learning curve.

This guide translates your Docker knowledge into Kubernetes concepts.

1. The Architecture: Control Plane and Nodes

Like Swarm, Kubernetes follows a master/worker architecture, but the components are more specialized.

The Control Plane (The Brains)

This is the "master" node. It makes global decisions about the cluster (scheduling) and detects/responds to cluster events (starting up a new pod).

• API Server: The front end for the Kubernetes control plane. All tools (kubectl, dashboards) talk to this API.

• etcd: A consistent, highly-available key-value store used as Kubernetes' backing store for all cluster data (the "source of truth").

• Scheduler: Watches for newly created Pods with no assigned node, and selects a node for them to run on.

• Controller Manager: Runs controller processes (e.g., Node Controller, Job Controller) that regulate the state of the system.

The Nodes (The Muscle)

These are the worker machines that run your applications.

• Kubelet: An agent that runs on each node. It ensures that containers are running in a Pod.

• Kube-Proxy: Maintains network rules on nodes. These rules allow network communication to your Pods.

• Container Runtime: The software that is responsible for running containers (e.g., containerd).

2. Core Concepts: Mapping Docker to Kubernetes

In Docker, the atomic unit is the Container. In Kubernetes, the atomic unit is the Pod.

The Pod

A Pod is the smallest deployable object in Kubernetes.

• A Pod represents a single instance of a running process in your cluster.

• Key Difference: A Pod can contain multiple tightly-coupled containers (e.g., a main app container and a helper "sidecar" container for logging).

• Networking: All containers in a Pod share the same IP address and localhost. They can talk to each other on localhost.

• Storage: They can share the same mounted Volumes.

The Deployment (Managing Pods)

You almost never create a Pod directly. Instead, you create a Deployment.

• A Deployment provides declarative updates for Pods and ReplicaSets.

• It is analogous to a Service in Docker Swarm.

• You describe a desired state in a Deployment (e.g., "Run 3 replicas of nginx:1.14"). The Deployment Controller changes the actual state to the desired state at a controlled rate.

The Service (Networking)

In Kubernetes, Pods are ephemeral. They die and get new IPs. A Service is an abstraction which defines a logical set of Pods and a policy by which to access them.

• It provides a stable IP address and DNS name for a set of Pods.

• It acts as an internal Load Balancer.

• Analogy: In Docker Compose, the service name (e.g., db) acts as the DNS name. In K8s, you must explicitly create a Service object to get this behavior.

The Ingress (External Access)

A Service exposes an application inside the cluster. An Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.

• It acts as your external Load Balancer / Reverse Proxy (like Nginx or Traefik).

3. Declarative Management with YAML

Kubernetes is purely declarative. You define everything in YAML manifests and apply them using the kubectl command-line tool.

Example: nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3                  # Desired state: 3 copies
  selector:
    matchLabels:
      app: nginx
  template:                    # The Pod Template
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2    # The Docker Image
        ports:
        - containerPort: 80

Applying the Manifest:

# Create or update the resources defined in the file
kubectl apply -f nginx-deployment.yaml

4. Key Differences from Docker Swarm

Feature	Docker Swarm	Kubernetes
Installation	Built-in to Docker Engine (easy).	Separate, complex installation (or managed cloud service).
Atomic Unit	Container	Pod (group of containers)
Networking	Automatic mesh via service name.	Explicit Service objects required.
Load Balancing	Built-in L4 load balancer.	Requires Ingress Controller for L7.
Volumes	Docker Volumes.	PersistentVolume (PV) & PersistentVolumeClaim (PVC) system (much more complex/powerful).
Config	Environment variables / Secrets.	ConfigMaps / Secrets.

5. Practical Workflow: "kubectl"

The kubectl CLI is your cockpit for Kubernetes.

• kubectl get pods - List all running pods.

• kubectl get services - List networking services.

• kubectl describe pod <pod-name> - Show detailed debug info/events for a pod.

• kubectl logs <pod-name> - Print the logs of a container in a pod.

• kubectl exec -it <pod-name> -- /bin/bash - Get a shell inside a running pod.

• kubectl delete -f my-file.yaml - Delete resources defined in a file.

6. Namespaces (Virtual Clusters)

Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called Namespaces.

• Use Case: You can have a dev, staging, and prod namespace on the same cluster, isolating resources and permissions between teams.

• Docker Analogy: There isn't a direct Docker equivalent, but it's similar to running multiple separate Docker Compose projects.