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 EnvoyCluster configured.

This CR needs to be referenced in the CR SidecarGateway.

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_authz on which the CustomResource EnvoyHTTPFilter relies.
  • The cluster ext-authz has the endpoint opa.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.

Consult the Envoy documentation Envoy clusters for further information.

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 backend cluster.