Intermediate

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: ...

Most beginner Docker setups have serious security problems. Containers running as root. Passwords in Dockerfiles. Outdated base images with known vulnerabilities. No resource limits. This tutorial covers the most important Docker security practices. You do not need to implement all of them at once. Start with the first three — they will fix the most critical issues. 1. Never Run Containers as Root By default, processes inside Docker containers run as root (UID 0). If an attacker exploits a vulnerability in your app, they have root access inside the container — and potentially a path to the host. ...

“Works on my machine” is a classic developer problem. One developer runs Python 3.11, another runs 3.13. One uses PostgreSQL 15, another uses 16. The app behaves differently on every machine. Docker solves this. With Docker, your entire development environment — app, database, cache, message queue — is defined in a YAML file. Every developer on your team runs identical environments with one command. Why Use Docker for Development? Consistent environments — everyone runs the same versions of everything No installation required — no need to install PostgreSQL, Redis, or Node locally Easy onboarding — new team members run docker compose up and have everything Clean isolation — each project has its own versions, no conflicts between projects Production parity — dev environment matches production as closely as possible The Development Compose Pattern A common pattern is to have two Compose files: ...