istio 如何让在 pod 里请求自己的 inbound route？

[nicholasxuu]

我们的服务原来是请求统一的 envoy 网关，再来分发到对应服务的。

想用 istio virtual service ，配置好 route （测试发现只能创建 inbound route ），通过gateway=mesh把这些路由规则发到每个 pod 的 sidecar 里去。这样服务只要请求自己这个 pod 的 sidecar ，就能靠 sidecar 的 proxy 转发到路由规则对应的服务里去了。（也就不需要那个中心的 envoy 网关来处理集群内部点对点的请求了）

我知道，可以直接请求对应的a-service.namespace.svc.cluster.local，就能请求到 mesh 里的目标服务了。但这样我对 service 名字的管理会比较麻烦，加上一些历史原因（要改很多微服务的代码）。所以，还是希望请求同一个 host ，用 path 来做路由。

现在卡了几个问题：

1. 如何请求自己 pod 的 sidecar ？在不跨 pod/跨节点的情况下，最快的触发 sidecar 的 envoy inbound route rule ？
2. virtual service 如果出现 match 规则里带了 port(不是 80 的 port)，那个 route 规则好像就会从 sidecar 的 envoy route 规则里消失了。是不是缺什么配置？或者gateway=mesh这种全局规则会有限制？

[tanxnative]

envoy 中配置 取出来看看

[nicholasxuu]

@tanxnative #1
virtual service
```
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin-vs
spec:
hosts:
- "testapi.host.com"
gateways:
- mesh
http:
- match:
- uri:
prefix: /status
- uri:
prefix: /anything
- uri:
prefix: /headers
route:
- destination:
host: httpbin.default.svc.cluster.local
port:
number: 5000
```
`curl -H 'Host: testapi.host.com' http://any-other-service.default/anything`是可以的

`curl -H 'Host: testapi.host.com' http://172.16.153.111.default/anything`是可以的（ IP 是任何自己 service 的 cluster ip ）

但是

`curl -H 'Host: testapi.host.com' http://10.73.3.111/anything` 就不行了（ IP 是自己 pod 的 ip ）
报错`curl: (7) Failed to connect to 10.73.3.111 port 80 after 0 ms: Connection refused`

尝试请求传说中 sidecar http inbound 端口也不行：
`curl -H 'Host: testapi.host.com' http://127.0.0.1:15001/anything`
`curl: (56) Recv failure: Connection reset by peer`

[ermeow]

15001 是 egress 流量重定向到的 outbound 端口，你直接发应该是没匹配到 listener 或者路由就会 reset

不太理解你的原始需求是什么。如果只是要用 path 区分后端服务，这是基本功能吧。为什么要发给自己？

你可以用 Istioctl pc 把 listener route endpoint 导出来研究一下生成的 envoy 配置

如 istio 配置满足不了你的需求，可以上 EnvoyFilter

[lidashuang]

https://cos.ap-beijing.myqcloud.com/dropshare-1252438752/pb-9lcRlyM599-8frtYz8rDxTgymwY0Q1wlS7JcW2WTOt.png 看看这个配置

[nicholasxuu]

@lidashuang #4 你意思是用 gateway=mesh 把路由规则发布到每个 pod 的 sidecar envoy 里？这个已经做到了。
但测试发现这些路由规则是请求进入 service/pod 时(inbound)才能触发的。（本来以为可以 outbound 时就能使用这些路由规则）
所以我需要在 pod 里先请求到某个 service （任何一个 service ），在那个 service 的 inbound 处理那儿，才能使用这些路由规则。就让这个请求多了一步。
理想的情况：请求者 pod 发出请求 -> 自己 sidecar 路由规则 -> 目标 service ，就完成请求了。
现在只能找到的路线：请求者 pod 发出请求 -> **集群内任何 service** -> 那个 service pod 的 sidecar 路由规则 -> 目标 service 。
这个请求就多绕去了一个 pod 。有点失去了 mesh 的意义，我们之前用的统一 envoy gateway 就是这么工作的。

@ermeow #3 对，就是 path->service 的基本功能。
发现 virtual service 定义给 sidecar 的规则是放在 sidecar 的 ingress 里的？（不是 egress outbound ，有没有什么方法能 outbound 时就触发规则？）
如果 pod 里发出的请求想触发这些规则，就得先发给某个 pod 的 sidecar ingress 才行，然后才能通过规则找到真正的目标 service 。
*所以我想如果真的只能在 inbound 时使用规则，那请求 pod 自己的 sidecar inbound ，算是最小化路径了。

[nicholasxuu]

发现这就是官网上说的 mesh gateway （东西向），但是是 experimental feature ，需要开启 CRD 才能用。
但 CRD 的 github 链接又 404 了。。。

```
Note that this document uses the Gateway API to configure internal mesh (east-west) traffic, i.e., not just ingress (north-south) traffic. Configuring internal mesh traffic is an experimental feature of the Gateway API, currently under development and pending upstream agreement. Make sure to install the experimental CRDs before using the Gateway API:
$ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.6.1" | kubectl apply -f -
```

[nicholasxuu]

更新一下，又不理解了，看 jimmysong 的文档，东西网关 outbound handler 规则，route 和 endpoint 都在的，但是没法像文档里说的一样进行路由。
唯一的区别是，他说的是向 host=ratings.default.svc.cluster.local 的请求，我设定的路由是向自定义域名的 host=internal.service.com 这样的。pod 里就显示 dns 解析问题了。

[nicholasxuu]

解决了，最后发现是需要添加个 ServiceEntry ，把 internal-service-com(FQDN) 添加到 dns 里去。
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: testapi
namespace: fortune
spec:
hosts:
- "<my-fqdn>"
location: MESH_INTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS
然后 virtual service 的规则，在 outbound handler 是可以正常处理请求的。