Kubernetes: A Beginner's Guide to Container Orchestration

DevOps DevOps 8 min read 1536 words Beginner ExcellentWiki Editorial Team

Kubernetes (often abbreviated as K8s) is an open-source container orchestration platform originally designed by Google. It automates the deployment, scaling, and management of containerized applications. While Docker handles individual containers, Kubernetes manages fleets of containers across multiple machines.

This guide walks through Kubernetes fundamentals from the ground up — no prior orchestration experience required.

Why Kubernetes?

Running containers on a single server is simple. You install Docker, run docker compose up, and your application is live. But production systems have requirements that single-server setups cannot meet:

High availability — If a container crashes, it should restart automatically
Scaling — Traffic spikes require more instances; traffic lulls require fewer
Rolling updates — Deploy new versions without downtime
Service discovery — Containers need to find each other by name, not IP
Load balancing — Distribute traffic across multiple instances
Storage management — Persistent data must survive container restarts

Kubernetes solves all of these problems with a declarative approach — you describe the desired state, and Kubernetes works to maintain it.

Core Concepts

Cluster

A Kubernetes cluster consists of a control plane and worker nodes. The control plane manages the cluster state, scheduling, and API requests. Worker nodes run your applications.

┌──────────────────────────────────┐
│         Control Plane            │
│  ┌──────┐ ┌──────┐ ┌─────────┐  │
│  │ API  │ │Sched │ │Control  │  │
│  │Server│ │-uler │ │Manager  │  │
│  └──────┘ └──────┘ └─────────┘  │
├──────────────────────────────────┤
│         Worker Nodes             │
│  ┌──────────┐ ┌──────────┐      │
│  │  Node 1  │ │  Node 2  │ ...  │
│  │ ┌──┐ ┌──┐│ │ ┌──┐ ┌──┐│      │
│  │ │P │ │P ││ │ │P │ │P ││      │
│  │ │o │ │o ││ │ │o │ │o ││      │
│  │ │d │ │d ││ │ │d │ │d ││      │
│  └──┘ └──┘│ │ └──┘ └──┘│      │
│  └──────────┘ └──────────┘      │
└──────────────────────────────────┘

Pods

A pod is the smallest deployable unit in Kubernetes. It represents one or more containers that share storage and network. Most pods run a single container, but multi-container pods are used for sidecar patterns — for example, a web server with a logging sidecar.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
    - name: nginx
      image: nginx:stable
      ports:
        - containerPort: 80

kubectl apply -f pod.yaml
kubectl get pods
kubectl describe pod nginx-pod

Deployments

A deployment manages a set of identical pods. It handles rolling updates, scaling, and self-healing. If a pod crashes, the deployment replaces it automatically.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: app
          image: myapp:1.0.0
          ports:
            - containerPort: 8080

kubectl scale deployment web-app --replicas=5
kubectl set image deployment/web-app app=myapp:1.0.1
kubectl rollout status deployment/web-app

The replicas field tells Kubernetes to maintain three identical pod instances. When you update the image, Kubernetes performs a rolling update — replacing pods one by one to avoid downtime.

Services

Pods are ephemeral — they come and go, and their IP addresses change. A service provides a stable network endpoint that load balances across a set of pods.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

Service types:

ClusterIP — Internal cluster access only
NodePort — Exposes on each node’s IP at a static port
LoadBalancer — Provisions a cloud load balancer (AWS ELB, GCP LB)

Ingress

Ingress exposes HTTP and HTTPS routes from outside the cluster to services. It is the most common way to route external traffic to your applications.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

You need an ingress controller running in the cluster — NGINX Ingress Controller and Traefik are popular choices.

Practical Examples

Deploying a Full Stack

# database-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16
          env:
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: db-secret
                  key: password
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: pgdata
      volumes:
        - name: pgdata
          persistentVolumeClaim:
            claimName: postgres-pvc

ConfigMaps and Secrets

Use ConfigMaps for non-sensitive configuration and Secrets for sensitive data:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  NODE_ENV: production
  LOG_LEVEL: info

kubectl create secret generic db-secret --from-literal=password=s3cret
kubectl get secrets

Cluster Management

kubectl Commands

kubectl get nodes                    # list cluster nodes
kubectl get pods -A                  # all pods in all namespaces
kubectl logs -f deployment/web-app   # follow logs
kubectl exec -it pod-name -- bash    # shell into a pod
kubectl describe pod pod-name        # detailed pod info
kubectl delete pod pod-name          # delete a pod

