Docker CI/CD for Kubernetes: Build, Scan, Sign, and Deploy Without the Pain

Kubernetes deployment on its own is powerful but incomplete. Pushing an ad-hoc image tag and running kubectl apply -f deployment.yaml works for a demo, but in production it's a recipe for drift, rollback chaos, and security gaps. Every team that scales past a single cluster discovers they need a repeatable, auditable pipeline that builds, scans, signs, and deploys with guardrails at every stage.

The challenge is that Kubernetes itself doesn't care about the CI/CD pipeline. It will happily run a container with critical CVEs, unsigned images, or the wrong tag. The pipeline is where you enforce quality — and Docker's toolchain (buildx, Scout, cosign) provides the building blocks.

This article walks through a complete production pipeline from git push to running pods. We'll cover kubectl set image for simple rollouts, helm upgrade --atomic for Helm-managed applications, blue-green and canary deployment strategies, rollback tactics (kubectl rollout undo, helm rollback), environment promotion with manual gates, and ArgoCD GitOps integration.

Pipeline Foundation: Build, Tag, Scan, Sign, Push

Every Kubernetes CI/CD pipeline starts with the same five steps: build an image with a unique tag, scan it for vulnerabilities, sign it for authenticity, push it to a registry, and record the digest. The unique tag is critical — using :latest in Kubernetes leads to configuration drift where different nodes run different versions. Always use the commit SHA as the image tag.

The scan step uses Docker Scout (policy-based) or Trivy (comprehensive). The sign step uses cosign (Sigstore) for keyless signing. Signing is increasingly required for admission control — Kubernetes can be configured with OPA/Gatekeeper or Kyverno to only allow signed images.

The push step should record the image digest (myapp@sha256:abc...) rather than the tag, because tags can be overwritten. The digest is immutable and guarantees that what was scanned and signed is exactly what gets deployed.

# Set unique tag based on commit SHA
SHA=$(git rev-parse --short HEAD)
IMAGE="myapp:$SHA"
REGISTRY="registry.example.com"

# Step 1: Build
docker buildx build --platform linux/amd64,linux/arm64 \
  -t $REGISTRY/$IMAGE --push .

# Step 2: Scan with Docker Scout (block on critical CVEs)
docker scout policy $REGISTRY/$IMAGE --policy .scout-policy.yaml

# Step 3: Sign with cosign (keyless, using OIDC)
cosign sign --yes $REGISTRY/$IMAGE

# Step 4: Record digest for immutable deployment
DIGEST=$(docker buildx imagetools inspect $REGISTRY/$IMAGE \
  --format '{{json .Manifest.Digest}}')
echo "Image digest: $DIGEST"

Deploying to Kubernetes with kubectl set image and Rollout

The kubectl set image command updates a deployment's container image in-place, triggering a rolling update. Combined with kubectl rollout status to wait for completion and kubectl rollout undo to revert on failure, this is the simplest production-ready deployment pattern.

Key parameters: kubectl rollout status deployment/<name> --timeout=5m waits up to 5 minutes for the rollout to complete. If it times out or detects a failure, the pipeline should call kubectl rollout undo deployment/<name> to revert.

For zero-downtime, ensure your deployment has a rolling update strategy with appropriate maxSurge and maxUnavailable.

# Deploy new image
kubectl set image deployment/myapp \
  myapp=$REGISTRY/$IMAGE --record

# Wait for rollout to complete (timeout after 5 minutes)
if ! kubectl rollout status deployment/myapp --timeout=5m; then
  echo "Rollout failed — rolling back"
  kubectl rollout undo deployment/myapp
  kubectl rollout status deployment/myapp --timeout=3m
  exit 1
fi

echo "Deployment successful — image: $DIGEST"

# Verify all pods are running the correct image
kubectl get pods -l app=myapp \
  -o jsonpath='{.items[*].spec.containers[*].image}'

Helm Upgrade --atomic: Deployments with Automatic Rollback

Helm manages Kubernetes applications as releases with versioned chart deployments. The helm upgrade --atomic command deploys a chart and automatically rolls back to the previous revision if the deployment fails. This is more robust than kubectl set image because Helm tracks all resources (Deployments, ConfigMaps, Services, Ingresses) as a single release.

Key flags: --atomic rolls back on failure, --timeout 5m sets the maximum wait time, --install creates the release if it doesn't exist, --history-max 10 limits stored revisions.

# Deploy with Helm — atomic upgrade with automatic rollback
helm upgrade --install myapp ./chart \
  --set image.repository=$REGISTRY \
  --set image.tag=$SHA \
  --set image.digest=$DIGEST \
  --atomic --timeout 5m --history-max 10 \
  --namespace production

# If the atomic deploy fails, explicitly roll back
if [ $? -ne 0 ]; then
  echo "Helm upgrade failed — rolling back"
  REVISION=$(helm history myapp -n production \
    -o json | jq '.[-2].revision')
  helm rollback myapp $REVISION \
    --namespace production --wait --timeout 3m
  exit 1
fi

Blue-Green and Canary Deployment Strategies

Beyond simple rolling updates, blue-green and canary deployments provide finer control over release risk. Blue-green maintains two identical environments (blue = current, green = new) and switches traffic atomically. Canary routes a small percentage of traffic to the new version and gradually increases it.

Blue-green implementation: deploy the new version with a different label (e.g., version: green), run health checks, then update the Service selector to point to the new version. Rollback is instant — just switch the selector back. The downside: doubled resource requirements during deployment.

Canary implementation: deploy the new version with a small replica count, use a service mesh (Istio, Linkerd) or ingress controller weight-based routing to split traffic. Monitor error rates for a soak period, then gradually increase the canary weight. If error rate spikes, the pipeline aborts the canary.

