如何使用 GitHub Actions、Ingress 和自动 TLS 在 GKE 上构建临时 PR 预览环境

邱宇行业资讯📡 BestBlogs·全站精选⭐ 902026-10-16244 阅读💛 207 收藏
如何使用 GitHub Actions、Ingress 和自动 TLS 在 GKE 上构建临时 PR 预览环境

📌 One-Sentence Summary

本手册详细介绍了如何构建一套完整系统,利用 GitHub Actions、Workload Identity Federation、共享 Ingress 和自动 TLS,为每个拉取请求在 GKE 上提供独立、自动部署且自动销毁的预览环境。

📝 Summary

文章针对共享预发布环境的常见问题——多个拉取请求相互冲突、配置漂移——提出了为每个拉取请求提供独立临时环境的方案,这一模式已被 Vercel、Netlify 和 Shopify 采用。教程基于 Google Kubernetes Engine(GKE)和 GitHub Actions 构建该方案。关键设计决策包括:通过 Workload Identity Federation 实现无密钥认证、使用单一共享 Ingress 控制器配合通配符 DNS 以避免为每个 PR 配置负载均衡器、以及通过定时清理任务清除孤立命名空间。指南涵盖项目结构、带构建时元数据注入的 Go 应用、多阶段 Dockerfile、Terraform 基础设施、使用 Kustomize 的 Kubernetes 清单、启动与销毁工作流,以及从 PR 创建到合并的完整生命周期。文章还讨论了成本影响和清理策略。

💡 Main Points

每个 PR 的临时环境解决了共享预发布环境的问题。

共享预发布环境会导致冲突、状态不清晰和配置漂移。为每个 PR 提供独立隔离的环境可以消除排队和清理开销,并确保环境更接近生产环境。

使用 Workload Identity Federation 的无密钥认证比服务账号密钥更安全。

GitHub Actions 通过基于仓库声明验证的短期 OIDC 令牌向 Google Cloud 进行认证,避免了在 GitHub secrets 中存储长期服务账号 JSON 密钥的风险。

单一共享 Ingress 控制器和通配符 DNS 降低了成本和复杂性。

无需为每个环境配置负载均衡器,一个 Ingress 控制器即可路由所有预览主机名,一条通配符 DNS 记录即可覆盖所有未来环境,显著降低云成本。

自动化清理必须假设失败情况,并包含定时清理任务。

即使 PR 关闭时会触发销毁,某些环境仍可能泄漏。定时任务会删除 PR 已不存在或超过最大存活时间的命名空间,防止不必要的计费。

构建元数据应烘焙到容器镜像中,而非通过环境变量传递。

使用 Go 的 -ldflags -X 在构建时注入 PR 编号和 Git SHA,确保运行中的应用报告真实的构建标识,防止通过部署时环境变量进行虚假标识。

💬 Key Quotes

预发布环境是共享的。一个环境,多个拉取请求。

给每个拉取请求自己的环境

无需服务账号密钥:GitHub Actions 通过 Workload Identity Federation 向 Google Cloud 进行认证。

一个负载均衡器,而非每个 PR 一个

假设失败的清理:PR 关闭时会触发销毁。但定时清理任务还会删除 PR 已不存在或超过最大存活时间的命名空间,因为即使 95% 有效的自动化清理仍会泄漏,而泄漏会体现在账单上。

📊 Article Meta

AI Screening: 90

Featured: Yes

Source: freeCodeCamp

Author: Amina Lawal

Category: 软件编程

Language: 英文

Read Time: 55 min

Word Count: 13532

Tags:

编程与工程 , 云原生 / DevOps , 安全 , Google , Vercel

#编程与工程# 云原生 / DevOps# 安全# Google# Vercel

文章评论(4)

逐光而行37 分钟前

有没有更详细的教程,期待后续。

回复
晨沐雨2 小时前

写得挺用心的,支持一下。

回复
雪知秋25 分钟前

作者写得真不错,学到了不少。

回复
陈皮话梅糖2 小时前

这篇文章分析得很透彻,收藏了!

回复