Google Cloud Platform 基础设施。

我们提供面向多云整合、容器化负载与基础设施成本控制的 Google Cloud Platform 托管部署服务——以新加坡为基地， 服务亚太地区的企业。

GCP 被视为整体资产中的一个环境，而非孤立存在。当负载跨越多个云平台时，我们配置 VPC 对等互联与安全专线， 使 GCP、AWS 与 Cloudflare 边缘之间的路由经过明确设计，并使流量检测与计算部署在整条路径上保持一致。

Kubernetes：选择 GCP 的理由

Google Kubernetes Engine 是目前最成熟的托管 Kubernetes 平台，对许多组织而言，它正是 Google Cloud 进入其架构的原因。 我们以 Standard 与 Autopilot 两种模式设计并运营 GKE 集群：节点池依据实际 Pod 请求量而非估算确定规模， 以 Workload Identity 取代长期有效的服务账号密钥，以网络策略限制东西向流量，Ingress 置于 Cloudflare 边界之后， 使集群从不直接暴露。

当某项服务不需要集群时——无状态 API、定时任务、Webhook 接收端——Cloud Run 可在没有运维开销的情况下运行容器， 空闲时缩减至零。按负载在 GKE 与 Cloud Run 之间做出选择，而不是因为集群存在就把一切都放上去， 是保持 GCP 支出与业务规模相称的重要因素。

跨云互联

多云架构的质量取决于各部分之间的网络。我们设计项目与 VPC 层级，使 GCP 负载通过私有地址访问 AWS 负载—— 吞吐量适中时使用 VPN 隧道，带宽与时延有更高要求时则在运营商中立机房对接 Cloud Interconnect 与 AWS Direct Connect—— DNS 在两侧统一解析，防火墙规则只编写一次，而非按云各写一套。

Cloudflare 边缘接入同一网络结构。入站流量在边界完成检测后，路由至承载该服务的云平台， 各云中的源站仅接受来自 Cloudflare 的连接。

支出与业务规模相称

Google Cloud 的定价模式对承诺的稳态负载慷慨，对被遗忘的资源则代价高昂。我们持续依据真实用量复核每个项目： 对稳态基线应用承诺使用折扣、识别闲置的 Compute Engine 实例与未挂载的永久性磁盘、发现余量远超 Pod 请求的节点池、 纠正与访问模式不匹配的存储类别、将可留在区域内的出站流量留在区域内。结算账户层面的预算与告警使增长尽早可见， 每项建议在实施之前均已量化。

GCP 在整体架构中的位置

Google Cloud 是我们运营的两个云平台之一，位于 Cloudflare 边界之后， 与 AWS 并行。客户委托我们的场景包括： 将既有的一组 GCP 项目纳入托管；为正在容器化的应用搭建 Kubernetes 平台；或在 AWS 架构之上加入 GCP 作为第二家供应商—— 两者之间的网络经过设计，而非临时拼凑。