GitOps on Kubernetes: Building a CI/CD Pipeline with Argo CD and Kubernetes Manifests

GitOps on Kubernetes has become the default operating model for teams that want repeatable, auditable, and scalable deployments. Instead of applying changes manually with kubectl, GitOps treats Git as the single source of truth for declarative infrastructure and application configuration. A controller such as Argo CD continuously reconciles what is running in the cluster with what is declared in Git, eliminating configuration drift and reducing the risk of manual deployment mistakes.

This article explains how to build a practical CI/CD workflow using Kubernetes manifests and Argo CD, covering repository structure, automated sync policies, multi-environment promotion, secrets handling, and progressive delivery with Argo Rollouts.

What is GitOps on Kubernetes?

GitOps on Kubernetes is an operational approach built on three principles:

• All desired state is declared in Git using Kubernetes manifests, Kustomize overlays, or Helm charts.

• Git is the change control system, meaning changes flow through pull requests, reviews, and automated checks.

• A reconciler enforces desired state by continuously comparing the cluster state to Git and applying corrections when drift occurs.

GitOps is now widely regarded as an industry standard for Kubernetes delivery. The most significant shift is cultural and procedural: if a change is not in Git, it is not considered real. This improves auditability and supports platform engineering by standardizing how environments are created, updated, and recovered.

Why Argo CD for GitOps?

Argo CD is one of the two dominant GitOps controllers, alongside Flux. Teams typically choose Argo CD when they value a strong user interface, clear application visibility, and a cohesive management experience. Flux is often preferred when teams want composable, Kubernetes-native controllers. Either can implement GitOps effectively, but this guide focuses on Argo CD because of its wide adoption in application-centric GitOps workflows.

Core Argo CD capabilities that matter in production

• Continuous reconciliation to prevent or correct configuration drift.

• Automated sync from Git to cluster, reducing manual deployment steps.

• Pruning to remove resources deleted from Git, keeping clusters clean.

• Self-healing to restore state when resources are changed out of band.

• Progressive delivery integration via Argo Rollouts for canary and blue-green strategies.

Reference Architecture: CI Updates Git, Argo CD Deploys

A well-designed GitOps pipeline separates concerns across two repositories:

• Application code repository: source code, tests, Dockerfile, and build pipeline.

• Kubernetes manifests repository: declarative YAML, Kustomize overlays, and environment configuration.

The deployment flow works as follows:

1. Developers merge changes to the application code repository.

2. CI builds an image and pushes it to a container registry.

3. CI updates the image tag or digest in the Kubernetes manifests repository.

4. Argo CD detects the Git change and reconciles the target cluster and namespace.

This approach avoids granting CI direct deployment permissions to the cluster and produces a clean audit trail. Git history becomes the record of what changed, when, and why.

Recommended Repository Structure for Kubernetes Manifests

A structure based on shared bases and environment overlays scales well across staging and production:

• clusters/ for cluster-specific configuration (staging, production)

• apps/base/ for shared manifests

• apps/overlays/ for environment-specific patches

• infrastructure/ for cluster add-ons such as ingress-nginx and cert-manager

This layout supports both standardization and controlled variation. The base can define Deployments, Services, and NetworkPolicies, while overlays adjust replica counts, resource requests, hostnames, or feature flags per environment.

Creating an Argo CD Application (the Sync Contract)

Argo CD uses an Application custom resource to define what to sync from Git and where to sync it in Kubernetes. A commonly used pattern looks like this:

Example Argo CD Application manifest:

(Shown as inline code for readability)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
source:
    repoURL: https://github.com/myorg/k8s-manifests
    targetRevision: HEAD
    path: apps/my-app/overlays/production
destination:
    server: https://kubernetes.default.svc
    namespace: my-app-prod
syncPolicy:
    automated:
      prune: true
      selfHeal: true

With automated sync enabled, Argo CD can be configured with operational safeguards such as retry limits (for example, five attempts with exponential backoff) and optimization flags that apply only out-of-sync resources. These options help when clusters experience transient failures such as API throttling or webhook timeouts.

End-to-End CI/CD Flow

Step 1: Build, test, and publish an immutable artifact