Monitoring

kubectl top pods     # CPU and memory usage
kubectl top nodes    # node resource usage

For production monitoring, deploy the metrics server and use tools like Prometheus and Grafana.

Best Practices

Use namespaces — Isolate environments (dev, staging, prod) within a single cluster
Set resource limits — Prevent one pod from starving others with resources.requests and resources.limits
Use liveness and readiness probes — Kubernetes checks if your app is alive and ready to serve traffic
Prefer Deployments over bare Pods — Deployments provide self-healing, scaling, and rolling updates
Use Helm — Package complex applications into reusable charts
Enable RBAC — Restrict who can create, modify, or delete resources

Summary

Kubernetes is the industry standard for container orchestration. Its declarative model — you specify the desired state, and Kubernetes handles the rest — makes it possible to run resilient, scalable applications in production. Start with Deployments and Services, add Ingress for external traffic, and adopt Helm charts as your applications grow in complexity.

Kubernetes Architecture Deep Dive

Control Plane Components

The kube-apiserver is the central management plane — all components and CLI tools interact with the cluster exclusively through the API server. It authenticates requests, validates them against admission controllers, and persists cluster state to etcd. The etcd distributed key-value store is the single source of truth for the entire cluster — storing all configurations, secrets, and state. Running etcd requires careful operation: regular backups, TLS encryption for all communication, and proper disk performance with SSD storage. The kube-scheduler watches for unassigned pods, filters nodes that don’t meet resource or constraint requirements, scores the remaining nodes using configurable plugins (like LeastRequestedPriority or NodeResourcesFit), and assigns each pod to the highest-scoring node. The kube-controller-manager runs controller loops that reconcile desired state with actual state — the ReplicaSet controller ensures the right number of pod replicas, the Deployment controller manages rolling updates, and the Namespace controller handles namespace lifecycle.

Node Components

Every Kubernetes node runs the kubelet, kube-proxy, and a container runtime. The kubelet is the primary node agent that registers the node with the cluster, creates and manages pods on that node by communicating with the container runtime, and reports node and pod status back to the API server. The container runtime (containerd, CRI-O, or Docker) pulls images and manages container lifecycle through the Container Runtime Interface (CRI). The kube-proxy maintains network rules on each node, implementing service abstraction through iptables, IPVS, or eBPF. It load balances traffic across pods in a service by rewriting packet destinations. Understanding these components is essential for debugging cluster issues — a node showing NotReady status requires checking the kubelet service, container runtime health, and network connectivity to the control plane.

Pod Lifecycle

Pods progress through distinct phases: Pending (scheduled but containers not started), Running (all containers running), Succeeded (all containers completed successfully for batch workloads), Failed (at least one container exited with error), and Unknown (node communication lost). Within a pod, containers go through states: Waiting (image pull, container creation), Running (executing), and Terminated (exited). Readiness probes determine whether a pod should receive traffic — a pod failing readiness is removed from service endpoints. Liveness probes determine if a pod needs restart — failure triggers the kubelet to recreate the container. Startup probes protect slow-starting containers from being killed by liveness probes during initialization. Proper probe configuration prevents cascading failures during deployment and traffic shifts.

Frequently Asked Questions

What is the difference between Kubernetes and Docker? Docker is a container runtime that packages and runs individual containers. Kubernetes is an orchestration platform that manages clusters of containers across multiple machines. Kubernetes can use Docker as the container runtime, but also supports containerd and CRI-O. Docker Compose manages multi-container applications on a single host, while Kubernetes manages multi-container applications across a cluster.

Do I need Kubernetes for my application? Kubernetes is beneficial when you need high availability, automatic scaling, rolling updates, and self-healing for containerized applications. It adds operational complexity. For a single server running a few containers, Docker Compose or a Platform-as-a-Service (Heroku, Railway) is simpler and more appropriate.

What is a pod vs a container? A pod is the smallest deployable unit in Kubernetes and contains one or more containers that share the same network namespace, storage volumes, and lifecycle. Containers in the same pod communicate via localhost and must be co-scheduled on the same node. A single-container pod is the most common pattern — the pod wraps a single application container.

For a comprehensive overview, read our article on Blue Green Deployments.

For a comprehensive overview, read our article on Ci Cd Pipeline Guide.

Share this article

X LinkedIn Facebook Email