Kubernetes (K8s) orchestrates containers at scale. It handles deployment, scaling, networking, and self-healing for your containerized applications. This guide covers the essentials and links to deeper resources — whether you’re deploying your first pod or debugging a production cluster.

Do you actually need Kubernetes?

Before diving in: Kubernetes is complex. If you’re running a single app with moderate traffic, you probably don’t need it. A simple VPS with Docker Compose, or a platform like Vercel/Railway, is simpler and cheaper.

Kubernetes makes sense when you have:

• Multiple services that need to communicate
• Traffic that varies significantly (auto-scaling)
• Requirements for zero-downtime deployments
• A team that needs standardized deployment workflows

For a comparison of simpler alternatives, read Docker vs Kubernetes and Docker Compose vs Kubernetes. If you’re not sure about containers at all, start with What is Kubernetes?.

Core concepts

Everything in Kubernetes is a resource defined in YAML. The key resources:

Pods — the smallest deployable unit. A pod runs one or more containers. You rarely create pods directly — you use Deployments.

Deployments — manage a set of identical pods. You tell Kubernetes “I want 3 replicas of my app” and it makes it happen. If a pod crashes, the Deployment creates a new one.

Services — networking. A Service gives your pods a stable IP address and DNS name. Without a Service, pods can’t be reached reliably because their IPs change when they restart.

ConfigMaps and Secrets — configuration. Store environment variables and sensitive data separately from your container images.

For the full command reference, bookmark the Kubernetes kubectl cheat sheet.

Getting started with kubectl

kubectl is the CLI for interacting with Kubernetes clusters. The commands you’ll use daily:

# See what's running
kubectl get pods
kubectl get deployments
kubectl get services

# Get details about a specific resource
kubectl describe pod my-pod

# View logs
kubectl logs my-pod
kubectl logs my-pod -f  # follow/stream

# Execute a command in a running pod
kubectl exec -it my-pod -- /bin/sh

Deploying an application

A minimal deployment:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: myregistry.com/my-app:v1.0.0
          ports:
            - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

Apply it:

kubectl apply -f deployment.yaml

Helm — package management for Kubernetes

Helm is like npm for Kubernetes. Instead of writing raw YAML for every service, you use charts (templates with configurable values):

# Install a chart
helm install my-release bitnami/postgresql

# Customize with values
helm install my-db bitnami/postgresql --set auth.postgresPassword=secret

See the Helm cheat sheet for the full command reference.

Troubleshooting

When things go wrong in Kubernetes, the debugging flow is:

1. kubectl get pods — check the status
2. kubectl describe pod <name> — check events for errors
3. kubectl logs <name> — check application logs

The most common errors:

• ImagePullBackOff — Kubernetes can’t pull your container image. Wrong image name, missing registry credentials, or the image doesn’t exist.
• CrashLoopBackOff — your container starts and immediately crashes, over and over. Check the logs — it’s usually a missing environment variable, wrong command, or the app crashing on startup.
• Connection refused — can’t connect to the Kubernetes API server. Check your kubeconfig and cluster status.

Kubernetes and Docker

Kubernetes runs containers, and those containers are usually built with Docker. The workflow:

1. Write a Dockerfile (use our Dockerfile generator)
2. Build and push the image to a registry
3. Reference the image in your Kubernetes Deployment YAML
4. kubectl apply

For Docker fundamentals, see the Docker complete guide and Docker cheat sheet.

Managed Kubernetes vs self-hosted

Running your own Kubernetes cluster is a full-time job. Most teams use managed services:

• EKS (AWS) — most popular, integrates with AWS services
• GKE (Google Cloud) — best developer experience, Kubernetes was born at Google
• AKS (Azure) — good if you’re already on Azure

The managed service handles the control plane (API server, etcd, scheduler). You manage the workloads.

What to read next

If you’re just starting: read What is Kubernetes? and Docker vs Kubernetes to understand when you need K8s.

If you’re working with a cluster: bookmark the kubectl cheat sheet and Helm cheat sheet.

If you’re debugging: check the troubleshooting section above — ImagePullBackOff, CrashLoopBackOff, and Connection refused cover the most common issues.