Feature gates
Review the required Gloo versions for gated features that you can optionally enable in the gloo-platform and gloo-platform-crds Helm charts.
In the featureGates Helm setting, you specify a key-value pair, in which the key is the feature name, and the value is a boolean to enable or disable the feature. For example, to onboard external workloads with Gloo Mesh Enterprise, you set --set featureGates.ExternalWorkloads=true in your helm install command, or set featureGates.ExternalWorkloads to true in your Helm values file. Note that the featureGates section replaces the deprecated experimental section in the gloo-platform Helm chart.
For more information about the Helm chart, see the Helm value reference. For more information about features that are in alpha or beta support, see Gloo feature maturity.
For some features, you must enable the feature gate in both the gloo-platform chart and the gloo-platform-crds Helm chart, because the feature requires a specific CRD that is not installed by default. Review the feature description in the following table to check whether the feature gate must be enabled in gloo-platform-crds too.
| Feature | Default value | Maturity | Since | Until | Description | Used by |
|---|---|---|---|---|---|---|
EnableDefaultTcpKeepalive | false | GA | 2.7.0 | When this flag is enabled, all VirtualDestinations are configured with TCPKeepalive by default, with the probes field set to 9 and the time and interval fields set to 180s. To override these values for a given VirtualDestination, configure a ConnectionPolicy. | Gloo management server | |
GatewayDefaultDenyAllHTTPRequests | false | GA | 2.5.0 | In Gloo Mesh Gateway, apply external auth or JWT policies to enable traffic for specific routes. This feature ensures ongoing security, even in the event of errors like policy deletion or Envoy filter issues. By default, all existing routes bypass this mechanism. To onboard routes to this new feature, you must label your HTTP routes with the reserved 'gateway.gloo.solo.io/require_auth': 'true' label. Once labeled, routes become subject to the dynamic default deny behavior, reinforcing security. | Gloo management server | |
InsightsConfiguration | false | Alpha | 2.5.0 | Configure settings for the insights engine. | Gloo management server | |
ResolveEastWestHostConflicts | false | GA | 2.6.6 | When this flag is enabled, additional strict validation and conflict resolution is performed on VirtualDestinations, ExternalWorkloads, and ExternalServices. This validation can detect whether two workspaces define the same destination hostname and port, and are exposed on the same east-west gateway at the same time. Normally, this is not considered a conflict. However, a bug was identified in Istio version 1.22 and lower where overlapping ServiceEntries are created that are rejected by Envoy. As a workaround, you can enable strict validation for east-west hostnames and ports to ensure that only one (the oldest) VirtualDestination, ExternalService, or ExternalWorkload can define a hostname and port that is exposed on the east-west gateway. If a conflict exists, the conflict is shown as a warning in the VirtualDestination, ExternalService, or ExternalWorkload resource that attempts to define the conflicting hostname and port. | Gloo management server | |
SafeModeAutoSkipWarming | true | Alpha | 2.6.0 | When this flag is enabled, the Gloo management server automatically excludes workload clusters that were never connected to the management server from Redis safe mode. This setting allows you to seamlessly onboard new clusters without setting the skipWarming field on the corresponding KubernetesCluster resource. NOTE: Enable this field only after you successfully upgraded to 2.6.0 and all workload clusters are reconnected to the Gloo management server and their input snapshots are present in Redis. | Gloo management server |