CI/CD with Kubernetes

Kubernetes is the dominant container orchestration platform — the system that runs containers at scale, manages their lifecycle, handles traffic routing, restarts failed instances, and rolls out new versions without downtime. For CI/CD, Kubernetes is the deployment target: the pipeline builds a Docker image, pushes it to a registry, and then instructs Kubernetes to run the new image across the cluster. How that instruction is given — through direct kubectl commands, through Helm chart releases, or through a GitOps operator like Argo CD — determines the deployment model's auditability, rollback capability, and operational complexity.

Three Deployment Models for Kubernetes

There is no single correct way to deploy to Kubernetes from a CI/CD pipeline. Three models are in common use, each with a different trade-off between simplicity, flexibility, and operational maturity.

Direct kubectl Deployment — The Simplest Starting Point

For teams just getting started with Kubernetes deployments, kubectl apply from the pipeline is the most straightforward approach. The pipeline authenticates to the cluster using a kubeconfig stored as a GitHub Secret or via OIDC, then applies manifests or patches the image tag on an existing deployment.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      contents: read
      id-token: write                    # For OIDC auth to cloud provider

    steps:
      - uses: actions/checkout@v4

      - name: Authenticate to GKE via OIDC
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.GCP_WIF_PROVIDER }}
          service_account: ${{ secrets.GCP_SERVICE_ACCOUNT }}

      - name: Get cluster credentials
        uses: google-github-actions/get-gke-credentials@v2
        with:
          cluster_name: prod-cluster
          location: europe-west1

      - name: Update image tag in deployment
        run: |
          kubectl set image deployment/api \
            api=ghcr.io/myorg/api:${{ github.sha }} \
            --namespace production

      - name: Wait for rollout to complete
        run: |
          kubectl rollout status deployment/api \
            --namespace production \
            --timeout=300s              # Fail pipeline if rollout takes more than 5 minutes

Helm — Templated Releases with Rollback

Helm is the Kubernetes package manager. A Helm chart defines all the Kubernetes resources an application needs — Deployment, Service, Ingress, ConfigMap, HorizontalPodAutoscaler — as templated YAML files. Values are injected at install or upgrade time from a values file or command-line overrides. The same chart deploys to staging with values-staging.yaml and to production with values-production.yaml, with the image tag passed as a parameter.

Helm tracks every release as a versioned history entry in the cluster. helm rollback my-app 3 rolls back to release revision 3 in seconds — no pipeline run required, no Git revert needed. For teams managing multiple services and environments, Helm's release management, values hierarchy, and rollback capability make it significantly more maintainable than raw kubectl apply at scale.

GitOps with Argo CD — The Operator Model

GitOps inverts the deployment model. Instead of the pipeline pushing changes to the cluster, an operator inside the cluster pulls changes from a Git repository. Argo CD watches a Git repository containing Kubernetes manifests or Helm charts. When the repository changes — because the CI pipeline updated the image tag in a values file — Argo CD detects the diff between the declared state in Git and the actual state in the cluster, and automatically applies the change.

The pipeline's role in a GitOps workflow changes significantly. Instead of authenticating to the cluster and running kubectl or helm commands directly, the pipeline updates the image tag in the Git repository and commits the change. Argo CD handles the rest. This means the pipeline never needs cluster credentials — a major security improvement. Every cluster change is traceable to a Git commit. Drift between the declared and actual state is detected and corrected automatically. Manual changes to the cluster are reverted unless they are first committed to Git.

jobs:
  update-gitops-repo:
    runs-on: ubuntu-latest
    needs: build-and-push            # Runs after the Docker image is built and pushed

    steps:
      - name: Check out the GitOps config repository
        uses: actions/checkout@v4
        with:
          repository: myorg/gitops-config    # Separate repo holding cluster state
          token: ${{ secrets.GITOPS_PAT }}   # PAT with write access to config repo

      - name: Update image tag in values file
        run: |
          # Replace the image tag in the production values file
          sed -i "s|tag:.*|tag: ${{ github.sha }}|" \
            apps/api/values-production.yaml

      - name: Commit and push the updated tag
        run: |
          git config user.name "CI Bot"
          git config user.email "ci@myorg.com"
          git add apps/api/values-production.yaml
          git commit -m "deploy: api ${{ github.sha }} to production"
          git push
          # Argo CD detects this commit and applies the change to the cluster
          # No cluster credentials needed in this pipeline at all

Practice Questions

Answer in your own words — then check against the expected answer.

Lesson Quiz