Kubernetes For Beginners

Kubernetes For Beginners

Every core Kubernetes concept you need to know before deploying your first app, explained in plain language with zero assumed experience.

Kubernetes has a reputation for being intimidating, mostly because it introduces a lot of new vocabulary at once — pods, deployments, services, namespaces. This guide breaks Kubernetes down into twelve simple chapters, each covering a group of related concepts. Every concept gets a short, plain-English explanation — enough to understand what it is and why it matters, without diving into advanced configuration. By the end, you’ll have a complete mental map of Kubernetes before writing your first YAML file.

1Container Orchestration & Kubernetes Fundamentals

The big idea behind Kubernetes, before touching any command.

What Is Container Orchestration?

Automatically managing where and how many copies of a containerized application run, restarting them if they crash, without a human manually starting each one.

What Is Kubernetes?

The most widely used tool for orchestrating containers across many machines, keeping applications running the way you’ve told it they should run.

Why Use Kubernetes?

It automatically restarts failed containers, spreads them across multiple machines for reliability, and can scale an application up or down based on demand.

Kubernetes vs Docker

Docker builds and runs individual containers on one machine; Kubernetes manages many containers across many machines, deciding where each one should run.

Kubernetes Distributions (Minikube, Kind, Managed K8s)

Minikube and Kind let you run a small Kubernetes cluster on your own laptop for learning; managed services (like GKE, EKS, AKS) run a production-grade cluster for you in the cloud.

Everyday Analogy

Think of Kubernetes like the manager of a large restaurant kitchen with many chefs (machines). You tell the manager, “I always want 5 chefs cooking pasta.” If one chef gets sick, the manager immediately finds a replacement, without you having to notice or step in. You describe the desired outcome, and Kubernetes keeps making it true.

2Kubernetes Architecture & Components

The pieces that work together to make a Kubernetes cluster function.

Cluster

A group of machines working together as one system, managed by Kubernetes as a single unit.

Control Plane

The “brain” of the cluster that makes all the decisions — what should run, where it should run, and whether everything is healthy.

Node (Worker Node)

An individual machine (physical or virtual) in the cluster where your actual application containers run.

kubelet

An agent running on every node that talks to the control plane and makes sure the containers it’s told to run are actually running.

kube-proxy

Handles network traffic routing on each node, making sure requests reach the right container even as containers move around.

etcd

The database where the control plane stores the entire state of the cluster — what should be running and the current status of everything.

API Server

The front door to the cluster — every command you run and every internal component talks to Kubernetes through this single entry point.

Scheduler

Decides which node a new container should run on, based on available resources and any rules you’ve set.

Controller Manager

Continuously watches the cluster’s actual state and takes action to match it to the desired state you’ve described.

3Pods

The smallest unit Kubernetes actually manages.

What Is a Pod?

The smallest deployable unit in Kubernetes — a wrapper around one or more containers that always run together on the same machine.

Single-Container vs Multi-Container Pods

Most pods contain just one container, but sometimes a small helper container is added alongside it to assist with logging or networking.

Pod Lifecycle

A pod moves through phases like Pending, Running, Succeeded, or Failed as Kubernetes creates, runs, and eventually removes it.

Pod IP Addresses

Each pod gets its own internal IP address, but that address changes if the pod is ever recreated — which is why pods are rarely accessed directly.

Ephemeral Nature of Pods

Pods are disposable by design — if one fails or is deleted, Kubernetes creates a brand new one rather than trying to fix the old one.

4Workload Resources

Higher-level objects that manage pods on your behalf.

Deployment

Describes how many copies of an application should run and handles creating, updating, and replacing pods automatically to match that description.

ReplicaSet

Makes sure a specific number of identical pods are always running; Deployments manage ReplicaSets automatically, so beginners rarely create these directly.

StatefulSet

Similar to a Deployment but used for applications (like databases) that need a stable identity and storage tied to each specific pod.

DaemonSet

Ensures exactly one copy of a pod runs on every node in the cluster, often used for monitoring or logging agents.

Job

Runs a pod until it completes a task successfully, then stops — used for one-off tasks rather than long-running applications.

CronJob

Runs a Job automatically on a repeating schedule, similar to a scheduled task on a regular computer.

5Services & Networking Basics

How traffic actually reaches your application’s pods.

What Is a Service?

A stable network address that automatically routes traffic to the right pods, even as those pods are replaced or moved around.

ClusterIP

The default Service type, giving your application an internal address reachable only from within the cluster.

NodePort

Opens a specific port on every node in the cluster, making the application reachable from outside using any node’s address.

LoadBalancer

Automatically provisions an external load balancer (usually from a cloud provider) to expose your application to the internet.

Ingress

Manages external HTTP/HTTPS access to multiple services using rules, similar to a smart front door that routes different web addresses to different applications.

DNS in Kubernetes

Every Service automatically gets a name that other pods can use to reach it, without needing to know its internal IP address.

6Configuration Management

Getting settings and sensitive values into your applications.

ConfigMaps

