The ZoneEgress proxy is used to isolate outgoing traffic to Services in other zones or external Services in the local zone.
Since the
ZoneEgressproxy uses Server Name Indication (SNI) to route traffic, mTLS is required.
This proxy is not attached to any specific workloads, it’s bound to a specific zone. A zone egress can proxy traffic between all meshes, so you only need one deployment in each zone.
When a zone egress is present:
- In a multi-zone deployment, all requests sent from local data plane proxies to other zones will be directed through the local zone egress instance, which will then direct the traffic to the proper instance of the zone ingress.
- All requests that are sent from local data plane proxies to external Services available within the zone will be directed through the local zone egress instance.
The
ZoneEgressproxy currently is an optional component. In the future it will become required for using external services.
The ZoneEgress entity includes the following parameters:
-
type: Must beZoneEgress. -
name: The name of theZoneEgressinstance, it must be unique for any givenzone. -
networking: The networking parameters of the zone egress.-
address: The address of the network interface that the zone egress is listening on. -
port: The port that zone egress is listening on. -
admin: The parameters related to the Envoy Admin API.-
port: The port that the Envoy Admin API will listen to.
-
-
-
zone: The zone that the zone egress belongs to. This is auto-generated on the Kong Mesh control plane.
A ZoneEgress deployment can be scaled horizontally.
In addition to mTLS, there’s a configuration in the Mesh resource to route traffic through the ZoneEgress:
This configuration will force cross zone communication and external services to go through ZoneEgress.
If enabled but no ZoneEgress is available the communication will fail.