Kubernetes Tutorial: From Zero to Production

What is Kubernetes?

Kubernetes (often abbreviated as K8s) is an open-source container orchestration platform originally developed by Google. It automates the deployment, scaling, and management of containerized applications across a cluster of machines.

At its core, Kubernetes answers the question: “I have many containers — how do I run them reliably, at scale, across multiple machines?”

New to containers or Docker? Check out the Core Concepts reference guide first.

Key capabilities:

When Should You Use Kubernetes?

Kubernetes is a powerful tool, but it's not always the right one. Here's how it compares to other deployment strategies:

Summary Table

Prerequisites

Before starting, make sure you have:

Tutorial Chapters

The tutorial is organized into six chapters plus a core concepts reference guide. Work through them in order for the best learning experience.

🛠️ Chapter 01 — Setup: Your First Kubernetes Cluster

In this chapter, we'll install all the tools you need and spin up a local Kubernetes cluster using k3d. By the end, you'll have a running cluster and know how to inspect it with kubectl.

Prerequisites

Before we begin, make sure you have:

Install Docker

k3d runs Kubernetes nodes as Docker containers, so Docker is required.

Install kubectl

kubectl is the command-line tool for interacting with any Kubernetes cluster.

Install k3d

k3d is a lightweight wrapper that runs k3s (a minimal Kubernetes distribution) inside Docker containers. It makes creating local Kubernetes clusters incredibly fast and easy.

Create Your First Cluster

Now for the fun part — let's create a Kubernetes cluster! With k3d, this is a single command:

k3d cluster create mycluster

What's happening here? k3d pulls the k3s Docker image, starts a Docker container that acts as your Kubernetes server node (control plane), and automatically configures kubectl to connect to this new cluster by updating your ~/.kube/config file.

Explore the Cluster

Now let's use kubectl to inspect what's running in our new cluster.

Stop the Cluster

When you're done with this chapter, stop and delete the cluster so the next chapter starts fresh:

k3d cluster stop mycluster
k3d cluster delete mycluster

Summary

🚀 Chapter 02 — Deployment: Running Your First Application

In this chapter, we'll deploy a real application to Kubernetes. You'll learn how to write YAML manifests, create a namespace, deploy an app with a Deployment, and verify it's running — all using kubectl.

Concepts: YAML & Infrastructure as Code

Infrastructure as Code (IaC) means defining your infrastructure in files that can be version-controlled, reviewed, and applied automatically. In Kubernetes, every resource — namespaces, deployments, services — is defined in YAML files. This is IaC in practice.

GitOps takes this further: your Git repository becomes the single source of truth. When you push a change to a YAML file, an automated system applies it to the cluster — giving you a full audit trail, easy rollbacks, and consistent deployments.

YAML Basics

YAML is the format Kubernetes uses for all its resource definitions. Key rules to remember:

Set Up a 4-Node Cluster

For this chapter, we'll create a cluster with 1 server (control plane) node and 3 agent (worker) nodes — 4 nodes total. This lets us see how Kubernetes schedules pods across multiple nodes.

k3d cluster create mycluster --agents 3

Create a Namespace

A Namespace is a virtual partition inside your cluster. We'll create a development namespace to isolate our workloads from the system components.

# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: development

kubectl apply -f namespace.yaml

Deploy an Application

Now let's deploy an application. We'll use pod-info-app — a simple Node.js app that displays information about the pod it's running in (name, namespace, IP address).

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-info-deployment
  namespace: development
  labels:
    app: pod-info
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pod-info
  template:
    metadata:
      labels:
        app: pod-info
    spec:
      containers:
        - name: pod-info-container
          image: kimschles/pod-info-app:latest
          ports:
            - containerPort: 3000
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP

Inspect Deployments and Pods

# Apply the deployment
kubectl apply -f deployment.yaml

# Check the deployment
kubectl get deployments -n development

# Check the pods
kubectl get pods -n development

# Get more details about a pod
kubectl describe pod <pod-name> -n development

Self-Healing in Action

Kubernetes automatically restarts failed pods. Try deleting a pod and watch Kubernetes recreate it:

# Delete a pod (replace with actual pod name)
kubectl delete pod pod-info-deployment-xxxxx -n development

# Watch Kubernetes recreate it immediately
kubectl get pods -n development --watch

Test with BusyBox

Deploy a BusyBox pod to test connectivity from inside the cluster:

# busybox.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
        - name: busybox
          image: busybox:latest
          command: ["sleep", "3600"]

