Kent Dong

> 这样连接被拒绝了 > > * connect to 10.68.5.183 port 8080 failed: Connection refused > * Failed to connect to go-ping-s.default.svc.cluster.local port 8080 after 4 ms: Connection refused > * Closing...

> ```yaml > go-ping-s.default.svc.cluster.local:8080 > ``` 嗯，那你要查查kubeproxy什么的了。看一下Service和Endpoints呢，里面有Pod吗？

> URX: The request was rejected because the upstream retry limit (HTTP) or maximum connect attempts (TCP) was reached. > https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage 目测是连不上。上面命令是在Gateway的Pod里做的吗？我看host变了。新的ingress发一下呢？

> curl -svk http://go-ping-s.default.svc.cluster.local:8080 建议你 exec 到 higress-gateway 的 pod 里再 curl 一下

> @CH3CHO 执行结果如下 你这个是在node上执行吧？能kubectl exec到pod里面吗？

> 这个就是在higress-gateway的pod内执行的 那这个前面的机器名有点迷惑性啊

因为实际执行服务发现的并不是控制台组件，这样做的话就有两个办法： 1. Console 针对性的对各种服务来源类型进行检测，这个不会太准； 2. Controller 开放一个接口，接受服务来源配置信息进行检测和服务发现，供 Console 调用。 @johnlanni 看一下这个需求呢？

> > > > ``` > discovery: > locator: > #自动为每一发现的服务生成路由：/serviceId/**，并转发请求时删除/serviceId前缀 > enabled: true > #serviceId使用小写字符 > lower-case-service-id: true > > ``` > > ``` > 准确的讲是gateway为发现的服务生成了路由 > ``` 应该是这里说的...

> @wuchencm 这个Higress是可以实现的，在McpBridge里监听Nacos中的服务信息时，目前只转换成ServiceEntry，通过一个开关可以转换为VirtualService就可以了。控制台交互类似，cc @CH3CHO ：  感觉是不是放到路由下面好一点呢？它属于一种特殊的路由类型，关联一个服务来源而不是服务

> @CH3CHO 实现上我觉得还是跟着 McpBridge 走，不跟着 Ingress，但是交互上可以考虑放到路由里 嗯，这个我理解，就是增加一个创建动态路由的功能，配置写到McpBridge里，但界面放到路由管理里。这个我界面设计一下先，等Controller那边支持了再做界面。