CI should produce a container image that is uniquely identifiable. Many teams prefer an image digest or a tag derived from the commit SHA. This supports traceability and simplifies rollbacks.

Step 2: Update Kubernetes manifests via pull request

After publishing the image, CI updates the manifests repository. Common approaches include:

• Updating a Kustomize images section in the environment overlay.

• Updating a Helm values file when deploying via Helm.

• Pinning an image digest for stronger supply chain guarantees.

A pull request workflow ensures that promotion to production requires review and policy checks. It also supports separation of duties, where developers propose changes while platform teams control approvals.

Step 3: Argo CD reconciles the cluster

Once the manifest change is merged, Argo CD detects the new commit and syncs the declared state into the destination namespace. If someone modifies a live resource manually, the self-heal feature reverts it to the Git-defined state automatically.

Progressive Delivery with Argo Rollouts

Basic rolling updates are often insufficient for high-impact services. GitOps pipelines increasingly include progressive delivery as standard practice, using Argo Rollouts for controlled releases.

Canary deployments with metrics-based promotion

A typical canary strategy follows these steps:

1. Shift 10% of traffic to the new version.

2. Pause and evaluate application metrics.

3. Promote to 100% if the success rate exceeds a defined threshold such as 95%.

4. Automatically roll back if analysis fails.

Argo Rollouts integrates with service meshes such as Istio for traffic splitting using VirtualService objects. This gives fine-grained control over how traffic moves between versions without changing client behavior.

Secrets Management in a GitOps Workflow

Storing secrets in Git is a common concern with GitOps. The recommended approach is to keep references in Git and fetch secret values at deploy time from an external system. Two widely used patterns are:

• External Secrets Operator to sync secrets from providers such as AWS Secrets Manager, Google Secret Manager, or HashiCorp Vault.

• SOPS-based encryption, where encrypted secret manifests live in Git and are decrypted during sync using a tool such as KSOPS.

Both patterns preserve the GitOps principle without committing plaintext secrets. They also align with zero-trust security practices by limiting which systems can retrieve sensitive values.

Bootstrap and Scaling Patterns: App of Apps

As clusters grow, teams standardize cluster bootstrapping with an App of Apps pattern. One Argo CD Application points to a directory that defines other Applications, enabling ordered installation across layers:

• Infrastructure add-ons first (ingress-nginx, cert-manager, external secrets)

• Platform services next (observability stack, policy controllers)

• Product applications last

This pattern is common in environments with separate staging and production clusters, or separate Git repositories per environment to enforce stricter controls on production changes.

Policy, Auditability, and Operational Benefits

GitOps on Kubernetes improves governance because the deployment pathway becomes consistent and reviewable. Teams commonly add:

• Admission policies with OPA Gatekeeper to prevent non-compliant resources from reaching the cluster.

• Pull request checks for schema validation, security scanning, and best-practice linting.

• Reduced direct cluster access, since changes flow through Git and the controller applies them.

The operational benefit is consistent across organizations: fewer drift-related incidents and clearer audit trails, which becomes increasingly important as Kubernetes estates scale across multiple teams and environments.

Skill-Building and Certification Pathways

Implementing GitOps on Kubernetes in a production environment requires solid grounding in Kubernetes operations, container security, and CI/CD fundamentals. Relevant Blockchain Council learning paths include:

• Kubernetes certifications and hands-on training covering cluster operations and workload management

• DevOps and CI/CD focused programs to standardize pipelines and release governance

• Cybersecurity certifications that address policy enforcement, secrets management, and zero-trust controls

Conclusion

GitOps on Kubernetes is a proven approach for running Kubernetes with consistency, auditability, and reduced operational overhead. By separating application code from Kubernetes manifests, letting CI update Git, and relying on Argo CD for continuous reconciliation, teams eliminate configuration drift and remove manual deployment steps. Adding Argo Rollouts introduces progressive delivery that is safer than basic rolling updates, and modern secrets patterns keep sensitive data out of Git while preserving declarative workflows.

For Kubernetes environments that need to scale with organizational growth, the guiding principle is straightforward: make Git the source of truth, and let controllers ensure the cluster matches it.