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 filter is missing in these CRs, the CR EnvoyHTTPFilter can be used to prepend such a native Envoy filter. The CR EnvoyCluster allows configuring additional clusters if a native Envoy 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 filters that connect to an upstream service require configuring the corresponding cluster with CR EnvoyCluster.
  • Envoy filters that do their work without an external cluster do not need an EnvoyCluster configured.

Example configuration

The CR EnvoyCluster allows configuring additional Envoy clusters. This is only required if a CustomResource EnvoyHTTPFilter relies on that cluster.

  • The following example shows a simple CustomResource EnvoyCluster which configures the following:
  • The cluster ext-authz with the endpoint opa.service.internal:8099.
kind: EnvoyCluster
  name: ext-cluster-1
    name: ext-authz
    connect_timeout: 1s
    type: LOGICAL_DNS
      cluster_name: ext-authz
        - lb_endpoints:
            - endpoint:
                    address: opa.service.internal
                    port_value: 8099

The native Envoy 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 backend cluster.

Consult the Envoy documentation Envoy clusters for further information.

It is highly recommended to use the CRs EnvoyHTTPFilter and EnvoyClusters only if the feature is unavailable in our other CRs. In such cases, please create a support case and let us know the use case and which feature you are missing in our CRs.

See also the API Reference documentation link at the end of this article.

Reference in CR SidecarGateway

To apply a certain EnvoyCluster CR for a specific Microgateway Engine, it must be referenced in the corresponding SidecarGateway. The following example references two EnvoyClusters.

kind: SidecarGateway 
  name: my-sidecar-gateway
    - name: ext-cluster-1
    - name: ext-cluster-2

Referencing multiple CustomResources can be useful when integrating shared services like an external authorization service by reusing service integration configurations from different SidecarGateways.

See also the API Reference documentation link at the end of this article.