Using Envoy Gateway
- Tier: Free, Premium, Ultimate
- Offering: GitLab Self-Managed
- Status: Beta
GitLab chart bundles the official Envoy Gateway to support migrating from the bundled NGINX Ingress towards Gateway API.
Upgrade the Envoy Gateway CRDs
Helm does not upgrade custom resource definitions (CRDs) after installation. For more information, see the Helm documentation. GitLab chart installs the Envoy Gateway and Gateway API CRDs on a new installation only. When a GitLab chart release bundles a new Envoy Gateway version, upgrade the CRDs yourself.
To upgrade the CRDs:
Find the Envoy Gateway version that the target GitLab chart version bundles. It is the
gateway-helmdependency inChart.yaml.Apply the CRDs for that version, before you run
helm upgrade:helm template eg-crds oci://docker.io/envoyproxy/gateway-crds-helm \ --version v1.9.0 \ --set crds.gatewayAPI.enabled=true \ --set crds.envoyGateway.enabled=true \ | kubectl apply --server-side -f -If Helm installed the CRDs, Helm owns their fields and server-side apply reports conflicts. Add
--force-conflictstokubectl applyto take ownership of those fields.Upgrade the GitLab chart.
Outdated CRDs cause one of two failures:
- The upgrade fails when the chart renders a resource kind or API version that the CRDs do not
serve. For example, GitLab chart 10.3 renders the GitLab Shell
TCPRouteasgateway.networking.k8s.io/v1, which the Gateway API 1.5 CRDs from Envoy Gateway 1.8 do not serve. The upgrade fails withno matches for kind "TCPRoute" in version "gateway.networking.k8s.io/v1". - The upgrade succeeds, but the API server prunes fields that the CRDs do not define. Kubernetes
drops these fields without an error, so the setting has no effect and the resource looks correct
in Helm output. For example, GitLab chart 10.3 sets
stripTrailingHostDoton the WebserviceClientTrafficPolicyresources, which the Envoy Gateway 1.8 CRDs do not define.
Use Envoy Gateway with GitLab
For information on using Envoy Gateway with GitLab, see: