What is gateway targetPort used for?

1 
[root@master01 gateway]# kubectl explain gw.spec.servers.port
KIND:     Gateway
VERSION:  networking.istio.io/v1beta1

RESOURCE: port <Object>

DESCRIPTION:
     <empty>

FIELDS:
   name <string>
     Label assigned to the port.

   number       <integer>
     A valid non-negative integer port number.

   protocol     <string>
     The protocol exposed on the port.

   targetPort   <integer>
2

targetPort is the container bind port.

3

why do i need to specify the container bind por

4

Which container? The Envoy in the Pod selected by the Gateway (eg. via label istio: istio-ingressgateway) selector spec?

I’m asking because I recently installed Istio 1.7 (was running 1.4.3 prior) and my istio-ingressgateway log indicated a “Permission Denied” on port 143 and the Gateway & istio-ingressgateway LB had the port added via both Helm Chart pre-install Job (1.4.3) and an IstioOperator overlay resources for the 1.7 install. So the bind failure aborted the Pod’s configuration from istiod(Pilot) causing 503 errors as mTLS wasn’t properly configured. And I read in the 1.7 release notes about the changes affecting adding ports < 1024 within Gateways.

Perhaps I should ask this question first: Does an istio-ingressgateway-nnmm-fff Pod instance get created to serve the needs of an Istio Gateway resource to handle traffic coming in from a Ingress service? So if there are 2 Gateway resources each selecting the same svc (“istio-ingressgateway”), there will be 2 Pods instantiated, each using the targetPort values to bind listeners per my wordy description below.

Is my understanding correct that the Envoy Pod (eg. istio-ingressgateway-7f4c4db984-27b8n) will use the targetPort as the bind port to listen for traffic being routed by the mesh Ingress LoadBalancer Service and that incoming traffic received on that targetPort is treated as coming in on the Gateway’s matching port for the purposes of a VirtualService’s HttpMatchRequest configuration.
As this is what I’m seeing in an EKS cluster - the istio-ingressgateway Service’s listed ports are the ports used by a kube-proxy process listening on those listed ports. This kube-proxy is the Envoy container running within a containerd.shim Pod process.
So nothing else in an Istio mesh cares about a Gateway’s actual targetPort values? That’s what I’m missing currently. And the reason to specify a Gateway.servers.port.targetPort is to avoid duplicates across Gateway instances within a Node (so iptables routing will be correct), yes? I might be wrong as is it the case that the LB targetPort has to match the Gateway’s targetPort if it’s specified? And should I be provisioning these extra(custom) Ingress ports or just declare them in the Gateway and let an Istio controller add them to the selected (eg. istio-ingressgateway) LB Service?

For example, If I want to expose an IMAP service to external users, I can add a port: 143, targetPort: 1143, protocol: TCP, name: tcp-imap item to the ports array in the istio-ingressgateway resource. And add to a Gateway that selects that istio-ingressgateway Service a servers array element whose port.number: 143 - so a VirtualService can match on the port 143, regardless of what targetPort was used by the Gateway. Right?

My apologies for the length of this post, I’m a bit obsessed on the details. as they matter.
Thanks.