GitOps on EKS: let a controller pull the desired state
GitOps declares the desired cluster state in Git and runs a controller inside the cluster that continuously reconciles toward it. Argo CD and Flux are the common choices; both are Kubernetes controllers and CRDs themselves, installed with Helm like any workload. A pull request is the change mechanism, so every change is reviewed, auditable and revertible.
On EKS the model fits the responsibility boundary naturally. AWS runs the control plane; the platform team only has to keep workloads and configuration correct, which is exactly what continuous reconciliation does. The security benefit is real: the controller has a scoped identity (a Pod Identity role to read a private repository or ECR), and no pipeline or human needs a standing credential that can change the cluster directly.
Draw the boundary with Terraform deliberately. Terraform creates the cluster, networking, IAM and add-on configuration; GitOps manages what runs inside. Overlap, for example both tools managing the same add-on, produces fights and surprising drift. Reveal the four stages with the right arrow.
Operationally plan for the controller's own upgrades, avoid putting Secret values in Git (use external secrets), and decide how image updates are promoted (by digest through pull requests or an image automation controller).