# Get pod IPs
kubectl get pods -n development -o wide

# Exec into BusyBox
kubectl exec -it busybox-<id> -- /bin/sh

# Inside BusyBox: make an HTTP request to your app
wget <pod-ip>:3000
cat index.html

View Application Logs

# View logs from a pod
kubectl logs <pod-name> -n development

# Follow logs in real time
kubectl logs -f <pod-name> -n development

# Show logs from all pods in the deployment
kubectl logs -l app=pod-info -n development

Scale Up: Add Nodes and Increase Replicas

Add 4 more agent nodes to the running cluster and scale the deployment to 16 replicas:

# Add 4 more agent nodes
k3d node create mycluster-extra --cluster mycluster --role agent --replicas 4

# Verify all 8 nodes are ready
kubectl get nodes

# Update deployment.yaml: set replicas: 16
# Then apply the change
kubectl apply -f deployment.yaml

# Watch pods roll out across all nodes
kubectl get pods -n development -o wide

Summary

🌐 Chapter 03 — Services, Resource Limits, and Kubernetes Architecture

In this chapter, we'll expose our application to the internet using a Service and an Ingress, add resource limits to our pods, and then take a step back to understand how Kubernetes actually works under the hood — the control plane, worker nodes, and how they coordinate together.

Set Up the Cluster

Create a k3d cluster with a port mapping so that traffic from your computer reaches the cluster's built-in load balancer:

k3d cluster create mycluster --agents 2 -p "8080:80@loadbalancer"

This maps port 8080 on your computer to port 80 on the k3d load balancer container. k3d comes with Traefik pre-installed as an ingress controller — it listens on port 80 inside the cluster and routes incoming HTTP requests to the right service.

Expose Your App with a Service and Ingress

Right now, our pods are running but they're only reachable from inside the cluster. To access the app from your browser, we need two things:

Service Types

The Service YAML

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: pod-info-service
  namespace: development
spec:
  type: ClusterIP
  selector:
    app: pod-info
  ports:
    - port: 80
      targetPort: 3000

The Ingress YAML

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pod-info-ingress
  namespace: development
  annotations:
    ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: pod-info-service
            port:
              number: 80

kubectl apply -f service.yaml
kubectl apply -f ingress.yaml

# Open in your browser
open http://localhost:8080

Add Resource Requests and Limits

Resource requests and limits tell Kubernetes how much CPU and memory each container needs and is allowed to use. This enables the scheduler to make intelligent placement decisions.

# Add to the container spec in deployment.yaml
resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

Kubernetes will perform a rolling update — replacing pods one at a time so the app stays available throughout the update.

Kubernetes Architecture

A Kubernetes cluster has two main parts: the control plane and the worker nodes.

The Control Plane

Worker Nodes

How They Work Together

Here's the sequence of events when you run kubectl apply -f deployment.yaml:

Summary

⛵ Chapter 04 — Helm: The Kubernetes Package Manager

In this chapter, we'll use Helm — the package manager for Kubernetes — to deploy a real application to our k3d cluster. Instead of writing and managing individual YAML files for every resource, Helm lets you install a complete application with a single command and customize it with a simple values file.

We'll deploy podinfo — a small Go web application purpose-built for demonstrating Kubernetes features.

Install Helm

Helm is a separate CLI tool you install alongside kubectl.

Set Up the Cluster

k3d cluster create mycluster --agents 1 -p "8080:80@loadbalancer"

Add the podinfo Helm Repository

A Helm repository is a collection of charts hosted at a URL — similar to how apt or brew have package repositories.

# Add the podinfo chart repository
helm repo add podinfo https://stefanprodan.github.io/podinfo

# Update your local cache
helm repo update

# List your configured repositories
helm repo list

Explore the Chart

Before installing anything, inspect the chart to understand what it will create and what you can configure:

# View chart metadata
helm show chart podinfo/podinfo

# View the default values (all configurable options)
helm show values podinfo/podinfo

# Search for charts on Artifact Hub
helm search hub podinfo

# Search within your added repositories
helm search repo podinfo

Install podinfo with a Values File

Rather than passing every option on the command line, create a values.yaml file to override the defaults:

# values.yaml
replicaCount: 2

ui:
  color: "#4CAF50"
  message: "Hello from Helm + k3d!"

ingress:
  enabled: true
  className: ""
  annotations:
    ingress.kubernetes.io/ssl-redirect: "false"
  hosts:
    - host: ""
      paths:
        - path: /
          pathType: Prefix

