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
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 releasesSecure kubeconfig Access
# 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
- uses: docker/build-push-action@v5
with:
cache-from: type=gha
cache-to: type=gha,mode=maxHelm vs kubectl
| kubectl set image | Helm upgrade | |
|---|---|---|
| Config management | Manual | values.yaml in Git |
| Rollback | kubectl rollout undo | helm rollback |
| Multi-resource | Requires multiple commands | Single command |
| Best for | Simple single-deployment apps | Complex 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.