A production-grade reference covering container orchestration — from fundamentals to advanced operations, security, and scaling.
01🎯
Introduction to Kubernetes
Container Orchestration Fundamentals
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It solves the challenges of running containers in production — monitoring health, scaling on demand, and ensuring zero-downtime deployments.
Problems Kubernetes Solves
💀
Container Failures
What if a container crashes? Kubernetes monitors health and automatically restarts failed containers — this is called self-healing.
📈
Traffic Spikes
What if load increases 10x? Kubernetes scales your app by creating more replicas and load balancing traffic across them.
🔄
Deployment Downtime
What if deployment breaks the app? Kubernetes does rolling updates — replacing containers one by one with zero downtime.
⏪
Rollback Needed
What if the new version has bugs? Kubernetes can rollback to a previous version with a single command.
Key Features
Feature
Description
Self-Healing
Automatically restarts failed containers and replaces pods when nodes die.
Auto Scaling
Scales applications up/down based on CPU, memory, or custom metrics.
Load Balancing
Distributes traffic across multiple pod replicas automatically.
Rolling Updates
Deploys new versions gradually without downtime.
Secret Management
Stores and manages sensitive data like passwords and API keys.
Automatic Bin Packing
Places containers on nodes based on resource requirements.
Kubernetes (K8s) is the most popular choice with advanced features and support from all major cloud providers. The name comes from Greek meaning "helmsman" — the person who steers a ship carrying containers.
02🏗️
Kubernetes Architecture
Control Plane & Worker Nodes
A Kubernetes cluster consists of a Control Plane (master) that manages the cluster, and Worker Nodes that run your applications. The control plane makes global decisions while worker nodes provide the runtime environment.
Control Plane Components
🌐
API Server
The front door to Kubernetes. All commands (kubectl, UI, SDK) go through the API server. It validates and processes requests.
💾
etcd
Distributed key-value store holding all cluster data — nodes, pods, configs, secrets. The single source of truth.
📋
Scheduler
Watches for new pods and assigns them to nodes based on resource requirements, affinity rules, and constraints.
🔄
Controller Manager
Runs controllers that maintain desired state — ReplicaSet controller, Node controller, Endpoint controller, etc.
Worker Node Components
🐳
Container Runtime
Software that runs containers (Docker, containerd, CRI-O). Pulls images and manages container lifecycle.
📡
Kubelet
Agent on each node that ensures containers are running in pods. Reports node and pod status to control plane.
🔀
Kube-proxy
Network proxy maintaining network rules on nodes. Handles routing traffic to correct pods and load balancing.
↳ Request Flow
kubectl
User command
→
API Server
Validates request
→
Scheduler
Picks node
→
Kubelet
Creates pod
⚡ Pro Tip
In production, run multiple control plane nodes for high availability. If etcd loses data, you lose your entire cluster state — always have backups!
03⚙️
Setup Kubernetes
Local Development & kubectl
For local development, use Minikube, Kind, or k3s to spin up a cluster on your machine. For production, use managed services like EKS, GKE, or AKS. kubectl is the CLI for interacting with any Kubernetes cluster.
BASHkubectl <command> <resource-type> <name> <flags>
# Examples:
kubectl get pods # List all pods
kubectl get pods -o wide # More details
kubectl describe pod inventory-pod # Detailed info
kubectl delete pod inventory-pod # Delete pod
kubectl apply -f manifest.yaml # Apply config file
kubectl commands follow a consistent pattern: verb (get, create, delete, apply) + resource type (pods, services, deployments) + name + flags (-o yaml, -n namespace).
04📦
Kubernetes Pods
The Smallest Deployable Unit
A Pod is the smallest deployable unit in Kubernetes — a wrapper around one or more containers that share network and storage. Containers in a pod can communicate via localhost and share volumes.
Why Pods?
🔗
Shared Network
Containers in a pod share IP address and ports. They communicate via localhost.
💾
Shared Storage
Containers can mount the same volumes for data sharing.
♻️
Co-scheduling
Related containers (app + sidecar) are always scheduled together on same node.
🎯
Single IP
Each pod gets one IP. Multiple containers share it via different ports.
Pods are ephemeral — they can be killed and recreated anytime. Never deploy pods directly. Use Deployments or StatefulSets for production workloads.
05♾️
Deployments & ReplicaSets
Self-Healing & Rolling Updates
ReplicaSets ensure a specified number of pod replicas are always running. Deployments wrap ReplicaSets and add rollout management — enabling zero-downtime updates and easy rollbacks.
Why Not Just Pods?
🔄
Self-Healing
If a pod dies, ReplicaSet creates a replacement automatically.
📈
Scaling
Increase replicas from 2 to 10 with one command.
🔀
Load Distribution
Traffic spreads across replicas via Services.
⏪
Rollbacks
Deployment keeps history, rollback to any previous version.
Use kubernetes.io/change-cause annotation to document changes. It appears in rollout history and helps teams understand what changed in each revision.
06🌐
Kubernetes Services
Stable Networking & Load Balancing
Pods get random IPs that change on restart. Services provide stable endpoints that abstract away pod IPs — enabling reliable communication and automatic load balancing across replicas.
Service Types
Type
Scope
Use Case
ClusterIP
Internal only
Default. Inter-service communication within cluster.
NodePort
External via node
Opens port 30000-32767 on all nodes. Development use.
LoadBalancer
External via cloud LB
Provisions cloud load balancer. Production external access.
port is what clients connect to (catalog-service:80). targetPort is the container port (8080). The selector matches pod labels to know which pods to route to.
$ kubectl get endpoints catalog-servicePod IPs backing the service
$ kubectl port-forward svc/catalog-service 8080:80Local access for debugging
⚠️ Important
NodePort opens ports on every node — security concern in production. Use LoadBalancer or Ingress instead.
07🚪
Kubernetes Ingress
HTTP Routing & TLS
Each LoadBalancer service creates a separate cloud load balancer with its own cost. Ingress consolidates multiple services behind one load balancer with URL-based routing and TLS termination.
Why Ingress?
💰
Cost Efficient
One load balancer for all services instead of one per service.
🔀
Path Routing
Route /api to backend, / to frontend.
🏠
Host Routing
Route shop.example.com to shop, api.example.com to API.
Use cert-manager to automatically provision and renew TLS certificates from Let's Encrypt.
08📁
Kubernetes Namespaces
Cluster Organization & Isolation
Namespaces are virtual clusters within a physical cluster. They organize resources, isolate teams, enable resource quotas, and allow the same resource names in different namespaces.
Default Namespaces
Namespace
Purpose
default
Resources created without specifying namespace
kube-system
Kubernetes system components (API server, scheduler, etc.)
NAMESPACE.YAMLapiVersion: v1
kind: Namespace
metadata:
name: production
labels:
env: prod
Cross-Namespace Communication
DNS# Full DNS name for services:
<service-name>.<namespace>.svc.cluster.local
# Examples:
catalog-service.production.svc.cluster.local
payment-api.payments.svc.cluster.local
# Short form (within same cluster):
catalog-service.production
⚠️ Important
Deleting a namespace deletes ALL resources in it. Be extremely careful with kubectl delete namespace in production!
09💾
Kubernetes Volumes
Persistent Storage
Container filesystems are ephemeral — data is lost when pods restart. Volumes provide persistent storage that survives pod restarts and can be shared between containers.
POD-PVC.YAMLapiVersion: v1
kind: Pod
metadata:
name: postgres
spec:
containers:
- name: postgres
image: postgres:15
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
volumes:
- name: data
persistentVolumeClaim:
claimName: postgres-data
Access Modes
Mode
Description
ReadWriteOnce (RWO)
Single node read-write
ReadOnlyMany (ROX)
Many nodes read-only
ReadWriteMany (RWX)
Many nodes read-write
⚡ Pro Tip
Use StorageClass with volumeBindingMode: WaitForFirstConsumer to create PVs in the same zone as the pod that needs them.
10🗄️
StatefulSets
Stateful Application Management
Deployments are for stateless apps where pods are interchangeable. StatefulSets are for stateful apps (databases) that need stable network IDs, ordered deployment, and persistent storage per pod.
Headless service (clusterIP: None) creates DNS entries for each pod: postgres-0.postgres-headless.default.svc.cluster.local
11🔧
ConfigMaps & Secrets
Configuration Management
ConfigMaps store non-sensitive configuration data. Secrets store sensitive data like passwords and API keys. Both decouple configuration from container images, enabling the same image across environments.
$ echo -n "mypassword" | base64Encode value for Secret
$ kubectl create secret generic db-creds --from-literal=password=mypasswordCreate Secret from literal
$ kubectl create configmap app-cfg --from-file=config.yamlCreate ConfigMap from file
⚠️ Important
Secrets are base64 encoded, not encrypted! Anyone with cluster access can decode them. Use external secret managers (Vault, AWS Secrets Manager) for production.
12🩺
Health Probes
Liveness, Readiness & Startup
By default, Kubernetes only checks if the main process is running. Probes let you define custom health checks — detect deadlocks, verify dependencies, and handle slow startups.
Three Probe Types
💓
Liveness
Is container alive? Failure → restart. Detect deadlocks.
✅
Readiness
Ready for traffic? Failure → remove from service. Warmup checks.
🚀
Startup
Has startup completed? Disables other probes until success.
Liveness probes should NEVER check external dependencies. A database outage shouldn't restart your app — it should stop receiving traffic (readiness).
13📊
Resource Management
Requests, Limits & QoS
Without resource specs, pods can consume unlimited CPU/memory, starving other workloads. Requests guarantee minimum resources for scheduling. Limits cap maximum usage.
Requests vs Limits
Requests
Limits
Purpose
Minimum guaranteed
Maximum allowed
Scheduling
Used by scheduler
Not considered
CPU Exceeded
N/A
Throttled
Memory Exceeded
N/A
OOMKilled
Resource Specification
RESOURCES.YAMLresources:
requests:
memory: "256Mi"
cpu: "250m" # 0.25 CPU cores
limits:
memory: "512Mi"
cpu: "500m" # 0.5 CPU cores
Start with requests = typical usage, limits = 2-3x requests. Monitor actual usage with kubectl top and adjust based on real data.
14📍
Advanced Scheduling
Affinity, Taints & Tolerations
By default, the scheduler places pods optimally. For specific requirements — SSD nodes, co-location, dedicated node pools — use node selectors, affinity rules, and taints/tolerations.
Use pod anti-affinity with topologyKey: kubernetes.io/hostname to spread replicas across nodes for high availability.
15🔐
RBAC Security
Role-Based Access Control
By default, anyone with cluster access can do anything. RBAC defines who (subjects) can perform what actions (verbs) on which resources. Essential for multi-tenant clusters and compliance.
RBAC Components
👤
Subjects
Who: Users, Groups, ServiceAccounts
📋
Roles
What: Permissions (verbs + resources)
🔗
Bindings
Connect subjects to roles
Role vs ClusterRole
Type
Scope
Role + RoleBinding
Single namespace
ClusterRole + ClusterRoleBinding
Entire cluster
Role Example
ROLE.YAMLapiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: development
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
RoleBinding
ROLEBINDING.YAMLapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-pod-reader
namespace: development
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
name: monitoring
namespace: monitoring
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Testing Permissions
$ kubectl auth can-i create podsCheck current user permission
$ kubectl auth can-i delete pods --as=aliceCheck as another user
$ kubectl auth can-i --listList all permissions
✓Follow least privilege — grant minimum permissions needed