GitOps — The Single Source of Truth
A classic scenario: an on-call engineer makes a critical change directly to the cluster using kubectl apply during an incident. A week later, CI/CD overwrites that change — the incident repeats, and the team loses hours figuring out why. In one of our projects, we recorded up to 47 drifts in a month across three clusters with 50 microservices. We encounter this regularly, which is why we offer turnkey GitOps implementation: git becomes the single source of truth for infrastructure state. Any change goes through a Pull Request with mandatory review and audit. This eliminates manual intervention and guarantees reproducibility.
GitOps is not just a tool, but a methodology for infrastructure management based on declarative configuration, versioning, and automatic synchronization. ArgoCD and Flux are the two main tools, each with its own strengths. ArgoCD provides a convenient web interface and is suitable for teams starting with GitOps. Flux is more Kubernetes-native and better for multi-tenant clusters. We choose the tool based on the client's task, rather than imposing one.
Our team of certified Kubernetes engineers with 5+ years of experience has implemented GitOps for 30+ projects — from startups to enterprises. Average deployment time savings of 40%, incident reduction by 2-3 times, and MTTR decreased by 60%. We will assess your project and offer the optimal solution. Get a consultation today.
What problems do we solve with GitOps?
Manual changes in the cluster. Even experienced engineers sometimes run kubectl scale during an incident. Without GitOps, that change does not land in git — drift is inevitable. GitOps automatically detects any discrepancies and rolls back the cluster to the repository state.
Configuration drift. We've seen projects where the difference between staging and production reached over 30 parameters. GitOps with Kustomize overlays allows keeping a base configuration once and overriding only differences between environments. This reduces the probability of errors by 80%. The average impact from a single undetected drift can be substantial due to downtime and rollbacks.
Secret management. Storing a Secret in plaintext in git is not allowed. We use Sealed Secrets or External Secrets Operator — encrypted secrets are committed to the repository, and the cluster controller decrypts them locally. Alternatively, store a reference to Vault or AWS Secrets Manager. Both approaches are secure and comply with GitOps principles.
ArgoCD vs Flux: What to Choose?
| Feature | ArgoCD | Flux |
|---|---|---|
| Interface | Built-in UI with resource graph | Only CLI / CRD (Weave GitOps available) |
| Operation | Polling every 3 min (default) | Webhook + watch for near real-time |
| Management | Application CRD |
GitRepository, HelmRelease, Kustomization |
| Multi-tenant | Via AppProject with RBAC | Native isolation via Kustomization |
| Drift detection | Built-in, with selfHeal |
Automatic reconciliation |
| Popularity | Higher, larger community | Lower, but active development |
In practice: if the team wants visual control and low entry threshold — we choose ArgoCD. If priority is everything as code without UI and maximum integration with Kustomize — Flux. We help you choose based on your ecosystem.
How does Drift Detection work?
Drift is the discrepancy between the state in git and the actual cluster. It arises from manual kubectl, HPA actions, controller changes. ArgoCD checks every 3 minutes by default. When drift is detected, the application goes to OutOfSync. The action depends on the policy: manual — only notification, automatic — immediate rollback.
The strictest mode is automatic sync with selfHeal: true. ArgoCD forcefully returns the cluster to the state in git, even if changes were made manually. This eliminates any unauthorized edits. However, risks must be understood: if an on-call engineer increased replicas to handle load, ArgoCD rolls back. Therefore, we recommend selfHeal: true only with a well-configured HPA that respects git configuration.
spec: syncPolicy: automated: prune: true # delete resources not in git selfHeal: true # roll back manual changes syncOptions: - CreateNamespace=true prune: true is another important option. Without it, resources removed from git continue to live in the cluster. Use with caution: if you accidentally delete a CRD from the repository, ArgoCD will delete all instances of that resource. Synchronization with cascading deletion requires review.
Which is Safer: Sealed Secrets or External Secrets Operator?
Sealed Secrets encrypts a Secret with a public key of the cluster using kubeseal. The encrypted SealedSecret can be committed to git. Inside the cluster, the controller decrypts it with a private key.
kubectl create secret generic db-password \ --from-literal=password=supersecret \ --dry-run=client -o yaml | \ kubeseal --controller-namespace kube-system \ --format yaml > db-password-sealed.yaml Issue: dependency on the cluster key. When recreating the cluster, all Sealed Secrets must be reissued. We recommend backing up keys:
kubectl get secret -n kube-system \ -l sealedsecrets.bitnami.com/sealed-secrets-key \ -o yaml > sealed-secrets-key-backup.yaml External Secrets Operator (ESO) does not store secrets in git but references an external store (Vault, AWS Secrets Manager, GCP Secret Manager). ESO creates a Secret in the cluster by synchronizing it from the source. More complex setup, but better for centralized management and rotation. For most clients, we choose ESO — it provides independence from the cluster and flexibility.
Turnkey GitOps Implementation Process
- Infrastructure audit — inventory of clusters, services, CI/CD, secrets. Identify configuration drift, unused resources, vulnerabilities.
- GitOps architecture design — tool selection (ArgoCD/Flux), repository structure (mono- or multi-repo), multi-cluster scheme, RBAC and NetworkPolicy policies.
- Controller deployment — install ArgoCD or Flux, configure HA, integrate SSO, backup configuration.
- Service migration — move configurations to GitOps repository, gradually switch from manual deployments. For each service, a separate Application or Kustomization.
- Secret configuration — implement Sealed Secrets or ESO, generate keys, configure rotation.
- Drift Detection testing — verify
selfHealon a test cluster, practice scenarios. - Go-live — document processes, train the team, hand over runbook. After completion, we guarantee a reduction in MTTR from 4 hours to 45 minutes.
What's Included
- Fully configured GitOps cluster (ArgoCD/Flux) with CI/CD integration
- GitOps repository structure with Kustomize overlays for environments
- Drift Detection policy with
selfHeal(upon agreement) - Secret management solution (Sealed Secrets or ESO)
- Runbook for on-call engineers and process documentation
- Team training (1-day workshop)
- 3-month warranty on settings with support
Estimated Timelines and Savings
| Task | Duration |
|---|---|
| Audit and design | 2-3 days |
| ArgoCD/Flux installation | 1-2 days |
| Migration of one service | 2-3 days |
| Sealed Secrets or ESO setup | 1-2 days |
| Full migration (5-10 services) | 2-4 weeks |
| Multi-cluster (2+ clusters) | +1-2 weeks |
Pricing is calculated individually after an audit. Average annual savings from GitOps implementation can be substantial due to reduced incidents and faster deployments. Additionally, this approach saves 120 man-hours per month by automating routine operations.
Common GitOps Mistakes and How to Avoid Them
- One application, one Application. Do not try to fit the entire infrastructure into a single
Application. Synchronization slows down, RBAC fails. Break it down into logical units. - Helm + ArgoCD without migration. If a Helm release already exists, you cannot simply attach ArgoCD — conflicts will arise. Use
helm uninstallorargocd app createwith adoption flags. - CRD creation order. CRD and its instances in the same
Applicationis an error. Use sync waves:argocd.argoproj.io/sync-wave: "-1"for CRD,"0"for resources. - Lack of Sealed Secrets key backup. During disaster recovery, secrets become unavailable. Backup is mandatory.
The GitOps methodology is well-documented, and its implementation in Kubernetes is covered in official resources. Order turnkey GitOps implementation — we'll assess your project and prepare a migration plan in 2 days. Get a consultation from a certified engineer.







