Implementing GitOps: Automation and Infrastructure Management

GitOps implementation: ArgoCD, Flux, GitOps repository structure, Kubernetes cluster synchronization, drift detection, and automatic rollback.

Our competencies:

Frequently Asked Questions

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1359
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1330
  • B2B Advance company logo design
    B2B Advance company logo design
    776
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1077
  • AIDER company logo development
    AIDER company logo development
    1022
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1112

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

  1. Infrastructure audit — inventory of clusters, services, CI/CD, secrets. Identify configuration drift, unused resources, vulnerabilities.
  2. GitOps architecture design — tool selection (ArgoCD/Flux), repository structure (mono- or multi-repo), multi-cluster scheme, RBAC and NetworkPolicy policies.
  3. Controller deployment — install ArgoCD or Flux, configure HA, integrate SSO, backup configuration.
  4. Service migration — move configurations to GitOps repository, gradually switch from manual deployments. For each service, a separate Application or Kustomization.
  5. Secret configuration — implement Sealed Secrets or ESO, generate keys, configure rotation.
  6. Drift Detection testing — verify selfHeal on a test cluster, practice scenarios.
  7. 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 uninstall or argocd app create with adoption flags.
  • CRD creation order. CRD and its instances in the same Application is 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.