GitOps vs Traditional CI/CD: Why Argo CD Changes Kubernetes Delivery

For years, the standard deployment model was simple: a CI/CD pipeline builds the application, runs tests, authenticates to the target environment, and pushes changes directly into Kubernetes. This works, but at scale it creates operational pain: too many pipelines with cluster credentials, inconsistent deployment logic, weak auditability, and unclear ownership of the real production state.

GitOps changes the model. Instead of asking the pipeline to push changes into the cluster, we declare the desired state in Git and let a controller inside Kubernetes reconcile the cluster toward that state. In practice, this means Git becomes the source of truth, Kubernetes becomes the runtime, and tools like Argo CD become the continuous delivery control plane.

Traditional CI/CD: Push-Based Delivery

In a traditional pipeline, GitLab CI usually performs most of the deployment work:

Developer push
    ↓
GitLab CI
    ↓
Build image
    ↓
Run tests
    ↓
helm upgrade --install
    ↓
GKE cluster

This model is familiar and powerful, but it couples build automation with runtime operations. The pipeline needs access to the cluster. Rollbacks depend on pipeline logic. Drift detection is usually external or missing. If someone changes a Kubernetes object manually, the pipeline may not notice until the next deployment.

The biggest pain point before GitOps is not that CI/CD is broken. It is that CI/CD becomes the owner of too many responsibilities: building, testing, deploying, securing credentials, managing environment differences, and sometimes even deciding what production should look like.

GitOps: Pull-Based Continuous Delivery

With GitOps, the CI pipeline still exists, but its role becomes narrower. GitLab CI builds the container image, runs tests, scans it, and updates a Git repository that contains the deployment configuration. Argo CD watches that repository and applies the declared state to GKE.

Developer push
    ↓
GitLab CI
    ↓
Build, test, scan, publish image
    ↓
Update Helm values in Git
    ↓
Argo CD detects change
    ↓
Argo CD syncs GKE cluster

This separation is the key architectural shift. CI produces artifacts. Git stores desired state. Argo CD reconciles Kubernetes. The deployment path becomes more auditable because every production change is represented as a Git commit.

Where Argo CD Fits

Argo CD is a GitOps continuous delivery tool for Kubernetes. It watches one or more Git repositories and compares the desired state in Git with the actual state running in Kubernetes. If the two differ, the application becomes OutOfSync. Depending on policy, Argo CD can either show the drift for manual approval or automatically sync the cluster.

In a GKE environment, Argo CD usually runs inside the cluster or in a dedicated management cluster. It connects to Git repositories, renders Helm charts or Kubernetes manifests, and applies them to the target cluster.

Core Argo CD Concepts

Repositories

A repository is where the desired state lives. This can be a Helm chart repository, a Git repository with raw Kubernetes YAML, or a Git repository containing Helm values.

gitops-repo/
  apps/
    payments/
      Chart.yaml
      values-dev.yaml
      values-prod.yaml
  platform/
    ingress/
    monitoring/
    external-secrets/

For senior platform teams, the important design question is repository ownership. Application teams may own application values, while the platform team owns cluster-wide components such as ingress controllers, External Secrets, Prometheus, Grafana, and policy configuration.

Applications

An Argo CD Application maps a source in Git to a destination in Kubernetes.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payments-prod
  namespace: argocd
spec:
  project: payments
  source:
    repoURL: https://gitlab.example.com/platform/gitops.git
    targetRevision: main
    path: apps/payments
    helm:
      valueFiles:
        - values-prod.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: payments
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

This object says: “For the payments production application, take the desired state from this Git path, render it with Helm, and apply it to the payments namespace.”

Projects

Projects are an important multi-tenant boundary. They define which repositories, clusters, namespaces, and resource kinds an application is allowed to use.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: payments
  namespace: argocd
spec:
  sourceRepos:
    - https://gitlab.example.com/platform/gitops.git
  destinations:
    - namespace: payments
      server: https://kubernetes.default.svc

For platform engineering teams, Projects are where GitOps starts to become governance. They prevent every team from deploying everywhere with unlimited permissions.

Real-World Example on GKE

Imagine a team deploying a payments API to GKE. Before GitOps, GitLab CI had direct access to the cluster and executed Helm commands. Every environment had slightly different deployment scripts. When production drift happened, engineers had to inspect the cluster manually and compare it with Helm values.

With GitOps, the flow becomes cleaner:

1. GitLab CI builds the Docker image.
2. The image is pushed to the registry.
3. CI updates the image tag in the GitOps repository.
4. Argo CD detects the Git change.
5. Argo CD syncs the Helm release to GKE.
6. Prometheus and Grafana observe the result.
7. Argo Rollouts can progressively shift traffic using canary or blue-green deployment strategies.

image:
  repository: registry.example.com/payments-api
  tag: "1.8.4"

Instead of asking “What did the pipeline deploy?”, the team asks “What commit describes production?” That is a much better operational question.

Secrets and Progressive Delivery

GitOps does not mean storing plaintext secrets in Git. For Kubernetes workloads, tools such as Sealed Secrets or External Secrets are usually used. Sealed Secrets allows encrypted secret manifests to live safely in Git. External Secrets integrates Kubernetes with external secret stores such as Google Secret Manager.

For safer releases, Argo CD can be combined with Argo Rollouts. Argo CD handles synchronization of desired state, while Argo Rollouts handles progressive delivery behavior such as canary releases, traffic shifting, and automated promotion or rollback based on metrics.

Diagram Explained in Text

[CI Layer]
GitLab CI → build/test/scan/push image

[State Layer]
Git repository → Helm charts, values, Kubernetes manifests

[Runtime Layer]
Argo CD → GKE → workloads, services, ingress, secrets, monitoring

The important detail is the direction of control. GitLab CI does not push directly into GKE. Argo CD pulls from Git and reconciles the cluster. This reduces external cluster credentials and makes Git the audit trail for runtime change.

Best Practices

• Keep CI and CD responsibilities separate: CI should build and validate; Argo CD should deploy and reconcile.
• Use Projects for tenancy: restrict repositories, namespaces, clusters, and permissions.
• Avoid manual cluster changes: emergency fixes should be committed back to Git quickly.
• Use Helm carefully: keep values explicit, reviewed, and environment-specific.
• Protect secrets: use Sealed Secrets or External Secrets, never plaintext Kubernetes secrets in Git.
• Observe deployments: connect Prometheus and Grafana to release health, not just infrastructure metrics.
• Adopt progressive delivery: use Argo Rollouts for high-risk services instead of relying only on rolling updates.
• Start with manual sync: move to auto-sync only when ownership, alerts, and rollback processes are mature.

Conclusion

Traditional CI/CD is still valuable, but it should not be the only source of deployment truth. For Kubernetes platforms, GitOps provides a cleaner operating model: Git defines the desired state, Argo CD reconciles that state, and the cluster becomes continuously auditable.

The real value of GitOps is not just automation. It is operational clarity. When production is described in Git, reviewed through merge requests, reconciled by Argo CD, and observed through Prometheus and Grafana, platform teams gain a more reliable and controlled deployment model.

For GKE-based platforms, Argo CD is not just another deployment tool. It is a control plane for Kubernetes delivery.