Kubernetes Basics Course

Kubernetes Looks Simple Until Your Pod Won't Schedule

The Kubernetes quickstart is a trap. A friendly `kubectl run` and a `kubectl port-forward` make the platform feel like a friendlier way to run Docker — until a pod sits in `Pending` for an hour, your Service has no endpoints, or a deployment rolls back silently because of an image pull error. The gap between "I can run a demo pod" and "I can run a real workload" is where most beginners stall. This course-style guide builds the operating model you actually need: what the control plane and nodes do, how Pods, Deployments, Services, and Ingress fit together, and why every YAML field you skip is a decision you're making by accident.

The Control Plane and Nodes: Who Does What in a Cluster

A Kubernetes cluster is split into a control plane and worker nodes, and the split explains most of what looks like magic. The control plane runs the API server (the only entry point for all commands), the scheduler (decides which node runs each Pod), the controller manager (reconciles desired state with reality), and etcd (the cluster's source-of-truth database). Worker nodes run a kubelet (the agent that talks to the control plane on the node), a container runtime, and kube-proxy for networking. Understanding this split tells you where problems live: an API-server outage blocks everything, a kubelet problem takes down only that node's workloads.

This also explains the single most common beginner confusion: a Pod stuck in `Pending` usually isn't an application bug. It means the scheduler couldn't place it — because the node lacks the required resources, a taint is blocking it, or no matching node exists. When you see `Pending`, you're debugging the scheduler and node taints/labels, not your app. Similarly, a CrashLoopBackOff is your app failing at runtime, and an ImagePullBackOff is a bad image name, tag, or registry credentials. Naming the failing layer — scheduler vs. runtime vs. image — is the first step in every repair.

Pods, Deployments, and the Stateless Workload Model

A Pod is the smallest schedulable unit: one or more containers that share a network namespace and storage. In practice most Pods run a single container, and you almost never create Pods directly — you create a Deployment (or other workload controller) that manages a ReplicaSet of Pods for you. The Deployment gives you declarative control: specify the desired number of replicas and the container image, and the controller establishes a reconciliation loop that keeps reality matching your declared state. Edit the spec and Kubernetes rolls to the new version; kill a Pod and it reschedules a replacement.

The stateless model is the key mental shift. Deployment-managed Pods can be replaced at any time, their IP addresses are ephemeral, and their filesystem is disposable. That's why state (database files, uploads, caches) must live outside the Pod in persistent volumes, and why Deployments are for stateless services. When you need uniquely-identified, stable stateful components (a database leader, a consensus participant), you reach for a StatefulSet instead — a separate controller that's harder to use but keeps stable identities and ordering. Getting the Deployment/StatefulSet decision right up front prevents painful migrations later.

Services and Ingress: Turning Ephemeral Pods Into a Reachable App

Because Pod IPs are ephemeral, you can't connect to a Pod by IP reliably. A Service is a stable abstraction that sits in front of a set of Pods (selected by label), giving them a stable cluster-internal DNS name and load-balancing traffic among the backing Pods. When a Service reports zero endpoints, it's usually a label mismatch — your Service `selector` doesn't match the labels on your Pods. That's the number-one "why won't my app connect?" cause in early clusters, and it's a pure YAML typo, not deep magic.

Exposing a Service to the world goes through Ingress (or a service of type LoadBalancer on a cloud provider). Ingress rules map hostnames and paths to Services, and behind them sits an ingress controller (e.g., NGINX Ingress, Traefik, or a cloud load balancer). A Service of type `ClusterIP` is internal-only; `NodePort` exposes a high port on each node; `LoadBalancer` provisions an external one. The hierarchy to internalize: Service selects Pods by label, Ingress routes external traffic to Services, and health readiness gates which Pods a Service sends traffic to.

ConfigMaps, Secrets, and the Right Way to Pass Configuration

Hardcoding config in container images is how versioning and secrets leak, and Kubernetes gives you two mechanisms to avoid it. A ConfigMap holds non-confidential configuration as key-value pairs that you mount as files or expose as environment variables. A Secret does the same for sensitive material (credentials, API keys, tokens) — and it's the correct home for anything you'd never commit to the image. Both are Decoupled from your container image, so you can redeploy the same image into different environments by swapping the config, which is exactly the pattern that supports a promotion workflow from dev to staging to production.

The security nuance matters. A Secret in Kubernetes is base64-encoded, not encrypted at rest by default — it's obfuscation, not protection, unless you enable encryption-at-rest for etcd and control who can read and edit Secrets via RBAC. Treat Secrets with the same care as production credentials anywhere else: rotate them, scope access tightly, and prefer external secret stores (via a SealedSecret or an external-secrets operator) when you need stronger guarantees. The mechanics of keeping secrets safe in a running cluster are covered in depth in the Kubernetes security basics guide; the key habit to build now is that Secrets live outside your images and your Pod specs.

Storage: Persistent Volumes and Why State Is Tricky

When your app needs files that survive a Pod restart, you need persistent storage. A PersistentVolume (PV) is cluster storage provisioned by an admin or dynamically by a StorageClass; a PersistentVolumeClaim (PVC) is an app's request for storage that binds to a PV. Pods then mount the PVC. In a managed cluster (EKS, AKS, GKE), a default StorageClass provisions cloud disks automatically when you create a PVC — which is convenient, but it means every PVC costs you real money and has a default size and performance tier you should set deliberately.

Revisit your Kubernetes mental model by contrasting it with the simpler single-host path you may have come from. A whole class of "why is this so complicated" frustration dissolves once you see Kubernetes as the orchestration layer on top of container fundamentals — which is exactly why mastering the single-host container flow first pays off. The Docker Compose guide shows what a multi-service stack looks like without a scheduler, and the 2026 Docker beginners guide grounds you in images, containers, and networking before you marry them to a control plane. The stateless model, health checks, and rolling updates you practice in Compose translate almost one-to-one, so the Kubernetes learning curve shrinks dramatically if your container instincts are already sharp.

Namespaces, Resource Limits, and Sharing a Cluster Safely

A cluster of one team soon becomes a cluster of many workloads, and namespaces are the first tool for separating them. Namespaces partition cluster resources, scope names, and give you an isolation boundary for RBAC and network policy. Separate environments (dev, staging, prod) into different namespaces, and don't let every workload share `default` — that's how a stray duplicate name or an errant `kubectl delete` wipes something important.

Equally important is resource management. Set `requests` and `limits` on every container: requests tell the scheduler how much CPU/memory to reserve, limits cap how much a rogue container can consume. Without them, one memory-hungry pod can stall the entire node and, worse, get OOM-killed mid-request without warning. Every field you leave unset is a default you didn't consciously choose, and in a shared cluster the request/limit defaults are the fields that most often cause outages. Add them to every workload, and monitor actual usage against requests so you don't over-reserve and waste money or under-reserve and cause evictions.

Comparing Managed Kubernetes Offerings and the DIY Path

For learning, Minikube or kind on your laptop is the fastest path to hands-on reps. For real workloads, a managed offering (EKS/GKE/AKS) removes the heavy control-plane operations burden; only choose self-managed if you have the ops team and the reason. Price roughly tracks node and resource usage, with control-plane fees as the main divergence.

Rollouts, Health Checks, and Running a Deployment Without Fear

A Deployment's real power is safe change: rolling updates that replace old Pods with new ones gradually, and automatic rollback when the new version fails its readiness check. To benefit, your image tags must actually change (a `latest` tag reused for every deploy defeats this, because the controller sees no spec change), and your Pod must have a readiness probe that reflects true app readiness, not just container start. Set `readinessProbe` and `livenessProbe` on every workload: readiness gates traffic, liveness restarts a hung container. Without them, Kubernetes assumes a container is ready the moment it's running, which means failed apps absorb traffic or idle silently.

Use `kubectl rollout status` and `kubectl rollout undo` to manage releases, and set `strategy` parameters (maxUnavailable, maxSurge) to control how aggressively the roll replaces Pods. Pin images by tag or digest, and know that a bad image (right tag, broken entrypoint) will still roll — which is why pre-deploy smoke tests and good probes beat hoping. The discipline of versioned images, health probes, and rollback awareness is what turns `kubectl apply` from a grenade into a controlled deployment.

Debugging a Cluster Without Panicking

When something breaks, work from the outside in with a standard ladder: `kubectl get events` for cluster-level signals, `kubectl get pods` for status (Pending, CrashLoopBackOff, ImagePullBackOff, Running with 0/1 ready), `kubectl describe pod` for the detailed reason, `kubectl logs` and `kubectl exec` for app-level insight, and `kubectl get endpoints` to confirm a Service's backs are healthy. Each rung pins the failure to a layer. A Service with no endpoints points at label mismatch; a CrashLoopBackOff at your app's startup; Pending at the scheduler and node capacity.

Build debugging habits before you need them under pressure. Keep a `kubectl get all -n ` alias, learn `kubectl logs -f` for streaming, and get comfortable with `kubectl exec -it` to poke around inside. Know that the practical journey from a first pod to a production-grade cluster — image workflow, health probes, resource limits, storage, and security — is a real curriculum, and the Kubernetes basics guide supplements this course with a hands-on lab sequence. Debugging under pressure is mostly about having a repeatable ladder and the vocabulary to say exactly which layer is failing, and both are learnable with deliberate practice on a local cluster first, where the stakes are zero.

From Demos to Real Workloads: What "Production-Ready" Actually Requires

Getting a pod to run is day one; getting a workload you'd trust with real traffic is a longer road. Production-readiness means every workload has resource requests and limits, readiness and liveness probes, versioned images, and an explicit rollback plan. It means replicas ≥ 2 for anything you depend on, a well-chosen StorageClass with the right access mode, namespaces that separate environments, and RBAC that limits who can create or modify workloads. It means monitoring (Prometheus/Grafana or a managed stack) and logging that reach what you defined, not what you assumed. The container-native operational patterns behind all of this — image hygiene, health checks, dependency wiring — are spelled out in the Docker DevOps guide, which reads naturally alongside this course.

It also means security as a default posture: Secrets scoped and rotated, minimal image privileges, network policies where it matters, and a plan for upgrades and patches — covered in the security basics companion. None of this is glamorous, and that's exactly the point. Kubernetes rewards the teams that respect its model — declarative state, ephemeral pods, storage as a first-class concern, and discipline in the fields that protect you. Master that operating model, and the platform stops being a source of mystery and becomes the boring, reliable foundation your deployments stand on.

Why is my Pod stuck in Pending and not doing anything?

Pending means the scheduler has not placed the Pod, almost always due to insufficient node resources, a taint on the node, or a node selector/label mismatch. Run `kubectl describe pod ` and read the Events section — it states the scheduling reason. Fix resource requests, remove or tolerate the taint, or correct the node affinity; it's a scheduling problem, not an app problem.

What's the difference between a readiness probe and a liveness probe, and do I need both?

Readiness gates whether a Pod receives traffic (stopping it from a Service when the app isn't ready); liveness restarts a container that's hung or deadlocked. Use both on anything that serves traffic. Readiness protects users from a booting or overloaded app; liveness recovers a wedged process. Skipping probes means Kubernetes assumes ready the moment the container starts — a common cause of failed traffic during slow startups.

Why does my Service show no endpoints even though Pods are running?

Almost always a label selector mismatch: the Service's `selector` labels don't match the labels on your Pods. Verify with `kubectl get pods --show-labels` and compare. Also confirm the Pods are `Running` and `Ready`; a Pod that's ready will appear in the Service's endpoints. This is the most common "my app can't connect" cause in a new cluster.

When should I use a StatefulSet instead of a Deployment?

Use a StatefulSet when your application needs stable, unique network identities, stable persistent storage per instance, and ordered deployment/scaling — the profile of databases, caches, and consensus systems. Use a Deployment for stateless services that can scale and be replaced freely. Choosing Deployment for stateful work causes data-loss and identity problems; choosing StatefulSet for stateless work adds needless complexity.