Kubernetes Fundamentals
Kubernetes (k8s) is a container orchestration platform that manages the lifecycle of containerized applications across a cluster of machines. Where Docker runs containers on a single host, Kubernetes decides which host in your cluster should run each container, restarts failed containers automatically, scales applications up or down based on load, and handles rolling deployments with zero downtime. It is the standard platform for running production containers at scale.
Why Kubernetes over plain Docker?
| Capability | Docker (standalone) | Kubernetes |
|---|---|---|
| Auto-restart on crash | Manual or --restart flag | Built-in with liveness probes |
| Scaling | Manual docker run | Replicas, HPA auto-scaling |
| Zero-downtime deploy | Manual coordination | Rolling updates built-in |
| Multi-host scheduling | Not supported | Core feature |
| Service discovery | Limited to one host | Cluster-wide DNS |
| Config/secret management | Manual env files | ConfigMaps, Secrets objects |
Cluster architecture
Kubernetes Cluster:
Control Plane (master node):
+------------------------------------------+
| API Server ← all kubectl commands hit here
| etcd ← cluster state database (source of truth)
| Scheduler ← decides which node runs each pod
| Controller Manager ← watches state, reconciles to desired
+------------------------------------------+
Worker Nodes (1 to N):
+------------------------------------------+
| kubelet ← node agent, runs pods per API Server instructions
| kube-proxy ← manages iptables rules for Service routing
| Container Runtime (containerd) ← actually runs containers
+------------------------------------------+
Your application runs in Pods on the worker nodes.
kubectl commands go to the API Server, which updates etcd,
and controllers act on those changes.Core Kubernetes objects
Object hierarchy:
Deployment ← "run 3 replicas of this app, roll out updates safely"
ReplicaSet ← "ensure exactly 3 pods are always running"
Pod ← "one or more containers, the smallest deployable unit"
Container ← your actual Docker image running here
Service ← "stable network endpoint for a set of pods"
ConfigMap ← "non-sensitive configuration data"
Secret ← "sensitive data (passwords, tokens)"
PersistentVolume ← "cluster-level storage resource"
Namespace ← "logical partition of the cluster for isolation"kubectl basics
# Check cluster and node status:
kubectl cluster-info
kubectl get nodes
kubectl get nodes output
NAME STATUS ROLES AGE VERSION
controlplane Ready control-plane 30d v1.29.2
worker-01 Ready 30d v1.29.2
worker-02 Ready 30d v1.29.2
# Get all resources in the default namespace:
kubectl get all
# Describe a resource (detailed status, events, conditions):
kubectl describe node worker-01
kubectl describe pod mypod-abc123
# Apply a YAML manifest:
kubectl apply -f deployment.yaml
# Watch resources update in real-time:
kubectl get pods -w
# Get events (crucial for debugging why pods won't start):
kubectl get events --sort-by='.lastTimestamp'
# Execute a command inside a running pod:
kubectl exec -it mypod-abc123 -- /bin/bash
# View logs from a pod:
kubectl logs mypod-abc123
kubectl logs mypod-abc123 -f # Follow
kubectl logs mypod-abc123 --previous # Logs from previous (crashed) container
Conclusion
The mental model for Kubernetes: you describe the desired state of your application in YAML manifests (I want 3 replicas of this container running), and Kubernetes continuously works to make the actual state match your desired state. If a pod crashes, the ReplicaSet controller notices the actual count dropped to 2 and creates a new pod. This reconciliation loop is the core of how Kubernetes provides self-healing. Start with kubectl get events and kubectl describe pod whenever something does not work — they reveal what the scheduler and kubelet are actually doing.
FAQ
Why should administrators understand Kubernetes Fundamentals?+
Because this topic affects planning decisions, server lifecycle, compatibility, support expectations, or how you reason about Ubuntu systems before making operational changes.
Do I need a lab for this topic?+
A lab is useful for checking commands and seeing the concept on a real Ubuntu machine, but the main value is understanding the decision, tradeoff, or system behavior clearly.
How should I use this knowledge in production?+
Use it to make better choices, document why those choices were made, and avoid rushed changes that ignore support windows, compatibility, stability, or operational risk.
Need help with Ubuntu administration?
Work directly with Muhammad Irfan Aslam for Ubuntu Server, Linux, cloud, Docker, DevOps, CI/CD, or infrastructure troubleshooting support.
Hire Me for Support