Container Orchestration¶

Overview¶

Container orchestration automates the deployment, scaling, networking, and management of containerized applications across a cluster of machines. When running containers at scale, manual management becomes impractical — orchestration platforms handle placing containers on appropriate nodes, restarting failed containers, load balancing traffic, and scaling up or down based on demand.

Kubernetes is the dominant orchestration platform. It introduces abstractions like Pods (groups of containers), Deployments (desired state declarations), Services (stable network endpoints), and Namespaces (logical isolation). The control plane manages the cluster state while worker nodes run the actual workloads.

How It Works¶

Why Orchestration?¶

Running containers on a single machine works for development, but in production you need:

High availability — if a machine fails, applications keep running on healthy machines
Scalability — add more container instances as demand grows
Automated recovery — crashed containers are restarted automatically
Service discovery — containers need stable ways to find and communicate with each other
Centralized management — a single place to deploy, update, and monitor all applications

Kubernetes Architecture¶

A Kubernetes cluster consists of nodes (machines) divided into two roles:

Control Plane (CP) runs the cluster management components:

API Server — the central control point. All commands (kubectl) and internal communication go through it
Scheduler — decides which worker node should run a new Pod
Controllers — watch the cluster state and make corrections (e.g., restart failed Pods)
etcd — key-value store holding all cluster state and configuration

Worker Nodes run the actual workloads:

kubelet — agent that receives instructions from the API server and manages containers on the node
kube-proxy — manages networking rules to route traffic to the correct containers
Container runtime — the engine that actually runs containers (containerd, Docker, etc.)

In production, a minimum of 3 nodes is recommended (1 CP + 2 workers). For learning, a single node running both roles (like K3s) is sufficient.

Core Resources¶

Pods¶

A Pod is the smallest deployable unit in Kubernetes — a group of one or more containers that share:

A single IP address and port space
Access to the same storage volumes
The same lifecycle (started and stopped together)

Typically, a Pod runs one main application container plus optional supporting containers (logging, proxy, etc.).

Namespaces¶

Namespaces provide logical isolation within a cluster. They separate resources into virtual compartments, controlling access and preventing naming conflicts. Default namespaces include:

default — where resources go if no namespace is specified
kube-system — reserved for control plane components

You create custom namespaces to organize applications (e.g., lab11, production, monitoring).

Deployments¶

A Deployment manages the lifecycle of Pods through ReplicaSets. It declares:

How many replicas (copies) of a Pod should run
Which container image to use
How to handle updates (rolling updates)

Deployments automatically restart failed Pods and redistribute them to healthy nodes. They are the standard way to run stateless applications.

Services¶

A Service provides a stable network endpoint for a set of Pods. Unlike Pods (whose IPs change on restart), a Service maintains a static IP throughout its lifetime.

Service types:

ClusterIP (default) — accessible only within the cluster. Gets an auto-resolving DNS name: <service>.<namespace>.svc
NodePort — opens a specific port on all nodes, routing traffic to the Service. Accessible from outside the cluster.
LoadBalancer — requests a cloud provider load balancer to route external traffic
ExternalName — maps a Service to an external DNS name

Ingress¶

Ingress resources configure a cluster-wide reverse proxy (the IngressController) to route HTTP/HTTPS traffic to Services based on hostnames or URL paths. This eliminates the need for each service to use a different port.

K3s includes Traefik as the default IngressController. Other options include Nginx Ingress and Envoy.

Volumes in Kubernetes¶

Kubernetes supports multiple storage types:

Ephemeral volumes exist only while the Pod is running:

emptyDir — temporary directory, deleted when the Pod stops
ConfigMap — key-value configuration data mounted as read-only files
Secret — sensitive data (passwords, keys) stored as base64-encoded values

Persistent volumes outlive Pods:

PersistentVolume (PV) — a piece of storage provisioned in the cluster (NFS, local disk, cloud storage)
PersistentVolumeClaim (PVC) — a user's request for storage, which binds to an available PV

This PV/PVC model separates storage provisioning (admin responsibility) from storage consumption (developer/user responsibility).

Declarative Configuration¶

All Kubernetes resources are defined as YAML manifests and applied with kubectl apply -f <file>.yaml. Multiple resources can be combined in a single file separated by ---. This makes the entire deployment reproducible and version-controllable.

Key Terminology¶

Cluster: A set of nodes (machines) managed by Kubernetes as a single system.
Node: A physical or virtual machine in the cluster. Runs either as a control plane node or a worker node.
Pod: The smallest deployable unit — one or more containers with shared networking and storage.
Deployment: A controller that manages ReplicaSets to ensure the desired number of Pod replicas are running.
ReplicaSet: Ensures a specified number of identical Pods are running at all times.
Service: A stable network endpoint that routes traffic to a set of Pods, surviving Pod restarts and IP changes.
Ingress: A resource that configures HTTP/HTTPS routing rules for the cluster's IngressController (reverse proxy).
ConfigMap: Non-sensitive configuration data stored as key-value pairs, mountable into Pods as files or environment variables.
Secret: Sensitive data (passwords, tokens) stored as base64-encoded values. Similar to ConfigMap but intended for confidential information.
PersistentVolume (PV): A piece of cluster storage, provisioned by an administrator or dynamically.
PersistentVolumeClaim (PVC): A user's request for storage that binds to a matching PV.
DaemonSet: Like a Deployment, but ensures exactly one Pod replica runs on every node. Used for monitoring agents, log collectors, etc.

Common Ports and Protocols¶

Port	Protocol	Purpose
6443	TCP	Kubernetes API server
10250	TCP	kubelet API
8080/8443	TCP	Traefik IngressController (HTTP/HTTPS)
30000–32767	TCP	NodePort service range

Why It Matters¶

As a system administrator, you will:

Deploy and manage containerized applications at scale using Kubernetes
Define application state declaratively in YAML manifests
Use Services and Ingress to expose applications with stable networking
Manage configuration and secrets separately from container images
Set up persistent storage for stateful workloads (databases)
Monitor and debug Pods using kubectl logs, kubectl describe, and kubectl exec

Common Pitfalls¶

YAML indentation errors — Kubernetes manifests are YAML; even one wrong space causes parse failures. Watch for trailing empty lines too.
Forgetting namespace flags — kubectl get pods only shows the default namespace. Use -n <namespace> or --all-namespaces.
Port conflicts — if Kubernetes and existing services (Apache) use the same ports, one will fail to start. Configure IngressController ports to avoid conflicts.
Not checking Events — kubectl describe pod/<name> shows Events that reveal why a Pod failed to start (image pull errors, volume mount issues, etc.).
Hardcoding Pod IPs — Pod IPs change on restart. Always use Services for inter-Pod communication.
Storing secrets in plaintext — use Kubernetes Secrets (or external vault solutions) instead of hardcoding passwords in manifests.
Not opening firewall ports — Kubernetes API (6443), NodePort services, and IngressController ports all need firewall rules.