GitOps Kubernetes: Declarative Ops for Modern Infrastructure

August 22, 2026

GitOps is an operational framework that leverages Git repositories as the single source of truth for declarative infrastructure and applications. It ensures that the actual state of your Kubernetes infrastructure continuously matches the desired state defined in Git through automated processes. This approach provides auditable, repeatable, and safe infrastructure management, accelerating delivery and improving reliability.

Understanding GitOps Principles with Kubernetes

GitOps builds on established DevOps principles by adding specific practices around version control, declarative configuration, and automated reconciliation. The core idea is that if you want to know what your infrastructure looks like, you look at Git, and if you want to change it, you change Git.

Core Components of GitOps

GitOps relies on three core pieces:

Git repositories: Store the desired configuration, often via Infrastructure as Code (IaC) manifest files.
Human-driven changes: Desired state changes are made through pull requests or merge requests with reviews.
Automated reconciliation: Automation continuously reconciles the actual state to match Git using a controller or operator.

This continuous reconciliation loop is crucial for detecting and correcting drift, ensuring the system converges back to the state declared in Git.

GitOps vs. Traditional CI/CD

GitOps differs from traditional CI/CD pipelines by treating infrastructure state as a versioned artifact in a repository, reviewed via pull requests, and applied automatically by a reconciliation system. This model provides properties that traditional push-based deployment pipelines cannot guarantee on their own, such as continuous drift control.

Feature	GitOps	Traditional CI/CD
Source of Truth	Git repository	CI/CD pipeline configuration
Deployment Trigger	Git commit	Manual trigger, code push
State Management	Declarative, reconciled	Imperative, pushed
Drift Correction	Continuous, automatic	Manual intervention
Auditability	Full Git history	Pipeline logs

GitOps for Edge and IoT Infrastructure

GitOps is particularly beneficial for managing edge and IoT infrastructure due to the unique challenges these environments present.

Challenges at the Edge

Edge environments often face several constraints:

Limited resources: Edge nodes may have 2-8 GB of RAM and 2-4 CPU cores.
Intermittent connectivity: Network links to central sites can be unreliable.
Large fleet: Managing hundreds or thousands of edge sites.
Limited physical access: Difficult to SSH in and fix issues manually.
Diverse hardware: ARM, x86, and various storage options.

Hub-Spoke Architecture for Edge GitOps

A common and effective approach for edge deployments is a hub-spoke GitOps architecture. In this model, a central GitOps controller (like Argo CD) manages configurations for multiple lightweight Kubernetes clusters at the edge.

Lightweight Kubernetes: Use distributions like K3s on spokes to accommodate the edge footprint for controllers and workloads. K3s is a popular choice for Argo CD-managed edge deployments.
Declarative registration: Register spokes declaratively (e.g., Argo CD cluster secrets) to avoid reliance on brittle one-off connectivity.
Edge constraints in overlays: Encode resource limits, replica counts, buffering behavior, and per-architecture images in overlays.
Staged rollouts: Stage changes by rollout-group labels and promote by Git commits/overlay inputs, allowing validation before full fleet rollout.

Lightweight Kubernetes Distributions for Edge

Distribution	Memory Usage	Best For
K3s	~512MB	General edge, IoT gateways
MicroK8s	~540MB	Ubuntu-based edge devices
K0s	~500MB	Minimal, single-binary
KubeEdge	Varies	Very constrained devices

K3s is the most popular choice for ArgoCD-managed edge deployments.

Secrets Management in GitOps Kubernetes

A critical aspect of GitOps is managing secrets securely, as Git history is durable and reviewable, while secret material must remain confidential. Plaintext secrets in Git create credential leaks.

Secure Secret Handling Patterns

References to external stores: Store references (like a Secret name or external secret path) in Git, while the actual secret value lives elsewhere (e.g., Vault, AWS Secrets Manager, GCP Secret Manager). A controller then fetches or decrypts the value at deploy time to create a Kubernetes Secret object. External Secrets Operator (ESO) is a tool for this pattern.
Encrypted secrets in Git: Encrypt secret values into a custom resource (e.g., SealedSecret) and commit the encrypted blob to Git. A controller in the cluster decrypts it at deploy time and writes the resulting Kubernetes Secret object. Sealed Secrets and SOPS are examples of tools for this.

