#Kubernetes
141 posts
K8s Intermediate #2: PV / PVC / StorageClass — The Persistent Data Model
Through [K8s Basics #6](/en/posts/k8s-basics-6) we pulled config and secrets out of the manifest into external objects, but one dimension remains — the data itself. The container filesystem disappears with the container, but DB data, user uploads, and metric time series have to outlive the Pod. This post fills that gap with the triangle of PersistentVolume, PersistentVolumeClaim, and StorageClass — static and dynamic provisioning, accessModes, reclaimPolicy, volumeBindingMode, and what StatefulSet's volumeClaimTemplates from [#1](/en/posts/k8s-intermediate-1) actually produces on top of all this.
K8s Intermediate #1: StatefulSet / DaemonSet / Job / CronJob — Controllers Beyond Deployment
The [Deployment](/en/posts/k8s-basics-4) from K8s Basics #4 sits on a stateless model — multiple identical Pods that come back the same way when they die. But databases that need identity and disks, agents that need exactly one per node, migrations that should run once, daily backups — none of these fit Deployment. This post covers the four controllers that fill those gaps in one pass: StatefulSet, DaemonSet, Job, CronJob.
K8s Basics #7: Namespaces and Labels — Organizing the Cluster
One thing slipped past quietly through this series — every Pod, Deployment, Service, ConfigMap, and Secret we created landed in the default namespace. And labels have been with us since [#4](/en/posts/k8s-basics-4)'s selector but never got their own pass. This post wraps the series with the two tools — Namespace and labels — that turn a cluster into something a human can read, and previews the next track (K8s Intermediate).
K8s Basics #6: ConfigMap and Secret — Splitting Out Configuration
Through [#5](/en/posts/k8s-basics-5), one thing in our manifest is still awkward — image tags, ports, and domains are written directly into it. This post pulls those out into two objects: ConfigMap and Secret. The K8s way to apply the 12-factor "store config in the environment" rule, three injection methods (env / envFrom / volume), the one-line caveat that Secret is not actually encryption, and why a Pod restart is needed when config changes.
K8s Basics #5: Service — ClusterIP / NodePort / LoadBalancer
[#4](/en/posts/k8s-basics-4) got 3 Pods running, but how traffic reaches them is still empty. Pod IPs change every time, no load balancing across the 3 Pods of one Deployment, and an external browser cannot get in at all. This post fills that gap with the Service abstraction — stable IP and DNS, how selector / Endpoints work, and the trade-offs across the three types ClusterIP / NodePort / LoadBalancer.
K8s Basics #4: Deployment and ReplicaSet — Declarative Deploys and Rolling Updates
A follow-up to the closing line of [#3](/en/posts/k8s-basics-3) — Pods are mortal, they just disappear when they die. This post writes a controller manifest for the first time. We pin down the three layers Deployment / ReplicaSet / Pod, watch auto-recovery when one Pod is deleted under replicas: 3, see how a one-character image-tag change drives a rolling update, and roll back a bad version with one command.
K8s Basics #3: kubectl and Your First Pod
Time to put your first workload onto the cluster from [#2](/en/posts/k8s-basics-2). We pin the kubectl command pattern in one table, bring up a first Pod imperatively with kubectl run, then rewrite the same shape as a YAML manifest. We inspect the Pod with describe / logs / exec, and end on the question — why one Pod is not enough, which is exactly why the next post needs Deployment.
K8s Basics #2: Local Environments — minikube / kind / Docker Desktop k8s
Time to actually meet the control plane / worker picture from [#1](/en/posts/k8s-basics-1). Compare the three ways to run K8s on a laptop (minikube / kind / Docker Desktop k8s), install kubectl, and bring up your first cluster with kind — through to inspecting the nodes and system pods.
K8s Basics #1: What Is Kubernetes — Why Do We Need a Container Orchestrator?
You can run a single container with Docker. But what if you need 100 — and they need to restart on failure, scale with traffic, and survive a node going down? This first post in the series covers the limits of single-container tools, the problem container orchestrators solve, and the big picture of a Kubernetes cluster.