VirtualService在启用相互TLS和HTTPS端口名称的Mesh中未被识别。

huangapple go评论53阅读模式
英文:

VirtualService not recognized in mesh with mutualTLS and https port name

问题

在我们的Kubernetes集群中,我们使用Istio,并在网格内的Pod之间使用相互TLS进行通信。一切都运行正常,但现在我们想引入一个VirtualService以便为金丝雀部署进行流量转移。

注意,我们只谈论网格内的流量,没有外部流量,它完全是在同一命名空间中的Pod之间。

我们的设置:

应用程序的服务 'parser-service'

# 服务 parser-service
spec:
  clusterIP: 172.20.181.129
  ports:
  - name: https-web
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    service: parser-service
  type: ClusterIP

金丝雀版本的服务

# 服务 parser-service-canary
spec:
  clusterIP: 172.20.30.101
  ports:
  - name: https-web
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    service: parser-service-canary
  type: ClusterIP

这是我们尝试的,应该将流量分割为50/50的VirtualService

spec:
  gateways:
  - mesh
  hosts:
  - parser-service
  tls:
  - match:
    - port: 80
      sniHosts:
      - parser-service
    route:
    - destination:
        host: parser-service
        port:
          number: 80
      weight: 50
    - destination:
        host: parser-service-canary
        port:
          number: 80
      weight: 50

我认为我们理解错了一些东西,但我们无法弄清楚是什么。流量仍然完全路由到parser-service,istioctl x describe pod parser-service-xxx-xxx也不显示VirtualService,这让我认为VirtualService被忽略了。

Pod: parser-service-7cfd596dbb-hjqd9
   Pod Revision: 1-14-6
   Pod Ports: 8080 (parser-service), 15090 (istio-proxy)
Suggestion: add 'version' label to pod for Istio telemetry.
--------------------
Service: parser-service
   Port: https-web 80/HTTPS targets pod port 8080
DestinationRule: istio-mutual for "*.mynamespace.svc.cluster.local"
   Traffic Policy TLS Mode: ISTIO_MUTUAL
--------------------
Effective PeerAuthentication:
   Workload mTLS mode: PERMISSIVE

我认为这与我们将端口命名为https-web有关,以便Istio sidecars之间的流量是加密的。当我们使用'http-web'作为端口名称并在VirtualService中使用HTTP匹配而不是tls时,流量分割工作正常。

希望得到任何指示或指向正确方向的指针。

英文:

In our kubernetes cluster we are using istio, with mutual tls for the communication between the pods inside the mesh. Everything is working fine, but now we would like to introduce a VirtualService to able to do traffic shifting for canary deployments.
We configured everything according to the istio documentation, but for some reason, the VirtualService seems just to be ignored, our canary version does not receive any traffic, even with a 50/50 traffic split.

Note, we are only talking about traffic inside the mesh, there is no external traffic, it's exclusively between pods in the same namespace.

Our setup:

Service of our application 'parser-service'

# service parser-service
spec:
  clusterIP: 172.20.181.129
  ports:
  - name: https-web
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    service: parser-service
  type: ClusterIP

Service of the canary version

# service parser-service-canary
spec:
  clusterIP: 172.20.30.101
  ports:
  - name: https-web
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    service: parser-service-canary
  type: ClusterIP

This is what we tried, a VirtualService that should split traffic 50/50

spec:
  gateways:
  - mesh
  hosts:
  - parser-service
  tls:
  - match:
    - port: 80
      sniHosts:
      - parser-service
    route:
    - destination:
        host: parser-service
        port:
          number: 80
      weight: 50
    - destination:
        host: parser-service-canary
        port:
          number: 80
      weight: 50

I think we misunderstood something, but we can't figure out what it is. The traffic is still routed 100% to parser-service and istioctl x describe pod parser-service-xxx-xxx also shows no VirtualService, which suggests to me that the VirtualService is just ignored.

Pod: parser-service-7cfd596dbb-hjqd9
   Pod Revision: 1-14-6
   Pod Ports: 8080 (parser-service), 15090 (istio-proxy)
Suggestion: add 'version' label to pod for Istio telemetry.
--------------------
Service: parser-service
   Port: https-web 80/HTTPS targets pod port 8080
DestinationRule: istio-mutual for "*.mynamespace.svc.cluster.local"
   Traffic Policy TLS Mode: ISTIO_MUTUAL
--------------------
Effective PeerAuthentication:
   Workload mTLS mode: PERMISSIVE

I think it has something to do with the fact that we named our ports https-web so that the traffic between the istio-sidecars is encrypted. When we use 'http-web' as port names and HTTP Match instead of tls in the VirtualService, the traffic split works fine.

Would appreciate any hints or pointers in the right direction

答案1

得分: 2

正如你建议的那样,Istio通过协议名称获取协议信息,并尝试在端口80/8080上使用HTTPS。你应该将它们命名为http-web。此外,你的虚拟服务想要通过TLS-SNI标头匹配端口80的流量。不要使用tls匹配器,而是使用http匹配器,并让它使用主机标头捕获流量,然后将其分发到两个版本。Istio将确保在启用Istio的两个Pod之间添加mTLS(假设你的trafficPolicy设置为ISTIO_MUTUAL,在istioctl输出中似乎是正确的)。

英文:

As you suggested, Istio derives protocol information from the protocol name and will try to use HTTPS on your port 80/8080. You should name them http-web.
Additionally, your VS wants to match traffic via TLS-SNI-header on a port 80. Don't use a tls matcher but a http matcher and let it use the host-header to capture your traffic and then distribute to both versions.
Istio will take care to add mTLS between two Istio-enabled pods (given that your trafficPolicy is set to ISTIO_MUTUAL which seems to be true in your istioctl output.

huangapple
  • 本文由 发表于 2023年4月7日 04:42:33
  • 转载请务必保留本文链接:https://go.coder-hub.com/75953604.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定