Istio和(或) Nginx侵入控制器

Question

我正在测试Istio，现在我要测试路由流量的“金丝雀”能力。

为了进行测试，我创建了一个由5个微服务(serviceA、serviceB、serviceC、serviceD、serviceE)组成的小servicemesh。每个人都能打电话给其他人。我只是传递一个像A，E，C，B，B，D这样的路径，请求遵循这个路径。为了从集群外部调用servicemesh，我有一个，其中有一个在serviceA pod上指向的In规则

这很好用。

我所面临的问题涉及使用如下自定义头匹配的流量切换：

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内部请求设置为true时，我想尝试将流量路由到v2版本的ServiceA。

问答：

• 为了使用这个特性，我的服务是否必须知道x内部标头，它们是否必须将它传递给请求中的下一个服务？或者他们不需要因为Istio为他们做这件事而去处理它？
• 为了使用这个特性，我是否需要使用Istio入口控制器(与Istio网关一起使用)而不是Nginx侵入控制器？

今天，我将使用Nginx侵入控制器公开我的一些服务。我们选择Nginx是因为它有一些特性，比如“外部授权”，这样可以节省我们很多工作，如果我们需要使用Istio instead控制器，我不确定它提供了与Nginx相同的特性。

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

谢谢你的帮助

Answer 1

Istio被设计为使用部署在每个Pod上的Envoy作为sidecars来拦截和代理服务网格中微服务之间的网络流量。

您也可以通过HTTP headers对请求和响应进行Envoy操作。根据正式的文档，可以按照以下顺序将自定义头添加到请求/响应中:加权集群级标头、路由级标头、虚拟主机级标头和最后的全局级标头。因为您的Envoy代理是以sidecar的形式部署在每个相关服务Pod上的，因此自定义HTTP header应该传递给每个请求或响应。

我建议使用Istio进位控制器及其核心组件Istio Gateway，该组件通常用于在Istio网格服务中启用监视和路由规则特性。

GitHub上出现了一个关于mesh服务中Nginx Ingress controller的实现和路由请求问题的问题。