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?

CapabilityDocker (standalone)Kubernetes
Auto-restart on crashManual or --restart flagBuilt-in with liveness probes
ScalingManual docker runReplicas, HPA auto-scaling
Zero-downtime deployManual coordinationRolling updates built-in
Multi-host schedulingNot supportedCore feature
Service discoveryLimited to one hostCluster-wide DNS
Config/secret managementManual env filesConfigMaps, 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