Kubernetes
K8s Intermediate #4: resources.requests / limits — Pod Resource Requests and Limits
[#3](/en/posts/k8s-intermediate-3) covered the path of external traffic into the cluster. This post moves the viewpoint back inside the Pod — the model of how a container requests and is limited on CPU and memory. `resources.requests` is what the scheduler sees when picking a node; `resources.limits` is the runtime cap kubelet enforces. This post walks through the separation of the two, QoS classes (Guaranteed / Burstable / BestEffort), the difference between CPU throttling and OOMKilled, JVM/Go runtime cgroup awareness, and the pattern of setting namespace defaults via `LimitRange` — all in one cycle.
K8s Intermediate #3: Ingress and Ingress Controller — The External Entry Point
[K8s Basics #5](/en/posts/k8s-basics-5) covered LoadBalancer as the standard external entry point, but when dozens of Services need external exposure, spinning up one cloud LoadBalancer per Service quickly inflates cost and management overhead. Routing by domain or path also can't be solved with a single LoadBalancer. This post follows the object that gathers that burden in one place — `Ingress` — and the Ingress Controller (nginx / Traefik / GKE Ingress / AWS ALB Controller) that turns those manifests into actual traffic, walking through the two-layer model, host/path-based routing, `pathType`, TLS termination, and `IngressClass` in one cycle.
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.