GitOps Implementation for Infrastructure Management

GitOps Implementation for Infrastructure Management

We implement GitOps as an operational model where the Git repository becomes the single source of truth for infrastructure and application state. Every change in the cluster goes through a Pull Request. No manual kubectl apply. No terraform apply from a developer's local machine. It sounds simple, but moving from "we deploy via CI" to a true GitOps approach impacts processes, repository architecture, secrets management, and team culture.

Why GitOps Requires a Systematic Approach

The most common mistake is to install ArgoCD or Flux, configure synchronization for one application, and declare "we have GitOps." A month later, you find that some resources are still created manually via kubectl create namespace, secrets are stored in CI variables and applied in pipelines, and Helm values for production are edited directly in the cluster without a commit to git. Drift between the repository and what is actually running accumulates unnoticed.

The second problem is a monolithic repository without a clear structure. When apps/ is mixed with infrastructure/ and overlays/ for different environments are inconsistent, onboarding a new engineer becomes a detective hunt. Kustomize overlays and Helm values must be organized by environment (base/, overlays/dev/, overlays/prod/) from the start, not refactored later.

Secrets management in GitOps is a separate headache. Plaintext secrets cannot be stored in git. Three viable options: Sealed Secrets (encryption via kubeseal, the secret is decrypted only by the controller in the cluster), SOPS with age/GPG (encrypted files in git, decrypted at runtime), External Secrets Operator (secrets live in Vault/AWS SSM/GCP Secret Manager, ESO syncs them as Kubernetes Secrets). The choice depends on whether you already have Vault in the infrastructure and whether you need a unified secrets store for multiple clusters.

How to Choose a GitOps Operator: ArgoCD vs Flux

For most teams, ArgoCD is convenient when visualization and multi-cluster management are needed. Flux is chosen for projects where everything must work through a pipeline without manual intervention.

GitOps Implementation Architecture

A full implementation includes several layers:

Repository strategy. Two main patterns: monorepo (everything in one repository — infrastructure + applications) and polyrepo (separate app repo + separate gitops/config repo). For most teams, the optimal approach is separate app repo and separate GitOps config repo — this separates the lifecycles of code and configuration and eliminates conflicts when multiple teams work simultaneously.

Config repository structure for Kustomize:

gitops-config/
├── apps/
│   ├── base/
│   │   └── myapp/
│   │       ├── deployment.yaml
│   │       ├── service.yaml
│   │       └── kustomization.yaml
│   └── overlays/
│       ├── dev/
│       │   └── kustomization.yaml   # patch resources + replica=1
│       └── prod/
│           └── kustomization.yaml   # patch resources + HPA + PDB
├── infrastructure/
│   ├── cert-manager/
│   ├── ingress-nginx/
│   └── monitoring/
└── clusters/
    ├── dev/
    └── prod/

Choosing a GitOps operator. ArgoCD — richer UI, convenient for multi-cluster, ApplicationSet for generating applications from templates. Flux v2 — more cloud-native, better integration with Helm OCI repositories, suitable for automated workflows without UI. In practice, teams that need visualization choose ArgoCD; Flux is chosen where everything goes through a GitOps pipeline without manual intervention.

CI/CD integration. In GitOps, CI remains for building and testing. CD moves entirely to the GitOps operator. The CI pipeline follows the schema: build → test → push image → update image tag in config repo → ArgoCD/Flux picks up the change and syncs the cluster. Updating the image tag in the config repo can be done via kustomize edit set image or via Argo CD Image Updater / Flux Image Automation.

Example GitHub Actions step to update image tag in config repo:

---
- name: Update image tag in gitops repo
  run: |
    git clone https://github.com/org/gitops-config.git
    cd gitops-config
    kustomize edit set image myapp=registry.example.com/myapp:${{ github.sha }}
    git add .
    git commit -m "ci: update myapp to ${{ github.sha }}"
    git push
  working-directory: apps/overlays/dev
---

Drift Detection and Self-healing

One of the main advantages of GitOps is automatic recovery from manual changes in the cluster. If someone modifies replicas directly via kubectl scale, ArgoCD will detect the drift and, after the configured sync interval (default 3 minutes), restore the state to what is in git. This is called self-healing, and it should be enabled deliberately — not for all resources at once.

Resources that often need to be excluded from auto-sync: HPA (horizontal pod autoscaler changes replicas automatically, conflicting with GitOps sync), PersistentVolumeClaims (modification could lead to data loss), some CRDs with dynamic reconciliation. In ArgoCD, this is configured via ignoreDifferences:

spec: ignoreDifferences: - group: apps kind: Deployment jsonPointers: - /spec/replicas 

Implementation Stages

Implementing GitOps is an iterative process, not a one-time task.

Full cycle from audit to production-ready GitOps takes from 3 weeks for a small stack to 3 months for complex multi-cluster infrastructure with compliance requirements.

What is included in the work

• Audit of current infrastructure and deploy processes
• Design of repository structure (monorepo or polyrepo)
• Setup of GitOps operator (ArgoCD or Flux) with RBAC and multi-tenancy
• Phased migration of applications while maintaining operability
• Implementation of secrets management (Sealed Secrets/SOPS/External Secrets Operator)
• Development of documentation and runbook
• Team training and support during launch phase

Contact us for an infrastructure audit — we will estimate the scope of work and implementation timeline. Our team has over 5 years of successful GitOps transformation projects in companies of various sizes. We guarantee results: 30-50% reduction in deployment time and elimination of manual operations.

Get a consultation on choosing a GitOps operator and repository architecture.