CloudRun 私有服务来服务主机名答案

【问题标题】：CloudRun private service to service hostnamesCloudRun 私有服务来服务主机名
【发布时间】：2019-05-21 19:04:16
【问题描述】：

在 CloudRun 上进行东西向服务调用时，文档涵盖 service to service authentication，但该示例不包含任何有关处理内部服务的正确方法的文档。

有 cloud run deploy 生成的 url，但它包含神秘的随机性 https://{service}-{a google id?}.a.run.app，这意味着您不能像在 GKE 集群中那样仅使用服务名称进行东西向调用。

我想知道我是否刚刚错过了 CloudRun 中的文档或 Knative 服务文档中的上游文档，或者我需要使用 CloudRun HTTP 或 RPC API 实现某种服务发现？

【问题讨论】：

“东西向”服务到服务调用是什么意思？
关于服务到服务的身份验证，这个例子是正确的，您只需要了解 OAuth 服务帐户凭据以及如何验证令牌即可。需要一个很好的例子来说明如何。本文可能对您有所帮助：medium.com/@stephen.darling/…
关于内部服务——您指的是什么服务？在某些情况下，服务会根据发送到 Cloud Run 的标头进行自动身份验证验证，Cloud Run 会在后台为您验证。
关于服务发现，Cloud Run 不存在。如果您想知道端点名称，您可以在 DNS 服务器中创建自己的端点 URL。 Cloud Run 的设计更倾向于 HTTP 请求/响应框架。想想微服务、Web 服务等，而不是像 Kubernetes 中那样紧密耦合的服务。另一个比较是 Cloud Functions，但在类固醇上。
东西向是微服务在网络/集群服务到服务通信中的代名词。您会发现它在 Knative 默认使用的 Istio 等服务网格产品中大量使用。

【解决方案1】：

Cloud Run（托管服务）不提供与 Cloud Run on GKE 或 Kubernetes 通常提供的相同名称质量的主机名。 {service} 或 {service}.{namespace}.srv.cluster.local 等将无法解决。

【讨论】：

【解决方案2】：

您可以查看新的 runsd 项目。它通过为您提供友好的主机名来调用同一项目中的其他 Cloud Run 服务来解决 Cloud Run 的 DNS 服务发现问题。它还会自动对发送到 Cloud Run 服务的每个请求进行身份验证

【讨论】：