On this page
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 (Gloo Platform APIs), 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 Solo 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 |
|---|---|---|---|---|---|---|
AllowVirtualDestinationWithoutSelectorsRouting | false | GA | 2.12.0 | Allows routing to VirtualDestinations that have no backing service selectors. You can reference VirtualDestinations in RouteTables where the actual service resolution is delegated to Istio via global services. This feature can be useful during migration from VirtualDestinations in Gloo Mesh (Platform APIs) to ambient multicluster peering with ztunnel-based east-west gateways, because it helps preserve policy application and status tracking during migration. After you enable this feature, you can create VirtualDestinations without selectors, reference the VirtualDestinations in RouteTables, and use Istio to resolve the VirtualDestination hostname via peering ServiceEntries or global services. | Gloo management server | |
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 | |
ImportedVirtualDestinationPolicyLegacyMode | false | GA | 2.10.0 | Legacy mode preserves a bug in which client-side policies are not properly applied to VirtualDestinations that are imported from one workspace to another, when no backing service for the VirtualDestination exists in the local cluster. This bug was fixed so that the importing behavior matches the expected behavior as described in the docs. The fix can impact the DestinationRules that are translated from the client-side policies as follows.
true before upgrading. Note that the legacy mode is deprecated and planned to be removed in version 2.11. | Gloo management server | |
InsightsConfiguration | false | Alpha | 2.5.0 | 2.9.0 | Configure settings for the insights engine. | Gloo management server |
NamespaceOffboarding | false | GA | 2.11.2 | Enables namespace offboarding so that you can exclude namespaces from reconciliation by labeling them with context.mesh.gloo.solo.io/reconciliation-disabled=true (to disable) or context.mesh.gloo.solo.io/reconciliation-disabled=dry-run (for dry-run mode). When enabled, both the management server and agents maintain a namespace cache to filter resource writes. Enabling this feature may have a performance impact. | Gloo management server, Agent | |
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 | |
StrictRelayLoadBalancing | false | Alpha | 2.12.0 | Fixes a bug in relay server load balancing where the connection count was checked before accounting for the incoming connection. When enabled, this feature enforces stricter 1:1 agent-to-management-pod connections when the number of agents equals the number of management replicas. This ensures optimal load distribution in environments with large numbers of clusters and namespaces. When disabled (default), load balancing uses the previous behavior, which allows slightly more flexibility but might result in uneven distribution. If you require strict 1:1 connections, such as with many clusters and namespaces per cluster, enabling this feature is recommended. If you observed successful failover behavior during pod unavailability with the existing load balancing method, keep this feature disabled. | Gloo management server | |
VirtualDestinationOffboardingEnabled | false | GA | 2.12.0 | When enabled, the solo.io/prefer-other: true annotation can be propagated to ServiceEntries that are generated from VirtualDestinations. This annotation indicates to Istio that generated ServiceEntry resources are de-prioritized if other ServiceEntries exist for the same host. In this way, you can offboard or deprioritize Gloo Mesh (Platform APIs) ServiceEntries in favor of your own custom ServiceEntries.The annotation can be set at two levels with the following inheritance:
| Gloo management server |