With ingress, you have the following schema:
User --------> load balancer ------ [[ kubernetes cluster ]] ------> istio ingress pod ----> application pod
load balancer is public (or at least private but on a network user are able to access)
kubernetes is fully private (user cannot access node/pod/service)
istio ingress pod receive only request from the load balancer ip.
With egress gateway, the schema may vary, for instance, let say you have private k8s, pod without routable network :
application pod -------> egress pod ---------> node --------> cloud network gateway ----> internet
private k8s with pod with routable network:
application pod -------> egress pod -------> cloud network gateway ----> internet
application pod -------> egress pod -------> node ----> internet
The “cloud network gateway” can be almost anything: a firewall (nat), a server with a corporate proxy (transparent proxy), … It is a component outside your cluster, is able to accept your packet and do something with it (deny them, nat them, inspect them …)
if you access an internet website, the website will see the ip of this cloud gateway
If you want to access a resource in the internal network, then you will have
application pod -------> egress pod -------> your resource LB
in both “your resource LB” and “cloud network gateway” you may want to filter the ip of the egress pod.
Well k8s do not have sticky ip … but it seems to be possible with calico… but not sure the configuration is available on managed k8s.
An option may to use network policy and add rules to prevent pod to access external except the egress gateway. but it can be tricky as the k8s network policies are namespaced, but again, there is calico extension to create a global policy.
If so, you will need to make the “resource LB” accept the full pod network CIDR knowing only egress can access.