For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

View supported Solo Enterprise for kgateway versions and their release cycle.

Review the following information about supported release versions for Solo Enterprise for kgateway, and supported versions of different open source projects within each release.

* Gateway API: The upstream kgateway project is conformant to the Kubernetes Gateway API specification.

• The Standard channel versions are supported and tested for the given Solo Enterprise for kgateway release.
• The Experimental channel of the highest supported Standard channel version of a release is compatible with Solo Enterprise for kgateway. Experimental channel features from other Gateway API versions, such as XListenerSet from a version other than the highest supported Standard channel version, are not guaranteed to be compatible.For the experimental features that are available in each Gateway API version, see Experimental features in Gateway API.

† OpenShift: Support depends on the underlying versions of Kubernetes, Gateway API, and Istio that the OpenShift Container Platform version includes. For more information, see OpenShift.

Image version compatibility

When you configure custom EnterpriseKgatewayParameters resources to deploy extension components such as external auth, rate limiting, or caching, you must specify compatible image versions. The following table lists the image versions for each component that are compatible with the current Solo Enterprise for kgateway release.

Solo Enterprise for kgateway

Solo Enterprise for kgateway offers n-3 patching support for bug and critical security fixes. In other words, the current release and the three previous releases of Solo Enterprise for kgateway are supported.

New features are not developed on or backported to stable branches. However, critical patches, bug fixes, and documentation fixes are backported to all actively supported branches.

Kubernetes

Solo Enterprise for kgateway is supported and tested with the latest Kubernetes version at the time of the Solo Enterprise for kgateway release, and all Kubernetes versions that were released up to 1 year before the latest version.

Envoy

By default, Solo Enterprise for kgateway offers support for n-1 of Envoy community releases. In specific support situations, fixes can be backported to n-2 or more without bumping the Envoy minor version. In other words, a fix can be developed based on the code that you deployed within the n-2 release timeframe.

Istio

Istio must run on a compatible version of Kubernetes. For example, Istio 1.27 is tested, but not supported, on Kubernetes 1.28. For more information, see the Istio docs.

OpenShift

Red Hat OpenShift Container Platform and Service Mesh include underlying versions of Kubernetes, Gateway API, and Istio. Make sure that these underlying versions are supported for the version of Solo Enterprise for kgateway that you want to use. For more information, check the release notes for the OpenShift Container Platform version that you are using.

In particular, keep in mind the following considerations by OpenShift version.

Image variants

Distroless

By default, the Solo Enterprise for kgateway control and data planes deploy with distroless images. Distroless images do not contain package managers, shells, or any other programs that are generally found in a standard Linux distribution. The use of distroless variants is a standard practice adopted by various open source projects and proprietary applications.

FIPS

You can optionally update the images that the Solo Enterprise for kgateway control or data plane deploy with to use fips images instead.

A fips image complies with National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS), for use cases that require federal information processing capabilities. For example, you might provide a cloud service that runs in a Federal Risk and Authorization Management Program (FedRAMP) regulated environment. In such cases, you can use Solo Enterprise for kgateway’s FIPS images without the need for any additional tooling or CLIs.

To install and verify FIPS images, see FIPS images. In versions 2.3.0 through 2.3.3, set each image yourself as described in the following steps.

Deploy a specific image variant

Update the image that you use for a particular Solo Enterprise for kgateway component.

Control plane

To change the image that the Solo Enterprise for kgateway control plane uses, update the Helm values of your Solo Enterprise for kgateway installation.

1. Get the values file for your current version.

   helm get values enterprise-kgateway -n kgateway-system -o yaml > values.yaml
   open values.yaml

2. Add the following snippet to your Helm values file. Note that the repository includes the -fips suffix.

   
   controller: 
     image: 
       registry: us-docker.pkg.dev/solo-public/enterprise-kgateway
       repository: enterprise-kgateway-controller-fips
       tag: "2.3.5"

3. Upgrade the control plane Helm installation.

   helm upgrade -i -n kgateway-system enterprise-kgateway oci://us-docker.pkg.dev/solo-public/enterprise-kgateway/charts/enterprise-kgateway \
   -f values.yaml \
   --version 2.3.5

Data plane

By default, the proxy is deployed with one container envoy-wrapper that proxies incoming traffic. In addition, Solo Enterprise for kgateway creates external auth and rate limiting servers for each GatewayClass that is referenced by a Gateway.

In version 2.3.4 and later, a FIPS control plane selects the FIPS data plane images for you. For details, see How the control plane selects FIPS images. In versions 2.3.0 through 2.3.3, set each image as described in the following steps.

