You are browsing documentation for an older version. See the latest documentation here.
Zone Egress
ZoneEgress
proxy is used when it is required to isolate outgoing traffic (to services in other
zones or external services in the local zone).
Because
ZoneEgress
uses Service Name Indication (SNI) to route traffic, mTLS is required.
This proxy is not attached to any particular workload. In multi-zone the proxy is bound to a specific zone. Zone Egress can proxy the traffic between all meshes, so we need only one deployment for every zone.
When Zone Egress is present:
- In multi-zone, all requests that are sent from local data plane proxies to other zones will be directed through the local Zone Egress instance, which then will 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.
Currently
ZoneEgress
is a purely optional component. In the future it will become compulsory for using external services.
The ZoneEgress
entity includes a few sections:
-
type
: must beZoneEgress
. -
name
: this is the name of theZoneEgress
instance, and it must be unique for any givenzone
. -
networking
: contains networking parameters of the Zone Egress-
address
: the address of the network interface Zone Egress is listening on. -
port
: is a port that Zone Egress is listening on -
admin
: determines parameters related to Envoy Admin API-
port
: the port that Envoy Admin API will listen to
-
-
-
zone
[auto-generated on Kong Mesh CP] : zone where Zone Egress belongs to
A ZoneEgress
deployment can be scaled horizontally.
In addition to MTLS, there’s a configuration in the Mesh
policy 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.