# Canary deployment with Istio VirtualService traffic splitting
# Step 1: Deploy canary (1 replica of new version)
kubectl apply -f k8s/canary-deployment.yaml

# Step 2: Verify canary is healthy
kubectl rollout status deployment/myapp-canary --timeout=3m

# Step 3: Route 5% traffic to canary
kubectl patch virtualservice myapp --type=merge \
  -p '{"spec":{"http":[{"route":[{"destination":{"host":"myapp","subset":"stable"},"weight":95},{"destination":{"host":"myapp","subset":"canary"},"weight":5}]}]}}'

# Step 4: Observe for 5 minutes
sleep 300
if [ "$(get_error_rate canary)" -gt 1.0 ]; then
  echo "Canary error rate too high — aborting"
  kubectl scale deployment/myapp-canary --replicas=0
  exit 1
fi

# Step 5: Gradually increase canary weight
echo "Canary healthy — scaling to 100%"
kubectl patch virtualservice myapp --type=merge \
  -p '{"spec":{"http":[{"route":[{"destination":{"host":"myapp","subset":"canary"},"weight":100}]}]}}'

Rollback Strategies: kubectl rollout undo, helm rollback, and Automated Fallback

A deployment strategy is only as good as its rollback mechanism. The key principle: rollback should be automated in the pipeline, not a manual kubectl command executed by an engineer under pressure.

For kubectl set image deployments, kubectl rollout undo deployment/<name> reverts to the previous revision. Revision history is limited by revisionHistoryLimit in the deployment spec (default: 10).

For Helm deployments, helm rollback <release> <revision> reverts the entire release. Use --wait --timeout 3m to wait for the rollback to complete. Helm tracks every upgrade as a new revision.

For ArgoCD GitOps, rollback is done by reverting the Git commit and letting ArgoCD sync.

# kubectl rollout undo
kubectl rollout undo deployment/myapp
kubectl rollout undo deployment/myapp --to-revision=3
kubectl rollout history deployment/myapp

# helm rollback
helm rollback myapp --namespace production --wait --timeout 3m
helm rollback myapp 5 --namespace production --wait --timeout 3m
helm history myapp --namespace production

# Automated pipeline rollback pattern
deploy() {
  if ! helm upgrade --atomic myapp ./chart; then
    echo "Deploy failed — rolling back"
    helm rollback myapp $(helm history myapp -o json | jq '.[-2].revision')
  fi
}

Environment Promotion with Manual Gates

Single-environment pipelines are simpler but risky — every commit goes straight to production. Environment promotion adds staging environments where changes are validated before reaching production, with manual approval gates between them.

Manual gates in GitHub Actions use environment with required reviewers. In GitLab CI, use when: manual with needs in the production job. The gate stops the pipeline until an authorized reviewer approves it.

The promoted artifact should be the same image digest from dev — never rebuild for production. Build once, promote across environments.

name: Deploy with Environment Promotion
on:
  push:
    branches: [main]
jobs:
  build:
    outputs:
      digest: ${{ steps.build.outputs.digest }}
    steps:
      - name: Build and push
        id: build
        run: |
          SHA=$(git rev-parse --short HEAD)
          docker buildx build --push -t myapp:$SHA .
          echo "digest=$(docker buildx imagetools inspect myapp:$SHA --format '{{.Manifest.Digest}}')" >> $GITHUB_OUTPUT
  deploy-dev:
    needs: [build]
    environment: dev
    steps:
      - run: helm upgrade --install myapp ./chart --set image.digest=${{ needs.build.outputs.digest }}
  deploy-staging:
    needs: [deploy-dev]
    environment: staging
    steps:
      - run: helm upgrade --install myapp ./chart --set image.digest=${{ needs.build.outputs.digest }} --atomic
  deploy-prod:
    needs: [deploy-staging]
    environment: prod
    steps:
      - run: helm upgrade --install myapp ./chart --set image.digest=${{ needs.build.outputs.digest }} --atomic --timeout 10m

ArgoCD GitOps Integration

ArgoCD follows the GitOps pattern: the Git repository is the single source of truth for the desired state of the cluster. ArgoCD continuously monitors the Git repo and the live cluster, and syncs any drift. In this model, the CI pipeline's job is to: (1) build and push the image, (2) update the deployment manifest in the Git repo with the new image digest. ArgoCD detects the change in Git and syncs the cluster automatically.

The pipeline should never call kubectl or helm directly when using ArgoCD. Instead, it commits the updated manifest to the Git repo using a GitOps token with write access. ArgoCD syncs on its own schedule (typically 3 minutes, or faster with webhooks).

# CI pipeline for ArgoCD GitOps — no kubectl or helm commands!

# Step 1: Build, scan, sign, push image
docker buildx build --push -t myapp:$SHA .
docker scout policy myapp:$SHA --policy .scout-policy.yaml
cosign sign --yes myapp:$SHA
DIGEST=$(docker buildx imagetools inspect myapp:$SHA --format '{{.Manifest.Digest}}')

# Step 2: Clone the GitOps repo and update the manifest
git clone https://$GITOPS_TOKEN@github.com/org/gitops-repo.git
cd gitops-repo

# Update the image digest in the k8s deployment manifest
yq eval -i ".spec.template.spec.containers[0].image = \"myapp@$DIGEST\"" apps/myapp/deployment.yaml

# Commit and push
git config user.email "ci@example.com"
git config user.name "CI Pipeline"
git add -A
git commit -m "Update myapp image to $SHA ($DIGEST)"
git push

# Step 3: ArgoCD auto-detects the change within 3 minutes