Istio和（或与之相对）Nginx入口控制器

Question

我正在测试Istio，目前正在测试路由流量的“ canary”功能。

为了进行测试，我创建了一个由5个微服务（serviceA，serviceB，serviceC，serviceD，serviceE）组成的小型服务网格。每个人都可以呼叫其他人。我只传递了A，E，C，B，B，D之类的路径，并且请求遵循该路径。为了从集群外部调用我的servicemesh，我有一个Nginx Ingress Controller，其Ingress规则指向serviceA pod。

一切正常。

我面临的问题与使用自定义标头匹配的流量切换有关，如下所示：

kind: VirtualService
metadata:
  name: ServiceA
  namespace: demo
  labels:
    app: demo
spec:
  hosts:
  - service-a
  http:
  - route:
    - destination:
        host: service-a
        subset: v1
  - match:
    - headers:
        x-internal-request:
          exact: true
    route:
    - destination:
        host: service-a
        subset: v2

所以在这里，当我将自定义标头x-internal-request设置为true 时，我想尝试将流量路由到ServiceA的v2版本。

问题：

• 为了使用此功能，我的服务是否必须知道x-internal-header，并将它们传递给请求中的下一个服务？还是因为Istio为他们完成工作，他们不需要处理它？

• 为了使用此功能，我是否需要使用Istio Ingress Controller（带有Istio网关）而不是Nginx Ingress Controller？

今天，我正在使用Nginx Ingress Controller公开一些服务。我们之所以选择Nginx，是因为它具有“外部授权”之类的功能，可以节省很多工作，并且如果我们需要使用Istio Ingress控制器，我不确定它是否提供与Nginx相同的功能。

也许有一条我看不到的中间道路

谢谢您的帮助

Answer 1

Istio设计用于Envoy部署在每个Pod上，sidecars以拦截和代理服务网格中微服务之间的网络流量。

您也可以HTTP headers通过来处理请求和响应Envoy。根据官方文档，可以按以下顺序将自定义标头添加到请求/响应：加权群集级别标头，路由级别标头，虚拟主机级别标头以及最终全局级别标头。因为您的Envoy代理部署在的每个相关服务Pod上sidecar，所以custom HTTP header应该传递给每个请求或响应。

我建议使用Istio Ingress Controller及其核心组件Istio Gateway，该组件通常用于启用Istio网状服务中的监视和路由规则功能。

GitHub上存在一个有关Nginx Ingress controllerin mesh服务的实现以及路由请求问题的问题。