These methods ensure that plaintext secrets never live unencrypted in the repository.

Observability and Monitoring in GitOps

Observability in GitOps must cover the control loop itself across every cluster, not just application metrics. This allows you to track why reconciliation might fail or why drift persists.

Key Metrics to Monitor

Sync status: Indicates whether the desired state from Git has been applied.
Health status: Reflects the health of the reconciled resources.
Reconciliation latency: Measures the time it takes for changes to converge.

Tools like Argo CD expose Prometheus metrics for application sync status, health status, and reconciliation latency. Flux exposes per-controller reconciliation duration and error counts. These metrics can be used to build Grafana dashboards and alert on sync failures and health degradations.

Common Pitfalls and Best Practices

Adopting GitOps with Kubernetes requires addressing common pitfalls to ensure effective and secure operations.

Pitfalls and Solutions

Pitfall	How to Handle It
Storing plaintext secrets in Git	Use External Secrets Operator, Sealed Secrets, or SOPS
No pull request gate on production	Require PR review for production overlay changes; use branch protection rules
Reconciler in sync-only mode with no drift alerts	Enable Prometheus metrics and alert on sync failures and health degradations
Mixing imperative `kubectl` commands with GitOps	Establish a team norm: all changes go through Git; direct `kubectl` access to production is break-glass only
Single large repo with no clear directory ownership	Define directory ownership with `CODEOWNERS` files

Local Data Persistence for Edge

For edge fleets, local data persistence is crucial to prevent data loss during disconnections or restarts. Kubernetes PersistentVolumes provide a mechanism for applications to store data locally, ensuring that write-ahead logs, message buffers, device identity caches, or edge-local indexes survive outages.

Frequently Asked Questions

What is GitOps in the context of Kubernetes?

GitOps is an operational framework that uses Git as the single source of truth for defining the desired state of Kubernetes clusters and applications. An automated reconciliation agent continuously compares the cluster's actual state with the Git-declared state and applies changes to converge them.

Why is GitOps beneficial for Kubernetes deployments?

GitOps provides auditable, repeatable, and safe infrastructure management by leveraging Git's version control capabilities. It automates deployments, corrects configuration drift, and improves reliability and delivery speed for Kubernetes applications.

How does GitOps handle secrets in Kubernetes?

GitOps avoids storing plaintext secrets directly in Git. Instead, it uses tools like External Secrets Operator, Sealed Secrets, or SOPS to either reference external secret stores or encrypt secrets within Git, which are then decrypted by a controller at deploy time.

What are the key components of a GitOps architecture for Kubernetes?

A GitOps architecture for Kubernetes typically involves Git repositories for declarative configuration, a reconciliation agent (like Argo CD or Flux) running in the cluster, and a pull request-based workflow for managing changes.

What are the challenges of implementing GitOps for edge Kubernetes environments?

Edge environments present challenges such as limited resources, intermittent connectivity, large fleet sizes, limited physical access, and diverse hardware. GitOps addresses these with lightweight Kubernetes distributions, hub-spoke architectures, and robust observability.

What is the mental model shift required for successful GitOps adoption?

The mental model shift is to stop thinking "GitOps deploys now" and start thinking "GitOps converges over time." This acknowledges that convergence, especially at the edge, happens across unreliable links and requires architectures that tolerate temporary divergence while guaranteeing eventual alignment.

Conclusion

GitOps, by making Git the single source of truth for Kubernetes configurations, provides a robust and auditable framework for managing infrastructure and applications. It automates the reconciliation of desired and actual states, significantly improving reliability and accelerating software delivery. For complex environments like edge and IoT, GitOps, combined with lightweight Kubernetes and secure secret management, offers a powerful solution to overcome unique operational challenges. Embracing GitOps principles and best practices is essential for modern organizations seeking to optimize their Kubernetes deployments.

Sources & References

Want to actually learn gitops kubernetes?

Curo turns topics like this into a personalized, guided learning board - built around what you already know. Free to start.

Try Curo