resources:
  requests:
    cpu: 10m
    memory: 32Mi
  limits:
    memory: 64Mi

# Create the namespace
kubectl create namespace podinfo

# Install the chart
helm install podinfo podinfo/podinfo --namespace podinfo -f values.yaml

Verify the Deployment

# Check the pods
kubectl get pods -n podinfo

# Check the Helm release
helm list -n podinfo

# Open in your browser
open http://localhost:8080

Upgrade a Release

Update the values file (e.g., change replicaCount: 3) and upgrade the release:

helm upgrade podinfo podinfo/podinfo --namespace podinfo -f values.yaml

# Check the release history
helm history podinfo -n podinfo

Roll Back a Release

If something goes wrong, roll back to a previous revision:

# Roll back to revision 1
helm rollback podinfo 1 -n podinfo

# Verify the rollback
helm history podinfo -n podinfo

Uninstall a Release

helm uninstall podinfo -n podinfo

# Delete the cluster when done
k3d cluster delete mycluster

Summary

🔬 Chapter 05 — Advanced Topics

In this chapter, we'll explore several advanced Kubernetes topics by running real commands against a k3d cluster. We'll cover different ways to manage pods, persistent storage, security hardening, logging and monitoring with Prometheus and Grafana, and automatic scaling with the Horizontal Pod Autoscaler.

Set Up the Cluster

k3d cluster create mycluster --agents 2 -p "8080:80@loadbalancer"
kubectl create namespace advanced

Ways to Manage Pods

Kubernetes provides several different controllers for managing pods. Each is designed for a specific use case.

Deployment: Rolling Updates

Deployments support rolling updates — Kubernetes replaces pods one at a time with zero downtime. Configure the strategy in your deployment YAML:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # At most 1 pod can be unavailable during an update
      maxSurge: 1         # At most 1 extra pod can be created during an update

# Watch the rolling update in real time
kubectl get pods -n advanced --watch

# Check rollout history
kubectl rollout history deployment/pod-info-deployment -n advanced

# Roll back to the previous version
kubectl rollout undo deployment/pod-info-deployment -n advanced

DaemonSet: One Pod Per Node

A DaemonSet ensures that exactly one copy of a pod runs on every node. Useful for log collectors, monitoring agents, and other node-level services.

# daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
  namespace: advanced
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      containers:
        - name: log-collector
          image: busybox:latest
          command: ["sh", "-c", "while true; do echo 'Collecting logs from node'; sleep 30; done"]
          volumeMounts:
            - name: varlog
              mountPath: /var/log
              readOnly: true
          resources:
            requests:
              memory: "16Mi"
              cpu: "10m"
            limits:
              memory: "32Mi"
              cpu: "50m"
      volumes:
        - name: varlog
          hostPath:
            path: /var/log

kubectl apply -f daemonset.yaml

# Verify one pod per node
kubectl get pods -n advanced -l app=log-collector -o wide

Job: Run to Completion

A Job creates pods that run until a task completes successfully. Use parallelism and completions for parallel processing.

# job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: pi-calculator
  namespace: advanced
spec:
  template:
    spec:
      containers:
        - name: pi
          image: perl:slim
          command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "128Mi"
              cpu: "250m"
      restartPolicy: Never

Persistent Volumes

Pods are ephemeral — when they restart, their data is lost. A PersistentVolumeClaim (PVC) requests durable storage that survives pod restarts. We'll deploy PostgreSQL with a PVC to demonstrate stateful workloads.

# postgres-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
  namespace: advanced
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Kubernetes Security

Security Context in Action

A Security Context defines privilege and access control settings for Pods and containers. Compare an insecure deployment (running as root) with a hardened one:

# Hardened security context
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

Scanning with Snyk

Snyk scans your YAML files for security misconfigurations before they reach production:

# Install Snyk CLI
npm install -g snyk

# Authenticate
snyk auth

# Scan your YAML files
snyk iac test deployment.yaml

Logging and Monitoring with Prometheus and Grafana

Install the kube-prometheus-stack Helm chart to get Prometheus (metrics collection) and Grafana (visualization) running in your cluster in minutes:

# Add the prometheus-community Helm repository
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# Create the monitoring namespace
kubectl create namespace monitoring

# Install the kube-prometheus-stack
helm install prometheus prometheus-community/kube-prometheus-stack   --namespace monitoring   --set grafana.adminPassword=admin

# Port-forward Grafana to your browser
kubectl port-forward svc/prometheus-grafana 3000:80 -n monitoring