To update the images that the proxy uses, or to update the external auth and rate limiting images, you use an EnterpriseKgatewayParameters resource and then deploy or update your Gateway to reference that resource.

1. Create an EnterpriseKgatewayParameters resource and define the image for each container that you want to use. The envoy-wrapper requires the -fips suffix in the repository. The external auth and rate limiting servers use their own -fips image repositories and the Solo Enterprise for kgateway version as the tag.

   kubectl apply -f- <<EOF
   apiVersion: enterprisekgateway.solo.io/v1alpha1
   kind: EnterpriseKgatewayParameters
   metadata:
     name: fips
     namespace: kgateway-system
   spec:
     kube:
       # main container in gateway proxy
       envoyContainer:
         image:
           registry: us-docker.pkg.dev/solo-public/enterprise-kgateway
           repository: envoy-wrapper-fips
           tag: "2.3.5"
           pullPolicy: IfNotPresent
       # proxy extensions, such as redis cache, external auth and rate limiting service
       sharedExtensions:
         extauth:
           container:
             image:
               registry: us-docker.pkg.dev/solo-public/enterprise-kgateway
               repository: ext-auth-service-fips
               tag: "2.3.5"
         ratelimiter:
           container:
             image:
               registry: us-docker.pkg.dev/solo-public/enterprise-kgateway
               repository: rate-limiter-fips
               tag: "2.3.5"
   EOF

2. Create a GatewayClass resource that references the EnterpriseKgatewayParameters resource.

   kubectl apply -f- <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: GatewayClass
   metadata:
     name: custom-enterprise-kgateway
     namespace: kgateway-system
   spec:
     controllerName: solo.io/enterprise-kgateway
     parametersRef:
       group: enterprisekgateway.solo.io
       kind: EnterpriseKgatewayParameters
       name: fips
       namespace: kgateway-system
   EOF

3. Create a Gateway with your custom GatewayClass.

   kubectl apply -f- <<EOF
   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: fips
     namespace: kgateway-system
   spec:
     gatewayClassName: custom-enterprise-kgateway
     listeners:
     - protocol: HTTP
       port: 8080
       name: http
       allowedRoutes:
         namespaces:
           from: All
   EOF

4. Verify that your gateway is deployed with your custom images.

   kubectl get deploy/fips -n kgateway-system -o yaml
   kubectl get deployments -n kgateway-system \
     -l 'app in (ext-auth-service,rate-limiter)' \
     -o yaml

Portal

To install the portal with FIPS images, see Install the FIPS portal. In versions 2.3.0 through 2.3.3, the portal controller does not select the web server image for you, so also set spec.webServer.container.image.repository to portal-web-server-fips on a PortalParameters resource, and set spec.authServer.container.image.repository to the same value if you deploy the auth server.

Release cadence

Solo Enterprise for kgateway releases are built on the OSS codebase and typically follow the equivalent OSS release. The OSS version is released as the latest build, while the Enterprise version is released as the first stable build of that version.

Release development

Alpha and beta release process

New features for Solo Enterprise for kgateway and OSS are developed on main.

• For Enterprise, new features are often first released as beta builds. You can use these beta builds to test new features, or wait until the feature is released with the next stable Enterprise minor version.
• For OSS, new features are released as patches off of main.

To receive feedback and improve functionality for real use cases, these features are often released according to a feature maturity model. As the features are improved and stabilized, they are gradually moved through the stages of alpha, beta, and general availability (GA) support. Review the following table for the comparison points between each stage of feature maturity. To see the maturity of a feature, check the feature’s documentation.

Stable release process

Development of a quality stable release on main typically follows this process:

1. New feature development is suspended on main.
2. Release candidates are created, such as .0-rc1, .0-rc2, and so on.
3. A full suite of tests is performed for each release candidate. Testing includes all documented workflows, a test matrix of all supported platforms, and more.
4. Documentation for that release is prepared, vetted, and staged.
5. The stable minor version is released.
6. Feature development on main is resumed.

Experimental features in Gateway API

The following features are experimental in the upstream Kubernetes Gateway API project, and are subject to change.

* - Instead of ListenerSets, you can use EnterpriseListenerSets for when you run an older version or non-experimental channel of Gateway API, such as on OpenShift Container Platform. Then, when you have Gateway API 1.5 standard channel, you can migrate EnterpriseListenerSets to the upstream ListenerSets.

† - Instead of the BackendTLSPolicy, you can originate TLS to the backend with the tls section of a BackendConfigPolicy that is attached to the backend service.

Sample command for version 1.6.1: Note that some CRDs are prefixed with X to indicate that the entire CRD is experimental and subject to change.

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.1/experimental-install.yaml

Additional support

Have other questions? Reach out to us on Slack or email sales@solo.io.