Manual Deployments to Flux GitOps Blueprint
This blueprint adopts Flux CD pull-based GitOps to reconcile Kubernetes clusters from Git, replacing manual deploys. It covers repository design, SOPS-based secret handling, waved migration, and automated image updates that close the loop from CI to cluster.
What and Why
Manual Kubernetes deploys leave no reliable record of desired state and make rollbacks fragile. Engineers apply manifests by hand or let CI push changes straight into the cluster, so the live state and any file in version control slowly diverge. Flux CD is a pull-based GitOps toolkit (a Cloud Native Computing Foundation graduated project) that runs inside the cluster and continuously reconciles it against Git. Where a push model sends changes into the cluster from outside, Flux pulls them, which keeps cluster credentials inside the cluster and shrinks the attack surface.
The outcome is the same GitOps promise: declarative desired state in Git, automatic reconciliation, drift detection, and Git-based rollback. Flux composes from a set of focused controllers (source, kustomize, helm, image-reflector, image-automation, notification) so a team can adopt only the pieces it needs and fit different repository layouts.
Phases
Assessment. List workloads, current deploy steps, environments, clusters, and secrets. Note which apps are Helm releases versus raw manifests, since Flux handles both through different controllers (HelmRelease versus Kustomization). Record any manual or out-of-band changes already in the cluster, and baseline deployment frequency and recovery time.
Design. Decide repository structure: per-cluster directories, per-environment overlays with Kustomize, or HelmRelease objects referencing a chart repository. Plan secret management with SOPS (Mozilla's tool for encrypted secrets committed to Git) or External Secrets Operator. Define reconciliation intervals, and use dependsOn to express ordering between Kustomizations so shared infrastructure lands before applications.
Bootstrap. Run flux bootstrap to install controllers and commit the bootstrap manifests to Git, so Flux manages itself. Verify the source-controller pulls the repo and the kustomize-controller applies it. Configure the notification controller to post sync results to Slack or an alerting system.
Migration. Convert live workloads to declarative manifests or HelmRelease resources and move them in waves, lowest-risk first. Use dependsOn to order shared infrastructure before applications. Validate health assessment and pruning on non-production before enabling them on production, so a mistaken commit cannot prematurely delete resources.
Automation. Enable Flux image automation so the image-reflector controller scans the registry and the image-automation controller opens commits or pull requests that bump image tags according to a policy (for example, semver ranges). This closes the loop from CI build to deployed change without manual edits, while keeping every change in Git history.
Key Risks and Mitigations
- Configuration drift during adoption. Reconcile live state into Git before enabling pruning, review the planned diff with
flux diff, and enable pruning only after a confidence period. - Secret handling. Use SOPS-encrypted secrets or External Secrets Operator; never commit plaintext. Manage the SOPS key in a cloud key management service and rotate any previously exposed secret.
- Reconcile loops. Misconfigured dependencies or image policies can cause churn or fighting controllers. Set sensible intervals, use
dependsOn, and watch controller logs and events during rollout.
Recommended Tooling
Flux CD controllers, Kustomize and Helm for templating, SOPS or External Secrets Operator for secrets, and a CI system to build and push images. Use Flux's notification controller for alerts and Flagger (which integrates with Flux) for progressive delivery such as canary analysis.
Success Metrics
Track deployment frequency, MTTR through Git revert, change failure rate, and drift detection latency. Automated image updates should also cut the manual toil of version bumps and shorten lead time.
Prerequisites
A Kubernetes cluster, an image registry, a Git host, a SOPS key or secrets operator, and agreement on repository layout and reconciliation policy. The team should also agree on naming conventions for Kustomizations and HelmReleases, and on who owns the config repository, since a merge to it triggers a deployment. Decide reconciliation intervals per environment and document the rollback procedure (revert the commit and let Flux reconcile) so on-call engineers can recover quickly without manual cluster access.