为 Istio Mesh 中 pod 的传出请求重写主机和端口

Rewrite host and port for outgoing request of a pod in an Istio Mesh

我必须获取现有的微服务 运行。它们以 docker 图像的形式给出。 他们通过配置的主机名和端口相互交谈。 我开始使用 Istio 来查看和配置每个微服务的呼出。 现在我需要重写/重定向主机和从一个容器发出的请求的端口。 我如何使用 Istio 做到这一点?

我会尽量举一个最简单的例子。 有两个服务,service-a和service-b。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-b
spec:
  selector:
    matchLabels:
      run: service-b
  replicas: 1
  template:
    metadata:
      labels:
        run: service-b
    spec:
      containers:
        - name: service-b
          image: nginx
          ports:
            - containerPort: 80
              name: web
---
apiVersion: v1
kind: Service
metadata:
  name: service-b
  labels:
    run: service-b
spec:
  ports:
    - port: 8080
      protocol: TCP
      targetPort: 80
      name: service-b
  selector:
    run: service-b

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-a
spec:
  selector:
    matchLabels:
      run: service-a
  replicas: 1
  template:
    metadata:
      labels:
        run: service-a
    spec:
      containers:
        - name: service-a
          image: nginx
          ports:
            - containerPort: 80
              name: web
---
apiVersion: v1
kind: Service
metadata:
  name: service-a
  labels:
    run: service-a
spec:
  ports:
    - port: 8081
      protocol: TCP
      targetPort: 80
      name: service-a
  selector:
    run: service-a

我可以docker执行到service-a并成功执行:

root@service-a-d44f55d8c-8cp8m:/# curl -v service-b:8080

< HTTP/1.1 200 OK
< server: envoy

现在,为了模拟我的问题,我想使用另一个主机名和端口访问服务 b。我想按照此调用的方式配置 Istio:

root@service-a-d44f55d8c-8cp8m:/# curl -v service-x:7777

此致, 克里斯蒂安

根据使用 istio 功能的必要性,可以使用两种解决方案。

如果没有istio特性打算使用,可以使用原生kubernetes解决。反过来,如果打算使用某些istio特性,则可以使用istio virtual service来解决。以下是两个选项:


1.原生 kubernetes

Service-x 应该指向 service-b 部署的后端。下面是 selector 指向 deployment: service-b:

apiVersion: v1
kind: Service
metadata:
  name: service-x
  labels:
    run: service-x
spec:
  ports:
    - port: 7777
      protocol: TCP
      targetPort: 80
      name: service-x
  selector:
    run: service-b

无论如何请求都会通过 istio,因为注入了 sidecar 容器。

# curl -vI service-b:8080

*   Trying xx.xx.xx.xx:8080...
* Connected to service-b (xx.xx.xx.xx) port 8080 (#0)
> Host: service-b:8080
< HTTP/1.1 200 OK
< server: envoy

# curl -vI service-x:7777

*   Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 200 OK
< server: envoy

2。 Istio 虚拟服务

在此示例中使用 virtual service。服务 service-x 仍然需要创建,但现在我们不指定任何选择器:

apiVersion: v1
kind: Service
metadata:
  name: service-x
  labels:
    run: service-x
spec:
  ports:
    - port: 7777
      protocol: TCP
      targetPort: 80
      name: service-x

从另一个 pod 测试它:

# curl -vI service-x:7777

*   Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 503 Service Unavailable
< server: envoy

503 预期的错误。现在创建 virtual service,它将在 port: 8080:

上将请求路由到 service-b
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: service-x-to-b
spec:
  hosts:
  - service-x
  http:
  - route:
    - destination:
        host: service-b
        port:
          number: 8080

从 pod 测试:

# curl -vI service-x:7777

*   Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 200 OK
< server: envoy

看到它按预期工作。


有用的链接: