CI/CD for Kubernetes — GitOps, ArgoCD & Flux

Deploying applications into a Kubernetes cluster using standard CI scripts (kubectl apply from GitHub Actions or GitLab CI) works for small setups, but it creates significant security and reliability issues at scale. Granting your external CI system admin credentials to your production cluster breaks the principle of least privilege. Furthermore, direct push pipelines leave no audit trail of what was modified out-of-band.

Enter GitOps: an operational paradigm where Git repositories act as the declarative single source of truth, and in-cluster agents continuously synchronize your cluster state with Git.

Push vs. Pull Deployment Models

Traditional Push-Based CI/CD

In a push model:

1. Developer pushes code to Git.
2. CI server runs unit tests and builds a Docker image.
3. CI pushes image to a container registry.
4. CI uses stored cluster credentials (kubeconfig) to run kubectl apply directly against the cluster API.

Drawbacks:

• Cluster API must be open to the internet or CI network.
• High-privilege credentials live in CI runners (a prime attack vector).
• Cluster drift: if someone manually modifies a resource via kubectl, Git and the cluster diverge silently.

Pull-Based GitOps Model

In a GitOps pull model:

1. CI pipeline only tests, builds, and publishes container images.
2. CI updates a Git commit containing the new image tag in a dedicated Config / Manifest Repository.
3. A GitOps controller (like ArgoCD or Flux) running inside the cluster polls or receives a webhook from Git.
4. The controller detects drift between Git and live cluster state, pulls changes, and reconciles them.

Advantages:

• Zero inbound network ports opened into the Kubernetes API.
• Cluster credentials never leave the cluster boundaries.
• Instant rollback: reverting a Git commit automatically triggers a cluster rollback.
• Self-healing: if someone edits a live pod or service in cluster, the operator immediately reverts it back to Git state.

---

ArgoCD in Practice

ArgoCD is the most popular GitOps controller in the CNCF landscape. It provides both an intuitive web UI and a declarative CRD-driven architecture.

The Application CRD

In ArgoCD, an Application resource defines the source Git repository and target cluster namespace:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-service
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/myorg/k8s-manifests.git'
    targetRevision: main
    path: apps/payment-service/production
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: payments
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Key features of modern GitOps workflows:

• Sync Waves & Hooks: Order dependencies (e.g., run database migrations before updating the API deployment).
• Argo Rollouts: Replaces the standard K8s deployment controller to enable progressive delivery (Canary with automated analysis via Prometheus metrics).
• Sealed Secrets / External Secrets: Store encrypted secrets safely in Git that can only be decrypted by the cluster private key.

---

Key Takeaways

• Push-based pipelines expose cluster credentials; pull-based GitOps keeps security boundaries intact.
• Git is the single source of truth for all cluster declarations, enabling painless auditing, rollbacks, and team collaboration.
• Tools like ArgoCD and Flux run inside the cluster, watching Git and eliminating manual cluster drift.