Open http://localhost:3000 in your browser (username: admin, password: admin). Pre-built dashboards give you instant visibility into cluster health, node resource usage, and application metrics.

Horizontal Pod Autoscaler (HPA)

The HPA automatically scales the number of Pod replicas based on observed CPU utilization or custom metrics. Set a target CPU percentage and min/max replica counts — Kubernetes handles the rest.

# Create an HPA targeting 30% CPU utilization
kubectl autoscale deployment pod-info-deployment   --namespace advanced   --cpu-percent=30   --min=2   --max=8

# Watch the HPA
kubectl get hpa -n advanced --watch

# Generate load to trigger scaling
kubectl run load-generator --image=busybox -n advanced --   /bin/sh -c "while true; do wget -q -O- http://pod-info-service; done"

# Stop the load generator
kubectl delete pod load-generator -n advanced

Summary

☁️ Chapter 06 — Kubernetes in Production: Local, On-Prem, and the Cloud

Throughout this tutorial, you've been running Kubernetes locally using k3d — a lightweight tool that runs a full Kubernetes cluster inside Docker containers on your computer. That's great for learning, but production Kubernetes looks very different.

In this chapter, we'll compare three ways to run Kubernetes in production, then deep-dive into the three major cloud providers' managed Kubernetes offerings: Amazon EKS, Google GKE, and Microsoft AKS.

What You've Been Running: k3d

On-Premises Kubernetes

On-premises Kubernetes means running Kubernetes on hardware that you own and operate — either in your own data center or in a co-location facility.

When you run Kubernetes on-prem, you own the entire stack: hardware procurement, OS patching, Kubernetes upgrades, etcd backups, high availability, networking (CNI plugin), storage (CSI driver), load balancing, certificate management, and security.

On-prem makes sense for: data sovereignty/compliance, existing hardware investment, air-gapped environments, and predictable high-volume workloads.

Managed Kubernetes on the Cloud

A managed Kubernetes service means the cloud provider handles the control plane for you. You focus on deploying your applications; they handle the infrastructure.

Side-by-Side Comparison

Cloud Provider Comparison: EKS vs. GKE vs. AKS

All three major cloud providers offer managed Kubernetes. They all run standard Kubernetes under the hood — your YAML manifests work on all three. The differences are in the surrounding ecosystem, pricing, and operational experience.

Which Should You Choose?

Key Concepts for Production Kubernetes

Summary

Every concept in this tutorial — Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, PVCs, DaemonSets, Jobs, HPA, Security Contexts, Helm — works identically on EKS, GKE, AKS, and any on-prem cluster. The Kubernetes API is the same everywhere.

The cloud-specific differences are in the infrastructure layer beneath Kubernetes: how load balancers are provisioned, how storage is allocated, and how IAM is integrated. Once you understand those integrations for your chosen provider, you're ready to run production workloads.

📚 Core Concepts Reference

New to containers or Docker? This reference guide explains the foundational concepts that Kubernetes is built on — the “what” and “why” behind containers, Docker, and the key Kubernetes objects. Refer back to it whenever you encounter an unfamiliar term in the tutorial.

Containers & Docker

Kubernetes Building Blocks

Production Kubernetes Concepts

Conclusion

This tutorial has taken you from zero to a solid understanding of Kubernetes — from spinning up your first local cluster with k3d, to writing YAML manifests, deploying applications, exposing them with Services and Ingress, managing them with Helm, exploring advanced topics like DaemonSets, StatefulSets, security contexts, and the HPA, and finally understanding how production Kubernetes works on AWS EKS, Google GKE, and Azure AKS.

The key insight is that the Kubernetes API is the same everywhere. Every concept you've learned — Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, PVCs, Jobs, HPA, Helm — works identically on any Kubernetes cluster, whether it's running on your laptop with k3d or in production on a managed cloud service. The cloud-specific differences are only in the infrastructure layer beneath Kubernetes.

About the Author

Wayne Cheng is the founder and AI app developer at Audoir, LLC. Prior to founding Audoir, he worked as a hardware design engineer for Silicon Valley startups and an audio engineer for creative organizations. He holds an MSEE from UC Davis and a Music Technology degree from Foothill College.

Learn More

Further Exploration

Explore the complete tutorial repository and experiment with extending the examples. Consider deploying a real multi-service application, setting up a CI/CD pipeline that deploys to your cluster, or migrating one of the chapters to a managed cloud provider to deepen your understanding of production Kubernetes.

For more AI-powered development tools and tutorials, visit Audoir .