1.14.0+ Upgrade Notice
Review and apply version-specific changes in Gloo Edge 1.14.x and Gloo Edge Enterprise 1.14.x before upgrading your Gloo Edge installation.
This upgrade notice summarizes the main feature, Helm, CRD, and CLI changes for you before upgrading to version 1.14. For more details on particular changes, see the Changelog.
Review the following highlights of features changes in Gloo Edge version 1.14.
New or improved features:
- Improved AWS Lambda response transformations: UnwrapAsApiGateway, previously a Gloo Edge Enterprise feature, has been migrated to Gloo Edge. The setting
responseTransformationhas been revised to configure this feature instead. Consequently, the feature
responseTransformationwill no longer hard-code the response’s
text/html. Additionally, it is now treated as an error when
responseTransformationare configured simultaneously. This is a potentially breaking change from the prior behavior whereby Gloo Edge would prioritize UnwrapAsAlb when both were set.
- New gRPC API: In previous releases, Gloo Edge used the functions that were available in the proto file and the HTTP mapping that you provided in the Virtual Service to derive the proto descriptors. Proto descriptors were then automatically added to the gRPC upstream. In Gloo Edge 1.14, HTTP mappings must always be provided in the proto itself to allow Gloo Edge to discover these mapping automatically. Any mapping rules that you added to Virtual Services in previous releases are ignored. This change is considered a breaking change. For more information, see Changes to the gRPC API in Gloo Edge 1.14. To learn how to use the new gRPC API, see gRPC.
- Automatic discovery of GraphQL remote executors: When your upstream service is already a GraphQL server that includes its own resolvers, you can automatically discover and use them to resolve requests for remote execution. You do not need to define another resolver within the GraphQLApi. For more information, see Remote executor configuration for existing GraphQL server upstreams.
- Added support for Kubernetes 1.25, removed support for 1.22: Gloo Edge (OSS) can now be run on Kubernetes version 1.25. At the same time, support for Kubernetes version 1.22 was removed. This is considered a breaking change as APIs and file paths have changed. For example, the PodDisruptionBudget CRD moved from the
policy/v1API. In addition, the Gloo Helm chart OCI registry path changed from
- Horizontal pod autoscaling v2 support: You can now configure horizontal pod autoscaling for the gateway proxy in accordance to the Kubernetes
- AWS Lambda responseTransformation
- xDS relay: With the introduction of leader election for the Gloo Edge control plane, xDS relay is no longer needed to increase the availability of the xDS server. Previously, the xDS relay was deprecated in 1.13, a beta-only feature in Gloo Edge 1.11 or 1.12, and not available for non-default installation modes of Gloo Edge, such as REST Endpoint Discovery (EDS), mTLS, or Istio mTLS modes.
New Helm fields:
- Specify the security and pod security context for the Redis and rate limit deployments by setting the following Helm values:
gatewayProxies.gatewayProxy.envoyLogLevelto enable Envoy logs.
- Add init containers and additional containers to the gateway proxy deployment with
- Control how pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains by using the
- Prevent writing core dumps in the case Envoy fails by using the
Deprecated Helm fields:
Removed Helm fields:
New CRDs are automatically applied to your cluster when performing a
helm install operation. However, they are not applied when performing an
helm upgrade operation. This is a deliberate design choice on the part of the Helm maintainers, given the risk associated with changing CRDs. Given this limitation, you must apply new CRDs to the cluster before upgrading.
New and updated CRDs:
- Added support for an
idleTimeoutfield in the route action configuration of a route to correspond to envoys
- Added the option to specify the HTTP
requestMethodthat you want to use when performing health checks for the gateway in the
dnsRefreshRatefields to the Upstream API to control cluster’s DNS refresh rate.
- Exposed Envoy’s
config.core.v3.Cluster.SlowStartConfigconfig in the Upstream API to allow users to configure delays for slow starting apps to accomodate round robin or least request load balancers.
- Added HMAC authentication support to the extauth API.
New CLI commands or options:
- Validate your configuration without needing RBAC permissions on certain resources by using the
- Compare the CRDs that are currently installed with the CRDs of a specific Helm chart version by using the
glooctl check-crds --version <string> --local-chart <string> --show-yaml <bool>command.
- Switch contexts for different clusters by using the
glooctl --kube-context <string>command.
The following steps describe the general process for upgrading Gloo Edge.
Want to test the new version before upgrading? Try out a Canary Upgrade.
Follow steps 1 - 2 in Upgrade Steps to prepare for upgrading, and to upgrade
Apply the new and updated CRDs. Replace the version with the specific patch version that you are upgrading to, such as
1.14.0in the following examples.
helm repo update helm pull gloo/gloo --version 1.14.0 --untar kubectl apply -f gloo/crds
helm repo update helm pull glooe/gloo-ee --version 1.14.0 --untar kubectl apply -f gloo-ee/charts/gloo/crds # If Gloo Federation is enabled kubectl apply -f gloo-ee/charts/gloo-fed/crds
Verify that the deployed CRDs use the same version as your current Gloo Edge installation.
Enable any new features that you want to use.
Continue to upgrade the Gloo Edge server components via Helm.