Isovalent Enterprise for Cilium 1.15 adds physical topology awareness to the egress gateway selection process. Users can now rely on the well-known Node label topology.kubernetes.io/zone to augment the default traffic distribution in a group of HA egress gateways. This helps optimise latency and reduce cross-zone traffic costs. Introduction Hello, my name is Raphael Bon and I'm a technical marketing engineer at Isovalent. Today I want to tell you about new features related to Egress Gateway in Isovalent Enterprise for Cilium 1.15. Egress Gateway is a feature of Cilium that lets you exit a Kubernetes cluster through a specific egress IP for traffic from selected workloads to an external CIDR. This is especially useful if you have a firewall outside of the cluster, or maybe a database that is aware of the source IP and filters traffic based on it. One challenge with this is resiliency. In Isovalent Enterprise for Cilium, we already have HA for Egress Gateway, which lets traffic exit through multiple nodes and load balances across them. But what happens if you have multiple availability zones? Is there a risk that traffic from a workload in one zone gets routed through an egress node in another zone, adding latency? Demo setup To solve this, we've added topology-aware egress routing with affinity in Isovalent Enterprise for Cilium 1.15. It is based on the well-known Kubernetes label topology.kubernetes.io/zone. In our demo, we'll tag some compute nodes and egress nodes as east, and some others as west. We have an X-Wing workload running in the cluster, and we're going to add those labels to the nodes so that kind-worker and kind-worker3 are east, while kind-worker2 and kind-worker4 are west. Policy configuration Now we're going to write an Egress Gateway policy for high availability, and add the affinity parameter with localOnlyFirst. That makes traffic prefer an egress node in the same zone as the workload. If that's not possible, it falls back to a node in another zone. When we look at the status of the gateway policy, we can see which interfaces are active for the topology. Our X-Wing pod is currently running on a node in the east zone, so traffic should exit through kind-worker3. When I make a request from X-Wing to an echo server outside the cluster, it goes through the egress gateway associated with the east zone, so we can see the affinity working. But what about resilience? If the east egress gateway becomes unavailable, we can simulate that by pausing the container. When we make requests again, they still succeed, but this time they go through the west zone because there is no east egress node available. As soon as we make the east node available again, traffic returns to the east zone. So you can not only route traffic through known IP addresses and load balance across egress nodes, but also optimize latency with topology-aware affinity. Conclusion Even if one of the nodes in the same availability zone fails, traffic still goes through another node, so you keep the resilience of the system. That's it for today. You can test this feature in the updated Egress Gateway lab we have on Isovalent.com. Have fun and have a good day.