CR EnvoyCluster
The Envoy proxy is the basis for the Microgateway Engine. It has been enriched with Airlock-specific features which can be configured with the corresponding CRs. If a feature available as a native Envoy HTTP filter is missing in these CRs, the CR EnvoyHTTPFilter can be used to prepend such a native Envoy HTTP filter. The CR EnvoyCluster allows configuring additional clusters if a native Envoy HTTP filter relies on it. For the CRs EnvoyHTTPFilter and EnvoyCluster, the Envoy configuration language must be used.
When do I have to configure an EnvoyCluster?
- Envoy HTTP filters that connect to an upstream service require configuring the corresponding cluster with CR EnvoyCluster.
- Envoy HTTP filters that do their work without an external cluster do not need an
EnvoyClusterconfigured.
You should use the CRs EnvoyHTTPFilter and EnvoyClusters only if a feature is unavailable in our other CRs. In such cases, contact our Support and let us know the use case and which feature you are missing in our current CRs.
Example configuration
For the default and an example configuration, see CR EnvoyCluster reference documentation.
The example covers:
- Configuration of an additional Envoy cluster
ext_authzon which the CustomResourceEnvoyHTTPFilterrelies. - The cluster
ext-authzhas the endpointopa.service.internal:8099.
The native Envoy HTTP filter and cluster are defined in the value section in raw types. The Microgateway Operator validates only the YAML syntax and if the input can be unmarshalled to the corresponding proto type.
By default, every CustomResource SidecarGateway results in a cluster named backend in the Envoy configuration, which points to the upstream application.
- Clusters with the same name overwrite previously defined clusters!
- It is not possible to overwrite the Airlock Microgateway default
backendcluster.