GitOps

The entire system state—from infrastructure provisioning to application configuration—is defined declaratively as code stored in Git. Instead of imperative scripts that detail how to reach a state, declarative manifests specify what the final state should be.

• Kubernetes YAML manifests define deployments, services, and ingress rules
• Terraform HCL files declare cloud infrastructure resources
• Helm charts template and parameterize complex application stacks

The Git repository becomes the immutable record of intent. Every change to the system begins as a pull request against these declarative files, enabling full auditability and version control of infrastructure decisions.

A software agent running inside the target cluster continuously polls the desired state from Git and compares it against the actual running state. When drift is detected, the agent automatically corrects the cluster to match the declared configuration.

• Flux and Argo CD are the dominant reconciliation agents
• The loop runs every 30-180 seconds by default, configurable per application
• Self-healing: if someone manually patches a deployment, the agent reverts it

This closed-loop control eliminates configuration drift and ensures that the live environment is always a faithful reflection of the Git repository, not the result of ad-hoc kubectl commands.

Unlike traditional CI/CD push pipelines that inject changes into an environment, GitOps uses a pull-based architecture. The reconciliation agent running inside the cluster pulls the desired state from Git and applies it locally.

• Eliminates the need to expose cluster credentials to external CI systems
• The cluster initiates all connections outward to the Git repository
• Works natively in air-gapped environments by pointing agents at local Git mirrors

This inversion of control dramatically improves security posture. No external system requires direct cluster-admin access, and all deployment actions are initiated from within the trusted boundary.

Because every state change originates as a Git commit, the repository history provides a complete audit trail of who changed what, when, and why. This transforms infrastructure management into a reviewable, reversible process.

• git log reveals the full timeline of configuration changes
• Pull request reviews enforce governance before changes merge
• git revert provides instant rollback to any previous known-good state
• Commit SHAs serve as immutable version identifiers for deployments

This Git-centric observability eliminates the "who ran what script" mystery that plagues imperative infrastructure management, making compliance audits straightforward and disaster recovery deterministic.

Reconciliation agents don't just correct drift—they detect and report it. When the actual cluster state diverges from the Git-declared state, the agent surfaces the discrepancy before taking corrective action.

• Argo CD provides a visual diff of out-of-sync resources
• Alerts can be routed to Slack, PagerDuty, or webhook endpoints
• Drift windows reveal unauthorized manual interventions
• Sync policies can be configured for manual approval or automatic correction

This visibility layer acts as a continuous compliance monitor, catching both accidental misconfigurations and potential security incidents where an attacker modifies running workloads outside the approved Git workflow.

GitOps enforces a clean boundary between build and deploy stages. CI pipelines build and test artifacts, but they never directly deploy. Deployment is the sole responsibility of the reconciliation agent.

• CI pipeline: builds container images, runs tests, pushes to registry
• Config repository: holds deployment manifests, updated via separate PR
• Reconciliation agent: watches config repo, applies changes to cluster

This separation prevents CI system compromise from granting cluster access. An attacker who breaches the CI pipeline can push malicious images but cannot deploy them without a separate merge into the config repository—which requires code review approval.

The practice of defining the desired state of a system rather than the sequence of commands to achieve it. In GitOps, every Kubernetes object—from Deployments to Custom Resources—is expressed as a YAML or JSON manifest. The system's reconciliation loop continuously compares the actual state against this declaration, correcting any drift automatically. This eliminates configuration snowflakes and ensures infrastructure is idempotent and auditable.

A control loop that continuously observes the actual state of a cluster, fetches the desired state from a Git repository, and applies corrective actions to eliminate drift. Tools like Argo CD and Flux implement this pattern, polling Git every few minutes or reacting to webhook events. The loop is self-healing: if a manual kubectl command deletes a resource, the controller automatically recreates it to match the declared state in Git.

Unlike traditional CI/CD push models, GitOps agents operate on a pull-based architecture. The controller runs inside the target cluster and actively pulls configuration updates from Git. This inverts the security model: - No external CI access to production clusters - No exposed cluster credentials in CI pipelines - Cluster-initiated connections simplify air-gapped deployments This pattern is critical for disconnected environments where ingress traffic is strictly controlled.

The mechanism by which GitOps operators identify divergence between the desired state in Git and the actual state running in the cluster. Drift can occur from manual emergency fixes, operator mutations, or resource contention. Tools like Argo CD provide visual diffing and can be configured to: - Auto-sync: Automatically revert drift - Alert-only: Notify operators without action - Prune: Remove resources deleted from Git This ensures immutable infrastructure discipline.

A native Kubernetes configuration management tool that enables declarative overlays without templating. Kustomize applies patches, appends labels, and modifies resource names across base manifests for different environments. In GitOps workflows, it allows a single base configuration to be variabilized for dev, staging, and production clusters through kustomization.yaml files. Unlike Helm, Kustomize operates purely on YAML without a server-side component, making it ideal for air-gapped rendering.