Platform

“Should I use ArgoCD or Flux?” I’ve been asked this question dozens of times. The honest answer: both are excellent. The real question is which fits your context better. I use ArgoCD. But that’s a choice based on my specific needs, not a universal truth. Let me explain both tools, their philosophies, and help you decide. The Core Philosophy Difference Before comparing features, understand the fundamental difference in approach: ArgoCD is application-centric. You define Applications that point to Git sources. ArgoCD manages them through a central control plane with a UI. ...

GitOps changed how I think about deployments. Instead of running commands against a cluster, I push to Git and watch the cluster converge to the desired state. It sounds simple, but the implications are profound. ArgoCD is my tool of choice for GitOps. Let me show you why, and how to get started. Why GitOps? The Philosophy First Before diving into ArgoCD, let’s understand why GitOps matters. Traditional deployment: Developer → kubectl apply → Cluster The problem: What is deployed? You have to query the cluster. Configuration drift happens silently. Rollbacks are manual and error-prone. There’s no audit trail beyond “someone ran kubectl.” ...

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

Kubernetes Network Policies are one of those features that everyone knows they should use but few actually understand. The YAML looks intimidating, the behavior is non-intuitive, and the mental model takes time to develop. I’ve spent hours debugging policies that “should work” but didn’t. Let me save you that pain with a visual approach to understanding Network Policies. The Default: Everything Talks to Everything By default, Kubernetes allows all pod-to-pod communication. Any pod can reach any other pod across any namespace. This is convenient for getting started but terrible for security. ...