K8sCalc

kubernetes

GitHub Actions K8s Deploy Generator

Generate a GitHub Actions workflow that builds and pushes a Docker image to GHCR, Docker Hub, or a private registry, then deploys to Kubernetes via kubectl or Helm.

CI/CD for Kubernetes with GitHub Actions

A complete Kubernetes CI/CD pipeline has three stages: test → build+push → deploy.

Image Tagging Strategy

yaml
tags: |
  type=sha,prefix=sha-      # sha-abc1234 — immutable, traceable
  type=ref,event=branch     # main — mutable, for latest ref
  type=semver,pattern={{version}}  # v1.2.3 — for releases

Secure kubeconfig Access

bash
# Encode your kubeconfig
cat ~/.kube/config | base64

# Add as GitHub Secret: KUBECONFIG # Workflow decodes it: echo "${{ secrets.KUBECONFIG }}" | base64 -d > ~/.kube/config chmod 600 ~/.kube/config ```

Build Cache

yaml
- uses: docker/build-push-action@v5
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

Helm vs kubectl

kubectl set imageHelm upgrade
Config managementManualvalues.yaml in Git
Rollbackkubectl rollout undohelm rollback
Multi-resourceRequires multiple commandsSingle command
Best forSimple single-deployment appsComplex multi-resource charts

Frequently Asked Questions

How do I store my kubeconfig in GitHub Secrets?

Run: cat ~/.kube/config | base64 | pbcopy. Then in GitHub: Settings → Secrets → New secret → name it KUBECONFIG. The workflow decodes it with: echo '${{ secrets.KUBECONFIG }}' | base64 -d > ~/.kube/config. Never commit kubeconfig to your repo.

Why tag images with the git SHA?

Mutable tags (latest, main) make rollbacks impossible — you can't tell which code is running. SHA tags (sha-abc1234) are immutable and traceable. Every deployment is pinned to a specific commit, making debugging and rollback reliable.

What is docker/build-push-action cache?

The GitHub Actions cache (cache-from/cache-to: type=gha) stores Docker layer cache in GitHub's cache storage. On subsequent builds, unchanged layers are restored from cache instead of being rebuilt — reducing build times from 5 min to 30 sec for typical Node/Python apps.

How does kubectl rollout status work?

kubectl rollout status deployment/my-app waits until the new pods are running and ready before the workflow step completes. If the new image has a bug and pods crash-loop, the rollout status command fails the workflow — preventing broken deploys from being marked as successful.