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