Kubernetes for Beginners: Pods, Deployments and Services Explained

Once you can package an application in a Docker container, a new question appears: how do you run dozens of containers across many servers, keep them healthy, update them without downtime, and scale them when traffic grows? Kubernetes (often written K8s) is the most widely used answer. This guide explains the core ideas in plain language and walks you through running your first application on a local cluster.

What Is Kubernetes?

Kubernetes is an open-source system that automates the deployment, scaling and management of containerised applications. You tell Kubernetes the desired state, for example “run three copies of this container”, and it keeps working until reality matches. If a container crashes, Kubernetes starts a new one. If a server fails, it moves the work to another server.

If containers are new to you, start with our Docker for Beginners guide.

Kubernetes Architecture in Simple Terms

A Kubernetes cluster is a group of machines split into two roles:

Control plane — the brain. It includes the API server (the front door for every command), the scheduler (decides where each Pod runs), the controller manager (keeps the actual state matching the desired state) and etcd (the database that stores cluster data).
Worker nodes — the machines that run your containers. Each node runs the kubelet (an agent that talks to the control plane) and a container runtime.

The Objects You Must Know

Pod — the smallest unit. It wraps one or more containers that share networking and storage. Pods are temporary, so you rarely create them directly.
Deployment — describes how many Pods you want and which image to run. It handles rolling updates and rollbacks.
Service — gives a group of Pods one stable address and load-balances traffic between them, even as Pods come and go.
Namespace — a way to separate teams or environments inside one cluster.
ConfigMap and Secret — hold configuration and sensitive values outside your container image.
Ingress — routes outside HTTP and HTTPS traffic to Services, often by domain name or path.

Set Up a Local Cluster

You do not need a cloud account to practise. Install Docker, then either minikube or kind, plus the kubectl command-line tool.

# Start a local single-node cluster with minikube minikube start # Check that kubectl can talk to it kubectl get nodes kubectl cluster-info

Deploy Your First Application

Create a file called nginx-deployment.yaml:

apiVersion: apps/v1 kind: Deployment metadata: name: web spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.27 ports: - containerPort: 80 resources: requests: cpu: "100m" memory: "64Mi" limits: memory: "128Mi" --- apiVersion: v1 kind: Service metadata: name: web spec: type: NodePort selector: app: web ports: - port: 80 targetPort: 80

The Deployment asks for three nginx Pods. The labels let the Service find them: any Pod labelled app: web receives traffic. Apply the file and look at what was created:

kubectl apply -f nginx-deployment.yaml kubectl get deployments kubectl get pods kubectl get services # Open the service in your browser (minikube) minikube service web

Everyday kubectl Commands

# See details and recent events for a Pod (first place to look when something fails) kubectl describe pod <pod-name> # Read container logs kubectl logs <pod-name> # Open a shell inside a running container kubectl exec -it <pod-name> -- sh # Scale up or down kubectl scale deployment web --replicas=5 # Update the image (rolling update with no downtime) kubectl set image deployment/web nginx=nginx:1.27.1 # Watch the rollout, and undo it if something goes wrong kubectl rollout status deployment/web kubectl rollout undo deployment/web # Remove everything you created from the file kubectl delete -f nginx-deployment.yaml

Try this to see self-healing

Delete one Pod with kubectl delete pod <pod-name> and run kubectl get pods straight away. Kubernetes notices that only two Pods are running and starts a replacement to get back to three.

Common Beginner Problems

ImagePullBackOff — Kubernetes cannot download the image. Check the image name and tag, and whether the registry needs credentials.
CrashLoopBackOff — the container starts and keeps crashing. Read kubectl logs and kubectl describe pod for the reason.
Pending Pods — the cluster does not have enough CPU or memory, or the Pod asks for something that is not available. The events section of describe explains why.
Service not reachable — the Service selector does not match the Pod labels. Compare them carefully, because one typo breaks the connection.

Kubernetes in the Cloud

Running your own control plane is hard work, so most teams use a managed service such as Amazon EKS, Google GKE or Azure AKS. The concepts in this guide are identical; the cloud provider simply operates the control plane for you. A common production path is: build an image in a CI pipeline, push it to a registry, and deploy it to the cluster using the same YAML, usually packaged with Helm.

What to Learn Next

ConfigMaps, Secrets and environment variables
Health checks (liveness and readiness probes)
Persistent volumes for data that must survive restarts
Ingress controllers and TLS certificates
Helm charts, and GitOps tools such as Argo CD

Automate the image build with our GitHub Actions tutorial, provision the cluster with Terraform, and see the whole journey in the DevOps roadmap for 2026.

Master Kubernetes with Hands-On Projects

Our DevOps program covers Kubernetes, Docker, Terraform, CI/CD and AWS with live mentoring.

Apply for the Program →