nvd11的专栏

这个模式在 GKE 是没问题的，因为前后端虽然部署在不同的 POD，但是可以共同 under 一个 GKE Gateway 之下。但是前端是无法直接通过 IAP 获取用户信息的，必须通过调用另一个同域的同样的 enable IAP 的 API (通常是同域的后端 API)而前后端都部署在 Cloud Run 上会不同了，两个 Cloud Run svc 天然有两个不同的域名。当前端开启 IAP 后，用户打开前端页面就会被重导向到 Google 账号登陆页面，当用户登陆后就会进入前端页面。

这不只是一篇技术博客，这是一篇战报。它讲述了一个看似简单的部署任务，如何演变成一场长达数小时、穿越 GCP 负载均衡、Envoy、FastAPI 和 MCP 协议层层迷雾的调试之旅。如果你也曾经历过“本地猛如虎，上线死如狗”的服务，那么，泡杯咖啡，这个故事就是为你准备的。

本文记录了py-github-agent项目中调用Google Gemini API时程序卡住问题的诊断与解决方法。问题表现为程序在调用API后无响应，经分析发现是gRPC协议与HTTP代理不兼容所致。解决方案是强制客户端使用REST API而非gRPC，通过在ChatGoogleGenerativeAI初始化时添加transport="rest"参数实现。修改后程序恢复正常，验证了REST API对代理的兼容性更好。

本文记录了Envoy代理集群自动化滚动更新的完整排查过程。初始问题表现为服务无响应，排查发现请求未到达后端就被GCP前端拒绝。深入分析发现GCE虚拟机上的Envoy配置文件版本过旧，进一步调查确认该虚拟机由代管实例组(MIG)管理，不能直接修改单机配置。最终建立了自动化更新流程：通过Cloud Build管道构建包含最新配置的镜像，并创建定时触发的管道自动更新MIG实例模板。解决方案实现了符合IaC最佳实践的自动化部署方案，包括开发修改、镜像构建和定时滚动更新三个关键步骤，有效解决了服务无响应问题并建立了可

每个 GCP 虚拟机都会自动配置一个 Metadata Server，Envoy 可以通过一个特定的 HTTP 端点（http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?世界上最常用的代理当然是nginx， 但nginx 很难实现这个动态获取gcp token的功能， 不是说不能， 只是要自己写一些插件之类的。例如 /pyapi/xxxx -> py-api-svc/

nvoy 是一个开源的边缘和服务代理，专为现代云原生应用程序设计。它可以被认为是网络流量的通用数据平面。Envoy 最初由 Lyft 构建，现在是云原生计算基金会 (CNCF) 的毕业项目。