#Kubernetes
Kubernetes orchestrates containerised workloads across clusters with declarative configuration and self-healing capabilities. These articles cover GKE production patterns, operator development, Kafka consumer scaling, multi-agent AI deployment on Kubernetes, and the operational practices that keep clusters reliable.
17 posts tagged with kubernetes. ← All posts
Kubernetes's deepest idea isn't its built-in objects — it's that the reconciliation model is extensible. You can teach Kubernetes new concepts and automate operating them, which is what operators do. This closing post covers that extension model, the realities of running Kubernetes in production, and the honest verdict on when its power is worth its complexity.
Kubernetes's deepest idea isn't its built-in objects — it's that the reconciliation model is extensible. You can teach Kubernetes new concepts and automate operating them, which is what operators do. Plus the realities of running it in production, and when it's worth the complexity.
Kubernetes has to answer a question every time a pod is created: which machine should run it? The scheduler answers it, and the quality of that answer depends entirely on information you provide — resource requests and limits. Get those right and the cluster packs efficiently and stays stable; get them wrong and you get waste, evictions, and mysterious outages.
Kubernetes answers a question every time a pod is created: which machine runs it? The scheduler answers it, and the quality depends on resource requests and limits you provide. Get those wrong and you get waste, evictions, and mysterious outages.
Pods are disposable — destroyed and recreated constantly — which raises two problems: how do you give a pod its configuration without baking it into the image, and how does any data survive a pod's death? ConfigMaps and Secrets answer the first; volumes and StatefulSets answer the second. This is how stateless-by-default Kubernetes handles config and the state it can't avoid.
Pods are disposable, which raises two problems: how to give a pod its config without baking it into the image, and how any data survives a pod's death. ConfigMaps and Secrets answer the first; volumes and StatefulSets answer the second.
Pods are ephemeral and get new IPs every time they're replaced, so how does anything reliably reach them? The Service — a stable address and load balancer in front of an ever-changing set of pods. Kubernetes networking looks intimidating, but it's a few clear layers solving one problem: stable communication over unstable pods.
Pods are ephemeral and get new IPs every time they're replaced, so how does anything reliably reach them? The Service — a stable address and load balancer in front of an ever-changing set of pods. Kubernetes networking is a few layers solving one problem.
Controllers are where Kubernetes's core idea — declarative desired state plus reconciliation — becomes machinery. A controller is a loop that watches "what you want" versus "what exists" and acts to close the gap, forever. Self-healing, scaling, and zero-downtime rollouts are all just controllers doing that one thing. This is the engine of Kubernetes.
Controllers are where Kubernetes's core idea — declarative desired state plus reconciliation — becomes machinery. A controller is a loop that watches what you want versus what exists and acts to close the gap, forever. Self-healing, scaling, and rollouts are all just that.
GitOps takes one idea to its logical conclusion: if your infrastructure and deployments are declarative code, then git should be the single source of truth, and a machine — not a human running commands — should continuously make reality match git. It turns "deploy" from an action you perform into a state you declare, and it's how modern platforms run.
GitOps takes one idea to its conclusion: if infrastructure and deployments are declarative code, git should be the single source of truth, and a machine — not a human running commands — should continuously make reality match git.
Kubernetes doesn't run containers directly — it runs pods. This surprises newcomers: why wrap a container in another abstraction? Because the pod solves a real problem — some containers genuinely need to run together, sharing network and storage — and making the pod (not the container) the unit of scheduling is what makes the rest of Kubernetes coherent.
Kubernetes doesn't run containers directly — it runs pods. Why wrap a container in another abstraction? Because some containers genuinely need to run together sharing network and storage, and making the pod the unit of scheduling keeps the rest of Kubernetes coherent.
A container feels like a lightweight virtual machine, but it isn't one — there's no guest OS, no hypervisor, no virtualization. A container is just a normal process that the Linux kernel has been told to isolate and constrain. Understanding that — namespaces for isolation, cgroups for limits, images for packaging — demystifies containers and everything Kubernetes builds on them.
A container feels like a lightweight virtual machine, but it isn't one — no guest OS, no hypervisor, no virtualization. A container is just a normal process the Linux kernel has been told to isolate (namespaces) and constrain (cgroups).
Kubernetes is famously complex, and most explanations start with its parts — pods, deployments, services — which is exactly backwards. Start with the problem: you have containers, you have many machines, and you need something to run the right containers on the right machines and keep them running as things fail. Kubernetes is a control loop for that, and once you see it that way, the complexity becomes comprehensible.
Kubernetes is famously complex, and most explanations start with its parts — which is backwards. Start with the problem: you have containers, many machines, and need something to run the right containers on the right machines and keep them running as things fail.
Securing the runtime platform end to end — hardened images, least-privilege workloads, default-deny networks, and admission control as the gate that decides what is ever allowed to run.
Securing the runtime platform: minimal non-root images scanned for CVEs, the container isolation model and hardening (drop caps, read-only FS, seccomp), and Kubernetes — Pod Security Standards, RBAC, default-deny NetworkPolicies, and admission control (Gatekeeper/Kyverno).
Notes from integrating OpenTelemetry into airshipit, an open-source bare-metal Kubernetes lifecycle project with contributions from Ericsson, AT&T, Microsoft, and others. The hard part wasn't OTel; it was making distributed traces useful across foreign code.
The azure-service-operator project lets you declare Azure resources as Kubernetes objects. Notes from the multi-vendor collaboration shape: how decisions got made, what slowed us down, what shipped despite it.
The transaction engine had to absorb 30K+ TPS across partner integrations, never lose a transaction, and survive partial failures. The architecture: Go, Kafka, Pub/Sub, Redis, K8s, with idempotency at every layer.
Field notes from running multi-agent AI on K8s. The patterns the book recommends, the ones that survived contact with production, and the ones that broke in interesting ways.
Postgres over the latest vector DB. Go stdlib over the framework du jour. Single binary over Kubernetes operator. The choices that bore reviewers and delight on-call engineers.
GOMEMLIMIT tells the Go runtime to keep memory below a soft cap by running GC harder when it's close. For containers with hard memory limits, this prevents OOM kills. The setting every Go service in K8s should have.
Multi-agent stacks have state: vector indexes, chat histories, agent memory. GKE for AI workloads needs StatefulSets, PVCs, gateway controllers, and the patterns that work in 2026.
All posts on this site are written by Pratik Dhanave, an Agentic AI Architect with 7+ years building production distributed systems, multi-agent AI platforms, and cloud-native infrastructure. About the author → Each article includes working code, architecture diagrams, and references to the specific frameworks and standards discussed. Browse all posts or explore related topics using the tag cloud above.