Why is containerPort required for server?

[jpreese]

Small clarification as this has bugged me a little. I noticed that the containerPort for web-ui isn't needed. If you remove it, you can still access the front end just fine and get a response from the gRPC service.

If you remove it from the server.yaml however, you can no longer call the service. The only real difference I can see is the server is using the grpc-web filter.

[venilnoronha]

I think this is related to istio/istio#6259. The discrepancy in the behavior could be due to how the filter configuration logic is implemented in Istio itself.

[jpreese]

That is what I was assuming, an issue with Istio, or that http filters have some sort of dependency on containerPort to route traffic after its done filtering.

From the linked issue:

Correct, k8s spec does not mandate the containerPorts to be listed, Istio requires it, so it can add the ports to the list of inboundPorts.

I did notice this as well. I did a kubectl log on the istio-init for the sidecars and saw INBOUND_PORT was set to 80, but again, at least with the UI still let traffic come in.

Does Istio provide any way to see exactly where this falls down? I don't necessarily mind that it's required, I'm just not able to actually prove it. For example, I did a kubectl log on the gateway and saw it returned a 503, then I did a kubectl log on the istio sidecar, but I'm not seeing any traffic, so it's not even getting to the side car as far as I can tell.

Which also leads me to believe the grpc-web filter happens before entering the pod? Though in your architecture diagram in your blog post for this, the filter is in the envoy sidecar.