GitOps 101: Managing Kubernetes Deployments with Argo CD and Flux

What Is GitOps?

GitOps is an operational approach that uses Git repositories as the source of truth for infrastructure and application configuration.

In a traditional Kubernetes workflow, an engineer may manually execute commands such as:

kubectl apply -f deployment.yaml

This can work for small environments but becomes harder to manage when multiple applications and Kubernetes clusters are involved.

With GitOps, Kubernetes configuration is stored in Git. When a deployment change is required, the configuration is updated through Git. A GitOps controller detects the change and works to make the Kubernetes cluster match the desired configuration.

The basic workflow is:

Developer → Git Repository → GitOps Controller → Kubernetes

Key GitOps Principles

GitOps is built around several important principles:

• Declarative configuration: Define the desired state rather than manual deployment steps.

• Git as the source of truth: Store configuration and deployment definitions in version control.

• Automated synchronization: Automatically apply approved configuration changes.

• Continuous reconciliation: Detects differences between the desired and actual cluster state.

These principles make Kubernetes deployments more repeatable and auditable.

How GitOps Works with Kubernetes

A Git repository, GitOps controller, and Kubernetes cluster are typical components of a Kubernetes GitOps design.

Kubernetes manifests, Helm charts, Kustomize setups, and other deployment definitions may be found in the Git repository.

For example:

kubernetes-config/

├── applications/

│   ├── frontend/

│   ├── backend/

│   └── api/

├── environments/

│   ├── development/

│   ├── staging/

│   └── production/

└── infrastructure/

The GitOps controller keeps an eye on the repository and contrasts the intended setup with the real Kubernetes environment.

The controller can reconcile the cluster with the configuration kept in Git if a discrepancy is found.

Deployment systems no longer need to explicitly push commands into Kubernetes thanks to this pull-based method.

What Is an Argo CD?

Argo CD is a declarative GitOps continuous delivery platform designed specifically for Kubernetes.

It monitors Git repositories and compares the desired application state with the actual state running in Kubernetes.

The basic workflow is:

Git Repository → Argo CD → Kubernetes

Helm charts, Kustomize setups, and Kubernetes manifests are all supported by Argo CD.

Application synchronization is one of its main features. For instance, even though the cluster now has three replicas, Git might demand five. Argo CD is able to recognize the difference and adjust the cluster to the intended condition.

Additionally, teams can check application health, synchronization status, resources, and configuration variances using the web-based interface that Argo CD offers.

Teams overseeing numerous applications and Kubernetes clusters may find this especially helpful.

What Is Flux?

Flux is a Kubernetes-native GitOps toolkit that uses controllers to synchronize Kubernetes resources with configuration stored in Git.

Flux adheres to the GitOps paradigm of continuous reconciliation and declarative configuration.

Because Kubernetes controllers form the foundation of its architecture, it is tightly connected with Kubernetes resources and APIs.

Git repositories, Helm deployments, and Kustomize processes are all supported by Flux. 

For example, an application may use:

myapp:v1.4

When a newer image becomes available, Flux can be configured to update the deployment configuration according to the organization’s image automation policy.

Argo CD vs Flux

Both Argo CD and Flux support Kubernetes GitOps, but their approaches differ.

The choice depends on the organization’s architecture, team experience, existing DevOps tools, and operational requirements.

How GitOps Automates Kubernetes Deployments

A typical GitOps workflow can connect application development, CI/CD, Git, and Kubernetes.

Step 1: Develop and Test

A developer changes application code and creates a pull request.

Step 2: Build the Container

The CI pipeline builds and tests the application and creates a container image.

Step 3: Update Deployment Configuration

The Kubernetes configuration is updated to reference the new image:

spec:

  containers:

    – name: web

      image: registry.example.com/web:v2.1

Step 4: Commit Changes to Git

The configuration change is reviewed and merged into the appropriate Git branch.

Step 5: GitOps Controller Detects the Change

Argo CD or Flux detects the updated configuration.

Step 6: Kubernetes Is Reconciled

The controller synchronizes the Kubernetes cluster with the desired configuration.

The complete workflow becomes:

Developer → CI → Container Registry → Git → Argo CD/Flux → Kubernetes

This separates application build and testing from Kubernetes deployment management.

Benefits of GitOps for Kubernetes

Better Auditability

Git records configuration changes through commits and pull requests, making deployment history easier to review.

Consistent Deployments

Declarative configuration helps teams maintain consistent environments across development, staging, and production.

Easier Rollbacks

If a deployment introduces an issue, teams can revert the Git change and restore a previous configuration.

Reduced Manual Operations

GitOps reduces the need for engineers to repeatedly run manual Kubernetes deployment commands.

Configuration Drift Detection

If someone changes Kubernetes resources directly, the cluster can differ from the configuration stored in Git. GitOps controllers can detect this difference and reconcile the environment according to the configured policy.