Architecture

I write a lot about Kubernetes. I use it daily. I’m a fan. But Kubernetes isn’t always the answer. In fact, for many teams and projects, Kubernetes is the wrong choice. Too complex, too expensive, too much overhead for what they’re trying to achieve. This is the post I’m writing for everyone considering Kubernetes adoption. Not to discourage you, but to help you make a conscious choice. The Kubernetes hype Kubernetes has won. It’s the de-facto standard for container orchestration. Every cloud provider offers managed Kubernetes. Every DevOps job posting asks for Kubernetes experience. ...

You start with one ArgoCD Application. Then five. Then twenty. Before you know it, you’re managing hundreds of Applications, and the manual overhead is killing your productivity. The App-of-Apps pattern solves this: one root application that manages all other applications. This is how I structure every GitOps repository, and it scales from homelab to enterprise. The Problem: Application Sprawl When you first adopt ArgoCD, you create Applications manually: kubectl apply -f apps/frontend.yaml kubectl apply -f apps/backend.yaml kubectl apply -f apps/database.yaml # ... repeat for every service This works for small deployments. But it creates problems: ...

What happens when your Kubernetes cluster can’t reach the internet? Not “slow connection” — no connection at all. Ships at sea. Remote mining sites. Factory floors with air-gapped networks. Military deployments. This isn’t an edge case. It’s a design requirement for anyone who takes sovereignty seriously. Why This Matters: Beyond the Technical Running Kubernetes offline forces you to confront a question most cloud-native guides ignore: what are you actually depending on? ...

Kubernetes is designed to be self-healing, but what does that actually mean? More importantly: what happens when the components doing the healing themselves fail? I’ve run Kubernetes clusters through all kinds of failures — planned, unplanned, and “hold my beer” experiments. Here’s what actually happens when things break. The Components That Can Fail Before diving into failure scenarios, let’s map out what we’re working with: Control Plane: kube-apiserver: The API that everything talks to etcd: The database storing all cluster state kube-scheduler: Decides where pods run kube-controller-manager: Runs controllers (ReplicaSet, Deployment, etc.) cloud-controller-manager: Cloud provider integrations (if applicable) Node Components: ...

When something goes wrong in Kubernetes, it’s often etcd. API server timing out? Check etcd. Pods stuck in pending? Might be etcd. Cluster feels slow? Probably etcd. Yet most Kubernetes operators treat etcd as a black box. It’s just “the database” that runs alongside the control plane. But understanding etcd makes you dramatically better at operating Kubernetes. Let me take you inside. What is etcd? etcd is a distributed key-value store. Think of it as a highly reliable dictionary that multiple servers agree on. Kubernetes uses it to store all cluster state: every pod, deployment, secret, configmap, and custom resource lives in etcd. ...