github actions自动发布到kubernetes的核心是构建可信任、可复现的流水线，关键在于权限控制、凭证安全、镜像可信和部署幂等四点到位：需用最小权限serviceaccount的kubeconfig（存为secret）、构建推送带sha标签的镜像、通过kubectl apply或gitops方式部署、并执行rollout status与健康检查验证。
GitHub Actions 实现自动发布到 Kubernetes，核心是把“代码变更 → 构建 → 部署”串成一条可信任、可复现的流水线。关键不在于写多少 YAML，而在于权限控制、凭证安全、镜像可信和部署幂等这四点是否到位。
准备好 Kubernetes 访问凭证与上下文
GitHub Actions 本身不连集群，必须让 Runner 能执行 kubectl 命令。最常用且推荐的方式是：把精简、作用域受限的 kubeconfig 文件内容存为 GitHub Secrets（比如叫 KUBECONFIG_SA），再在工作流中写入 ~/.kube/config。
- 这个 kubeconfig 应来自专用的服务账户（ServiceAccount），绑定最小必要 RBAC 权限（如仅对目标命名空间有
deployments、secrets、pods的读写） - 避免使用管理员 kubeconfig，更不要硬编码或明文提交
- 部分平台（如 AKS、GKE）支持用 Azure 登录或 GCP Workload Identity 替代 kubeconfig，安全性更高
构建并推送容器镜像
发布前必须有新镜像。GitHub Actions 可以原生构建 Docker 镜像，并推送到 GHCR、ACR、GCR 或其他私有/公有 Registry。
Convert Github Repository
下载
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
- 用
docker/build-push-action@v5构建并推送，配合secrets.GITHUB_TOKEN即可推送到 GHCR - 若用 ACR，需先通过
azure/docker-login@v1登录，再构建推送 - 镜像 Tag 建议用
${{ github.sha }}或${{ github.event.pull_request.head.sha }}，确保每次部署对应明确版本 - 务必在 Deployment YAML 中将
image:字段设为变量（如ghcr.io/owner/repo:${{ github.sha }}），避免硬编码 latest
部署清单到集群（kubectl 或 GitOps）
有两种主流方式把应用“落”到 Kubernetes：
-
直接 kubectl apply：适合简单场景。用
azure/setup-kubectl@v3安装 kubectl，再运行kubectl apply -f ./k8s/。注意加--dry-run=client -o yaml先校验语法，再实际 apply -
Helm/Kustomize 渲染后部署：更适合多环境（dev/staging/prod）。用
azure/k8s-bake@v4渲染模板，输出纯 YAML，再交给azure/k8s-deploy@v4执行。能天然支持覆盖参数、环境差异化 - GitOps 方式（如 Argo CD）不直接由 Actions 部署，而是 Actions 更新 Git 仓库中的 manifests，由 Argo CD 自动同步——这种方式审计更清晰、回滚更可靠
验证与滚动更新保障可用性
发布不是“apply 完就结束”，还要确认服务真正就绪。
- 加一步
kubectl rollout status deployment/my-app -n my-ns --timeout=120s，等待新 Pod Ready 并旧 Pod 完全终止 - 可选：调用健康检查端点（如
curl -f http://my-app:8080/healthz），失败则整个 job 失败，阻止错误发布 - 滚动重启已有部署（如
kubectl rollout restart deployment/my-app）适用于只改配置不换镜像的场景 - 建议在 job 最后加
kubectl get pods -n my-ns日志快照，便于事后排查