Store non-sensitive configuration data (like settings or URLs) separately from your application code, so the same image can be reused across environments.

Secrets

Similar to ConfigMaps but intended for sensitive values like passwords and API keys, stored with additional access restrictions.

Environment Variables in Pods

Values passed into a container when it starts, often pulled from ConfigMaps or Secrets rather than hardcoded.

Labels

Key-value tags attached to objects (like pods) that let you group, filter, and select resources — for example, all pods labeled app: frontend.

Annotations

Similar to labels but meant for descriptive, non-identifying information, like a build version or a contact email, not used for selecting resources.

7Storage Basics

Keeping data around even when pods are recreated.

Volumes

Storage attached to a pod that can persist data beyond a single container’s lifetime within that pod, though not necessarily beyond the pod itself.

Persistent Volumes (PV)

A piece of storage in the cluster provisioned ahead of time, existing independently of any specific pod’s lifecycle.

Persistent Volume Claims (PVC)

A request from an application for a specific amount of storage, which Kubernetes matches to an available Persistent Volume.

Storage Classes

Define different types of storage available in the cluster (like fast SSD vs. slower standard storage), letting PVCs request a specific tier.

8Scaling & Scheduling Basics

Adjusting how much of your application runs, and where.

Horizontal Pod Autoscaling

Automatically increases or decreases the number of running pods based on real-time metrics like CPU usage.

Manual Scaling

Directly telling Kubernetes to run a specific number of pod copies, without relying on automatic metric-based adjustments.

Node Selectors

A simple way to tell Kubernetes a pod should only run on nodes matching certain labels, like nodes with a GPU.

Resource Requests and Limits

Requests tell Kubernetes how much CPU/memory a pod needs to be scheduled; limits cap how much it’s allowed to use once running.

9kubectl Basics

The command-line tool you’ll use constantly as a beginner.

What Is kubectl?

The official command-line tool for talking to a Kubernetes cluster’s API server — nearly everything you do with Kubernetes goes through this tool.

kubectl get

Lists resources in the cluster, like pods, services, or deployments, along with their current status.

kubectl describe

Shows detailed information about a specific resource, including recent events, useful for troubleshooting.

kubectl apply

Creates or updates resources in the cluster based on a configuration file you’ve written.

kubectl delete

Removes a resource from the cluster, such as a pod or a service.

kubectl logs

Shows the output produced by a container running inside a pod, useful for debugging application issues.

kubectl exec

Runs a command inside an already-running container, often used to open an interactive shell session for investigation.

10Namespaces & Cluster Organization

Keeping a cluster organized as more people and applications use it.

What Is a Namespace?

A way to divide a single cluster into multiple virtual sections, useful for separating different teams, environments, or applications.

Default Namespace

Where resources are created automatically if you don’t specify a namespace — fine for learning, but production clusters usually use dedicated namespaces.

Resource Quotas

Limits on how much CPU, memory, or number of objects a single namespace is allowed to use, preventing one team from consuming all cluster resources.

RBAC (Role-Based Access Control) Basics

Controls exactly which users or applications are allowed to view or modify specific resources within the cluster.

11Health & Reliability Basics

How Kubernetes knows something is wrong, and fixes it automatically.

Liveness Probes

A periodic check Kubernetes runs to see if a container is still working correctly; if it fails repeatedly, Kubernetes restarts the container.

Readiness Probes

A check that tells Kubernetes whether a container is ready to receive traffic — a pod can be running but not yet ready, like during startup.

Self-Healing

Kubernetes automatically restarts failed containers and replaces failed pods, without any human needing to intervene.

Rolling Updates

Gradually replaces old pods with new ones during a deployment update, keeping the application available throughout the process.

12Getting Started & Best Practices

Turning these concepts into hands-on practice.

Installing kubectl

Downloading the kubectl command-line tool is the first practical step before you can interact with any Kubernetes cluster.

Setting Up a Local Cluster (Minikube/Kind)

Running a small, single-machine Kubernetes cluster on your own laptop is the easiest way to practice without needing a cloud account.

Deploying Your First App

A classic first exercise is deploying a simple web server image and exposing it with a Service to see it respond to requests.

Common Beginner Mistakes

Forgetting to expose a Service properly, not setting resource requests/limits, and treating pods as permanent instead of disposable are frequent early stumbling blocks.

Where to Go Next

Once these basics feel comfortable, natural next steps include Helm (package management for Kubernetes), custom resource definitions, and cluster security hardening.

Key Takeaways

  • A pod is the smallest unit Kubernetes manages, but you’ll almost always manage pods indirectly through a Deployment.
  • A Service gives your application a stable address, solving the problem of pods constantly being replaced and getting new IPs.
  • ConfigMaps and Secrets keep configuration and sensitive data separate from your application code.
  • Kubernetes is fundamentally about describing a desired state and letting the control plane continuously work to match reality to it.
  • kubectl is your primary tool for everything — getting, describing, applying, and deleting resources.
  • Start with a local cluster (Minikube or Kind) to practice safely before touching a real production cluster.