Kubernetes service port re-mapping and pod IP/port

[awprice]

I'm not sure if this is a bug or the intended behavior of Istio, so I've opted to make this a discussion rather than a bug.

We have a Kubernetes workload (Contour ingress) that communicates with other Kubernetes workloads via the pod IP and port of the workload rather than through a service IP.

We have Istio for performing mTLS between workloads.

When we've configured the port of the service to match the target port, e.g.

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  type: ClusterIP
  selector:
    app: example-service
  ports:
    - name: http
      port: 9898
      protocol: TCP
      targetPort: 9898

The workload is able to successfully connect to the pod IP and port through Istio when the above is used.

However, when the service is using port remapping, i.e. the port on the service being different to the port on the container, e.g.

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  type: ClusterIP
  selector:
    app: example-service
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 9898

The workload is unable to connect to the pod IP and pod port. We see the requests go through the PassThrough cluster in Istio and because we have strict mTLS enabled, the request is blocked when it reaches the pod.

It seems like Istio isn't configuring an outbound endpoint for the pod IP and port when the remapping is present in the Service object which leads to the request going through the PassThrough cluster.

We've worked around this by ensuring that no re-mapping is occurring in the Service objects, but we're after an explanation for why this is occurring.

[howardjohn]

Istio effectively doesn't support "to pod" traffic. It essentially happens to work in some cases. https://istio.io/latest/docs/ops/configuration/traffic-management/traffic-routing/ explains it a bit

[awprice]

@howardjohn Thanks mate - that makes sense and I suspected that was going to be the case