我有一个 GKE 集群，我正在其上测试 Google Cloud Run，它还托管不由 Cloud Run 管理的服务。为了访问这些，我设置了一个简单的网关和虚拟服务，如此处所述。此网关已在启用了 Istio 插件但未启用 Cloud Run 的 GKE 集群中成功运行。
似乎在启用了 Cloud Run 的集群中，我的自定义网关被忽略了，并且所有流量都通过名为 istio-autogenerated-k8s-ingress 的默认网关。我怀疑这可能是因为默认值是为Hosts: *.
如何确保不受 Cloud Run 管理的服务的网关优先于它负责的主机？编辑自动生成的网关是否安全？修改它会破坏 Cloud Run 吗？Cloud Run 在正常运行时会覆盖或修改此文件吗？
istio-autogenerated-k8s-ingress 由 Istio 插件提供。CloudRun 不使用它。所以删除它是安全的。它不会破坏 CloudRun。
GKE 上的 CloudRun 默认使用命名空间 knative-serving 下的 Gateway knative-ingress-gateway。我很好奇你的用例。您是否还想使用自己的网关为 CloudRun 相关服务提供流量？如果你愿意，你可以在 config-istio ConfigMap 中添加一个条目 "gateway.{your-own-gateway}: "istio-ingressgateway.istio-system.svc.cluster.local " com/knative/serving/blob/master/config/config-istio.yaml）。
编辑自动生成的网关是否安全？
是的，但是如果您为 GKE 集群使用了 Cloud Run 插件，那么它会在一段时间后被重写为插件中的一个。
修改它会破坏 Cloud Run 吗？
如果您写错或犯了错误，Cloud Run 可能无法正常工作。
Cloud Run 在正常运行时会覆盖或修改此文件吗？
如上所述，如果您使用插件将 Cloud Run 部署到集群，那么配置可能会在一段时间后自动修改，因为一切都是预先配置的。
您是否使用过本指南在 GKE 上设置 Cloud Run？如果是这样，请阅读serving/pkg/reconciler/route/README.md，因为它可能很有帮助。