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

Solo Enterprise for kgateway link

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 link

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 link

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 link

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.

Image variants link

Distroless link

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 link

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.

Deploy a specific image variant link

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

Control plane link

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.1.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.1.5
     

Data plane link

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.

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. Note that the envoy-wrapper requires the -fips suffix in the repository, whereas the extauth and rate liming servers include the -fips suffix in the image 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.1.5"
           pullPolicy: IfNotPresent
       # proxy extensions, such as redis cache, external auth and rate limiting service
       sharedExtensions:
         extauth:
           container:
             image:
               registry: gcr.io/gloo-mesh
               repository: ext-auth-service
               tag: "0.72.2-fips"
         ratelimiter:
           container:
             image:
               registry: gcr.io/gloo-mesh
               repository: rate-limiter
               tag: "0.17.2-fips"
   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 deploy/ext-auth-service-custom-enterprise-kgateway  -n kgateway-system -o yaml
   kubectl get deploy/rate-limiter-custom-enterprise-kgateway  -n kgateway-system -o yaml
     

Release cadence link

Solo Enterprise for kgateway releases are built on the OSS codebase and typically follow the equivalent kgateway 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 link

Alpha and beta release process link

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 link

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 link

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

Sample command for version 1.4.0: 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.4.0/experimental-install.yaml
  

Additional support link

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

link