High Availability

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 I first set up a “production” Kubernetes cluster, I had one control plane node. It worked fine until it didn’t — a failed disk took down the entire cluster. Every pod, every service, everything. That day taught me what “single point of failure” really means. Kubernetes High Availability isn’t optional for production. But there’s a choice that trips up many people: do you run etcd on your control plane nodes (stacked), or on separate dedicated nodes (external)? Let me break down both approaches. ...