Step 1 • Before You Start
Prerequisites — Docker, Containers, and Linux beginner Kubernetes orchestrates containers — you must understand Docker first. Know how to: build images (Dockerfile, multi-stage builds), run containers (docker run, volumes, port mapping, environment variables), use Docker Compose for local development, understand image layers and the registry (Docker Hub, ECR, GCR), and have basic Linux fluency (processes, file permissions, environment variables, systemctl). Without Docker fundamentals, Kubernetes concepts won't make sense.
8h Step 2 • Core Concepts
Kubernetes Architecture and Concepts beginner Understand what Kubernetes is — a container orchestration platform. Learn the control plane: kube-apiserver (the REST API gateway — everything talks to it), etcd (the distributed key-value store — the source of truth), kube-scheduler (assigns Pods to Nodes), kube-controller-manager (runs controllers — ReplicaSet, Deployment, etc.). Worker Nodes run kubelet (agent, talks to apiserver), kube-proxy (iptables/IPVS rules for Services), and a container runtime (containerd, CRI-O). Understand the reconciliation loop — desired state vs actual state.
5h Step 3 • Core Concepts
kubectl — The Kubernetes CLI beginner kubectl is your primary interface to Kubernetes. Learn the imperative vs declarative styles, essential commands (get, describe, logs, exec, apply, delete, port-forward, cp), resource shortnames (po, svc, deploy, ns, cm, secret), output formats (-o yaml, -o json, -o wide, -o jsonpath), label selectors (-l app=frontend), and namespace scoping (-n mynamespace, --all-namespaces). Set up shell autocompletion and kubeconfig contexts (kubectl config use-context, kubectx for multi-cluster).
4h Step 4 • Workloads
Pods — The Atomic Unit beginner A Pod is the smallest deployable unit — one or more tightly coupled containers sharing a network namespace (localhost) and storage volumes. Learn Pod spec (containers, image, command, args, env, ports, resources), init containers (run and complete before app containers start), sidecar containers (co-located helpers like log shippers), Pod lifecycle phases (Pending, Running, Succeeded, Failed, Unknown), and restart policies. Understand why you rarely create Pods directly — use a controller instead.
5h Step 5 • Workloads
Deployments, ReplicaSets, and DaemonSets beginner Controllers manage Pod lifecycle. Deployment manages stateless apps — rolling updates (maxUnavailable, maxSurge), rollback (kubectl rollout undo), pause/resume, and history. ReplicaSet ensures N replicas are running (normally managed by Deployment, rarely created directly). DaemonSet runs one Pod per Node (great for log shippers, node exporters, CNI plugins). Job runs a task to completion. CronJob runs Jobs on a schedule. Learn how label selectors (spec.selector.matchLabels) connect controllers to Pods.
6h Step 6 • Networking
Services and Networking intermediate Services provide stable DNS names and load balancing to a set of Pods (selected by labels). Service types: ClusterIP (internal-only, default), NodePort (exposes on each node's IP), LoadBalancer (provisions a cloud LB — use for production), ExternalName (DNS alias). kube-proxy programs iptables/IPVS rules. Pod-to-Pod communication uses the flat cluster network (CNI plugins — Calico, Flannel, Cilium). CoreDNS resolves service names (my-svc.my-namespace.svc.cluster.local). NetworkPolicies restrict pod-to-pod traffic.
7h Step 7 • Networking
Ingress and Ingress Controllers intermediate Ingress is an API object that manages external HTTP/HTTPS access to services — host-based and path-based routing, TLS termination. It requires an Ingress Controller to implement the rules — NGINX Ingress Controller (most common), Traefik, HAProxy, or cloud-native (AWS ALB Controller, GKE's built-in). Use cert-manager with Let's Encrypt for automatic TLS certificate provisioning and renewal. Understand the difference between Ingress and Gateway API (the newer, more powerful replacement).
5h Step 8 • Configuration
ConfigMaps and Secrets intermediate Decouple configuration from container images. ConfigMaps store non-sensitive key-value data — inject as environment variables or mount as files. Secrets store sensitive data (base64-encoded, not encrypted by default) — inject as envFrom or volume mounts, never bake into images. Enable Secrets encryption at rest in etcd with EncryptionConfiguration. Use external-secrets-operator with AWS Secrets Manager, GCP Secret Manager, or HashiCorp Vault for production — never commit Secrets to Git.
5h Step 9 • Storage
Volumes, PVs, PVCs, and StorageClasses intermediate Kubernetes storage has multiple layers. emptyDir (ephemeral, dies with pod), hostPath (node-local, not portable), and persistent storage. PersistentVolume (PV) — cluster-level storage resource. PersistentVolumeClaim (PVC) — a request for storage (size, access mode: ReadWriteOnce, ReadWriteMany, ReadOnlyMany). StorageClass — dynamic provisioning template (AWS EBS, GCE PD, Azure Disk, NFS). Understand volume binding modes, reclaim policies (Retain, Delete), and why StatefulSets pair with volumeClaimTemplates.
6h Step 10 • Security
Namespaces, RBAC, and Service Accounts intermediate Namespaces partition a cluster into virtual clusters — separate teams, environments, or applications. Resource quotas (ResourceQuota) and limit ranges (LimitRange) per namespace. RBAC: Role (namespaced permissions) and ClusterRole (cluster-wide), bound to subjects via RoleBinding and ClusterRoleBinding. Subjects: Users, Groups, or ServiceAccounts. ServiceAccounts are identities for Pods — auto-mounted token gives access to the API. Follow least-privilege: don't use the default ServiceAccount with broad permissions.
6h Step 11 • Operations
Resource Requests, Limits, and QoS intermediate Every container should declare resource requests (what the scheduler uses to find a fit) and limits (the hard ceiling). CPU requests/limits in millicores (100m = 0.1 core), memory in bytes (256Mi). QoS classes: Guaranteed (requests == limits — least likely to be evicted), Burstable (requests < limits), BestEffort (no requests/limits — first evicted). LimitRange sets defaults per namespace. VPA (Vertical Pod Autoscaler) can recommend or auto-adjust requests. Right-sizing is critical — too low causes OOMKills, too high wastes money.
5h Step 12 • Operations
Liveness, Readiness, and Startup Probes intermediate Kubernetes uses three probe types: livenessProbe (is the app alive? — restart if failing), readinessProbe (is the app ready for traffic? — remove from Service endpoints if failing), startupProbe (gives slow-starting apps more time — disables liveness/readiness until it passes). Probe mechanisms: httpGet, tcpSocket, exec, grpc. Configure initialDelaySeconds, periodSeconds, failureThreshold, successThreshold, timeoutSeconds. Bad probe configuration is one of the top causes of production incidents — too aggressive causes flapping, too lenient misses real failures.
4h Step 13 • intermediate
Scheduling — Taints, Tolerations & Affinity intermediate Control pod placement with node selectors and node affinity (requiredDuringScheduling / preferredDuringScheduling). Use taints and tolerations to repel pods from specialized nodes (GPU, spot instances). Apply pod affinity and anti-affinity for co-location and spreading. Define PriorityClasses to ensure critical workloads get resources during contention.
5h Step 14 • Scaling
HPA, VPA, and Cluster Autoscaling intermediate HPA (Horizontal Pod Autoscaler) scales the number of Pod replicas based on metrics — CPU utilization, memory (v2 API), or custom metrics (Prometheus via KEDA). Configure minReplicas, maxReplicas, and target utilization. KEDA (Kubernetes Event-Driven Autoscaling) scales on any event source (queue depth, Kafka lag, cron). VPA (Vertical Pod Autoscaler) adjusts resource requests. Cluster Autoscaler adds/removes Nodes when pods are unschedulable. Karpenter (AWS) is a faster, more flexible Node provisioner.
6h Step 15 • advanced
Deployment Strategies — Canary, Blue-Green & Rolling advanced Implement rolling updates (maxSurge, maxUnavailable), blue-green deployments (two identical environments with traffic switch via Service selector), and canary releases (gradual traffic shifting). Use kubectl rollout undo for rollbacks. Explore progressive delivery tools: Argo Rollouts and Flagger for automated canary analysis using Prometheus metrics.
6h Step 16 • Packaging
Helm — Package Manager for Kubernetes intermediate Helm packages Kubernetes manifests into reusable charts. Learn chart structure (Chart.yaml, values.yaml, templates/), templating with Go templates ({{ .Values.image.tag }}, helpers in _helpers.tpl), helm install/upgrade/rollback/uninstall, overriding values with --set or -f values-prod.yaml, hooks (pre-install, post-upgrade), and chart dependencies. Use Artifact Hub to find community charts. Understand when to use Helm vs Kustomize — Helm for parameterized packages, Kustomize for overlay-based configuration.
7h Step 17 • Observability
Observability — Metrics, Logs, and Tracing advanced Three pillars of observability in Kubernetes. Metrics: Prometheus (pulls /metrics endpoints), Grafana (dashboards), kube-state-metrics (Deployment/Pod state as metrics), node_exporter (node-level metrics), Prometheus Operator simplifies setup. Logs: structured JSON logs, aggregated with Loki + Promtail (lightweight) or Elasticsearch + Fluentd/Fluent Bit. Tracing: OpenTelemetry SDK in your app, Jaeger or Tempo as the backend. Use the Prometheus community kube-prometheus-stack Helm chart to install everything.
8h Step 18 • GitOps
GitOps with ArgoCD or Flux advanced GitOps uses Git as the single source of truth for cluster state — a controller continuously reconciles the cluster to match what's in the repo. ArgoCD is a Kubernetes-native CD tool — define Applications pointing to a Git repo/Helm chart/Kustomize overlay, get a visual UI showing sync status. Flux CD is a lighter, CLI-focused GitOps operator. Learn the GitOps principles (declarative, versioned, automated, continuously reconciled), image update automation, and multi-cluster management patterns.
7h Step 19 • Security
Security — Policies, Scanning, and Hardening advanced Kubernetes security is multi-layered. Pod Security Standards (PSS) — Privileged, Baseline, Restricted — replace PodSecurityPolicy. Network Policies restrict pod-to-pod traffic at the CNI layer (Calico or Cilium). securityContext settings: runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation: false, capabilities.drop: [ALL]. Scan images with Trivy. Audit logs reveal API server access. Falco detects runtime threats. OPA/Gatekeeper enforces custom admission policies. Principle of least privilege everywhere.
8h Step 20 • Production
Managed Kubernetes — EKS, GKE, and AKS advanced Running Kubernetes in production means using a managed service — EKS (AWS), GKE (Google Cloud), AKS (Azure). Learn how to provision clusters with Terraform or eksctl, configure node groups and managed node pools, integrate cloud IAM with Kubernetes RBAC (IAM Roles for Service Accounts on EKS, Workload Identity on GKE), set up cluster upgrades with zero downtime (node drain, PodDisruptionBudgets), use spot/preemptible instances for cost savings, and implement disaster recovery with Velero backups.
10h 