同一GCP项目中Cloud Run与GKE服务通信及部署方案咨询

问题1：为GKE服务配置域名、负载均衡及SSL证书的方案是否可行？ #

该方案完全可行，但属于「对外暴露式」的互连方式，适合需要公网访问GKE服务的场景：

• 实现路径：通过GKE Ingress配置外部负载均衡，绑定自定义域名并申请GCP托管式SSL证书，将生成的HTTPS地址写入Deployment的环境变量，即可让Cloud Run和其他GKE服务通过公网域名访问目标GKE服务，和现有Cloud Run的互连逻辑完全兼容。
• 利弊分析：
  • 优势：和现有Cloud Run的访问模式统一，无需修改服务内部的通信代码；公网域名便于排查跨服务调用问题、接入监控工具。
  • 劣势：额外产生负载均衡、域名解析的成本；需要维护Ingress规则、SSL证书续期、域名解析记录，增加运维复杂度。

问题2：无需域名、SSL证书及负载均衡的替代方案 #

针对同项目内的服务互连，有两种更轻量化的内部通信方案：

方案一：基于GCP VPC内部网络通信 #

利用GCP同项目VPC的互通特性，直接通过内部地址访问：

• GKE集群内服务互访：给每个GKE Deployment创建ClusterIP类型的Service，其他GKE服务可通过{服务名}.{命名空间}.svc.cluster.local:{端口}的内部域名访问，比如xxxxx-api.xxxxx.svc.cluster.local:8080，直接将该地址写入环境变量即可。
• Cloud Run访问GKE服务：创建GCP Serverless VPC Access Connector，让Cloud Run接入GKE所在的VPC网络，之后Cloud Run就能直接访问GKE的ClusterIP服务地址；也可将GKE Service配置为Internal LoadBalancer，通过内部IP访问。
• GKE访问Cloud Run服务：Cloud Run提供内部服务域名（{服务名}.run.app的内部访问入口），或通过VPC Connector直接访问，无需依赖公网域名。

方案二：采用服务网格（Anthos Service Mesh） #

若需要精细化流量管理（如熔断、灰度发布、统一加密），可部署Anthos Service Mesh（ASM）：

• 所有服务通过网格中的Sidecar代理通信，直接使用服务名即可完成跨集群/跨平台（Cloud Run+GKE）的调用，无需配置外部地址或负载均衡；
• 网格自动处理服务间的TLS加密，无需手动管理SSL证书。

GitHub Actions自动化部署适配 #

两种方案都可通过GitHub Actions实现全流程自动化：

• 对外暴露方案：用gcloud命令创建Ingress、申请SSL证书，通过sed/Kustomize替换Deployment YAML中的域名变量，再执行kubectl apply部署。
• 内部通信方案：提前在YAML中写好内部服务地址，或借助GCP服务发现自动注入环境变量，GitHub Actions仅需执行镜像构建推送、kubectl apply部署即可；若用到Serverless VPC Connector，可在Actions中添加步骤检查Connector状态，确保连通性。

内容的提问来源于stack exchange，提问作者DevOPs