If you've been managing Kubernetes clusters the traditional way, you're probably familiar with the chaos: kubectl commands run across terminals, someone applies changes directly to production, and suddenly nobody's sure what state the cluster is actually in. GitOps fixes that by making Git your single source of truth for everything, your infrastructure configuration and your deployments.
What GitOps actually means
At its core, GitOps is simple. You declare your desired system state in Git, and a controller continuously watches that repo and syncs your cluster to match it. This sounds obvious in theory, but it changes everything operationally. You get four things automatically: everything is declaratively described, any changes come through Git, a software agent keeps the actual state in sync with what you declared, and no one runs kubectl apply in production. Your Git history becomes your complete audit log.
Flux v2 as a toolkit
Flux v2 is the open source option here, and it's solid. It handles syncing your Git repos to your clusters, manages Helm releases and Kustomize overlays, and gives you composable APIs so other tools can build on it. What's useful is that Flux handles multi-tenancy (different teams managing their own repos without stepping on each other), multi-cluster setups (one management cluster coordinating workload clusters), and image automation (automatically updating image tags when new versions hit your registry).
Argo CD for the dashboard view
Argo CD takes a different angle. You get a UI that shows you the diff between what you declared in Git and what's actually running. From there you can sync with one click or set it to sync automatically and it'll tell you if everything's healthy. You can see your deployment history, what each resource is doing, and Argo Rollouts lets you do blue/green deployments and canary releases with automatic rollback if your metrics go wrong.
The operational side
The real payoff is operational discipline. PRs replace direct changes, so someone reviews everything before it goes in. Your Git history is the audit trail. If something breaks, git revert is your rollback. But you need to do a few things right: everything goes through Git (no exceptions in production), your repo structure has to match your actual deployment topology, and secrets get encrypted separately using Sealed Secrets or ExternalSecrets. Plain text secrets in Git are a non-starter.