Kubernetes Fundamentals Explained Simply

1. Introduction

Kubernetes documentation is thorough, detailed, and difficult to read if you don't already know what you're looking for. This guide takes a different approach: explain each core concept in terms of the problem it solves, show what it looks like in practice, and point you toward the failure patterns you'll encounter most often. By the end you'll have a working mental model of how Kubernetes fits together — which makes both operating it and debugging it significantly easier.

2. What Kubernetes Is Used For

Kubernetes is a container orchestration platform. That means: you tell it what containers you want to run, how many copies, where they should be placed, how they should communicate, and what should happen if they crash — and it makes it so. Without Kubernetes, you'd manage all of that manually across a fleet of servers.

In practice, teams use Kubernetes to: deploy applications reliably using rolling updates, scale workloads up and down automatically based on load, route traffic to healthy pods, manage configuration and secrets, provision storage for stateful applications, and enforce resource limits so one workload can't starve another. The full Kubernetes guide hub covers the operational side in depth.

3. Pods

A pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share a network namespace and can share storage volumes. In practice, most pods contain one container — the multi-container pattern is used for sidecars (a logging agent or service mesh proxy running alongside the main application).

Pods are ephemeral. They can be scheduled to any node, restarted, moved, or evicted at any time. You should never SSH into a pod and make changes that aren't in your code or configuration — the pod will be replaced and those changes will be lost. Everything that needs to persist must go into a volume, a ConfigMap, a Secret, or the container image itself.

# Check pod status
kubectl get pods -n <namespace>

# See why a pod is failing
kubectl describe pod <pod-name> -n <namespace>

# Read container logs
kubectl logs <pod-name> -n <namespace>

# Get a shell inside a running pod
kubectl exec -it <pod-name> -n <namespace> -- sh

4. Deployments

A Deployment manages a set of identical pods. You define what you want (image, replicas, resource limits, environment variables) and the Deployment controller makes it happen. It also handles rolling updates: when you change the image tag, it gradually replaces old pods with new ones while keeping the application available.

Deployments create ReplicaSets, which create pods. You don't usually interact with ReplicaSets directly — they're managed by the Deployment controller. The things you configure in a Deployment that matter most in production: the container image, resource requests and limits, environment variables, liveness and readiness probes, and the rolling update strategy.

# Apply a Deployment manifest
kubectl apply -f deployment.yaml

# Check rollout status
kubectl rollout status deployment/<name> -n <namespace>

# Rollback if the new version is broken
kubectl rollout undo deployment/<name> -n <namespace>

# Scale manually
kubectl scale deployment/<name> --replicas=5 -n <namespace>

5. Services

A Service gives a stable DNS name and IP address to a set of pods. Without a Service, you'd need to know the pod's IP address to reach it — which changes every time the pod is replaced. Services use label selectors to route traffic to all pods that match a given set of labels.

There are three main Service types: ClusterIP (only reachable inside the cluster), NodePort (exposes the service on every node's IP at a specific port), and LoadBalancer (provisions a cloud load balancer and gives you an external IP). In most Kubernetes setups, you use ClusterIP for internal communication and expose traffic externally through an Ingress instead of LoadBalancer Services.

# View services and their endpoints
kubectl get service -n <namespace>
kubectl get endpoints <service-name> -n <namespace>

# If endpoints are <none>, the selector doesn't match any running pods
kubectl get pods -n <namespace> --show-labels

6. Ingress

Ingress routes external HTTP/HTTPS traffic into the cluster. An Ingress resource defines rules: "requests for app.example.com/api go to the api-service, requests for app.example.com go to the frontend-service." An Ingress Controller (NGINX, Traefik, or the AWS Load Balancer Controller) reads these rules and configures the actual proxy or load balancer.

Common Ingress issues: the controller isn't installed, the ingressClassName doesn't match, the TLS secret doesn't exist, or the backend Service has no ready pods. The full diagnostic guide is at Fix Kubernetes Ingress Not Working.

# Check Ingress resources
kubectl get ingress -n <namespace>

# If ADDRESS is empty, the controller hasn't provisioned the load balancer
kubectl describe ingress <name> -n <namespace>
# Read the Events section for controller errors

7. ConfigMaps and Secrets

ConfigMaps store non-sensitive configuration data (URLs, feature flags, config files). Secrets store sensitive data (passwords, API keys, TLS certificates). Both are injected into pods as environment variables or mounted as files. The key difference: Secrets are base64-encoded (not encrypted by default in most clusters) and have restricted access in RBAC.

# Check ConfigMaps and Secrets in a namespace
kubectl get configmap -n <namespace>
kubectl get secret -n <namespace>

# A missing ConfigMap or Secret causes ContainerCreating to hang
# Check pod events if a pod won't start:
kubectl describe pod <pod-name> -n <namespace>

8. Volumes and Storage

Pods are stateless by default — any data written to the container filesystem is lost when the pod is replaced. For persistent storage, you use PersistentVolumes (PV) and PersistentVolumeClaims (PVC). A PVC is a request for storage: "I need 10 GiB of read-write-once storage." A StorageClass tells Kubernetes how to fulfil that request (e.g. provision an AWS EBS volume).

The most common storage issue is a PVC that stays in Pending state — usually because the StorageClass doesn't exist, the provisioner isn't running, or there's an availability zone mismatch. The full diagnostic guide is at Fix Kubernetes PVC Pending.

# Check PVC status
kubectl get pvc -n <namespace>
# Bound = ready to use, Pending = still provisioning or blocked

# Describe a pending PVC to see why
kubectl describe pvc <pvc-name> -n <namespace>

9. Common Failure Patterns

Most Kubernetes problems fall into a small number of categories. Learning to recognise them quickly is more valuable than memorising every kubectl flag:

• ImagePullBackOff — the container image can't be pulled. Check registry credentials, image tag, and network connectivity.
• CrashLoopBackOff — the container starts and immediately exits. Check pod logs for the error, check environment variables and config.
• OOMKilled — the container exceeded its memory limit. Increase the limit or fix a memory leak.
• Pending pods — the pod can't be scheduled. Check node capacity, taints, and PVC status.
• Service not reachable — check that the Service's label selector matches the pod labels and that there are endpoints.

10. Where to Go Next

Once you have the fundamentals in place, the most effective way to deepen your Kubernetes knowledge is to operate a real cluster and work through failures. The Kubernetes troubleshooting hub on DevOps Compass covers the specific failure modes you'll encounter in production — each article walks through the exact diagnostic commands and fixes.