Docker & Kubernetes Tutorial

You have worked through all 12 articles in the Kubernetes series. Now it is time to go to production. This checklist covers everything you need to verify before your application is ready for real traffic. Each item links back to the tutorial where it is covered in depth. Going through this checklist before your first production deploy will save you from the most common production failures. Reliability Define resource requests and limits on every container Without requests, the Kubernetes scheduler cannot place Pods correctly. Without limits, one runaway container can OOM-kill an entire node. ...

Your app works great with 2 replicas at normal traffic. But at peak hours it gets 10x more requests. And at 3 AM it gets almost none. Running 10 replicas around the clock wastes money. Running 2 replicas at peak is too slow. Kubernetes can scale your application automatically — up when traffic is high, down when it is quiet. This tutorial covers three autoscaling tools. Three Types of Scaling Type What scales Tool Horizontal Number of Pods HPA, KEDA Vertical CPU/RAM per Pod VPA Cluster Number of nodes Cluster Autoscaler Horizontal scaling adds more copies of your app. Vertical scaling makes each copy bigger. Cluster autoscaling adds more machines to the cluster when all machines are full. ...

A Kubernetes cluster has many attack surfaces. Misconfigured Pods can break out of their namespace. Overprivileged service accounts can access the entire cluster. Unscanned images can run with known vulnerabilities. This tutorial covers the essential security practices before taking any Kubernetes application to production. The 4Cs of Cloud Native Security Think of Kubernetes security in layers: Cloud → Cluster → Container → Code Code — vulnerabilities in your application code Container — image security, running as non-root, minimal base images Cluster — RBAC, Pod Security Standards, Network Policies Cloud — network firewall rules, IAM policies, cloud provider security Each layer depends on the one below it. Fixing only one layer is not enough. This tutorial focuses on the Container and Cluster layers. ...

Deploying to Kubernetes manually is slow and error-prone. Every deploy requires building an image, pushing it to a registry, and updating the cluster. With CI/CD, all of that happens automatically on every push to your main branch. Write code, push to GitHub, and your new version is live in minutes — with zero-downtime rolling updates. This tutorial builds a complete pipeline with GitHub Actions. The Pipeline Overview Developer pushes code to main branch ↓ GitHub Actions triggers workflow ↓ Build Docker image ↓ Push image to registry (GHCR or Docker Hub) ↓ Deploy to Kubernetes (kubectl apply or helm upgrade) ↓ Wait for rollout to complete ↓ Done — new version is live Prerequisites A Kubernetes cluster (for this tutorial, we use a real cluster — not minikube). Options: k3s on a VPS, or any cloud provider. A GitHub repository with your app code and Kubernetes manifests Basic understanding of GitHub Actions (jobs, steps, secrets) Step 1: Prepare the Kubernetes Manifests Keep your Kubernetes YAML files in your repository, under a k8s/ directory: ...

Your Kubernetes app is running. But is it healthy? Is it slow? Are any Pods crashing? How much memory is it using? Without monitoring, you find out about problems when users complain. With monitoring, you know before they do. The industry standard for Kubernetes monitoring is Prometheus + Grafana. Prometheus collects and stores metrics. Grafana visualizes them in dashboards. The Observability Stack Observability has three pillars: Metrics — numbers over time (CPU usage, request count, error rate) Logs — what happened and when (application output, events) Traces — how a request flows through multiple services This tutorial focuses on metrics with Prometheus and Grafana. Logging (Fluent Bit) and tracing (OpenTelemetry + Jaeger) are separate topics. ...

A production Kubernetes application quickly grows into dozens of YAML files: Deployments, Services, ConfigMaps, Secrets, Ingress rules, RBAC roles, and more. Managing all of these manually is error-prone. Different environments (dev, staging, production) need different values. Sharing your app with others means sending them a bundle of raw YAML. Helm solves this. It is the package manager for Kubernetes — think npm for Node.js or apt for Ubuntu, but for Kubernetes applications. ...

Your Kubernetes app is running. Services expose it inside the cluster. But how does external traffic reach it? This used to be solved by Kubernetes Ingress and the popular ingress-nginx controller. But in March 2026, ingress-nginx moved to maintenance-only mode. No new features. Best-effort support only. If you are starting a new project today, use the Kubernetes Gateway API instead. It is the official, actively developed successor — built by the same SIG Network team that built Ingress. ...

Pods are ephemeral. When a Pod is deleted or rescheduled to a different node, all data written inside it is gone. This is fine for stateless apps. But databases, file uploads, and cache data need to survive Pod restarts. That is what Persistent Volumes are for. The Problem with Pod Storage By default, a container’s filesystem lives only as long as the container lives. When the container stops, the data disappears. ...

Your application needs a database host, a port number, an API key, and a password. How do you pass these to your containers in Kubernetes? You should not hardcode them in the Docker image. You should not put passwords in your Deployment YAML either. Kubernetes has two objects for this: ConfigMap — for non-sensitive configuration Secret — for sensitive data like passwords and API keys Why Not Hardcode Config? Imagine you hardcode a database hostname in your Docker image: ...

When you deploy an application to Kubernetes, you work with three objects almost every time: Pods, Deployments, and Services. A Pod is the unit that runs your containers A Deployment manages a set of Pods and handles updates A Service gives your Pods a stable network address Understanding these three is the foundation for everything else in Kubernetes. Prerequisites: A running Kubernetes cluster. See Kubernetes Tutorial #2: Installing Kubernetes Locally. Pods — The Smallest Unit A Pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share the same network and storage. ...