1.11.0+ Upgrade Notice
Review the changes in Gloo Edge 1.11.x and Gloo Edge Enterprise 1.11.x, and apply the version-specific changes before upgrading your Gloo Edge installation.
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.
Helm changes
In Gloo Edge v1.11.20 / Gloo Edge Enterprise v1.11.27 and later, the default Gateways, ExtAuth Upstreams, and RateLimit Upstreams are installed via a Job during the Helm installation and upgrade process, instead of being included directly in the Helm chart. After you upgrade to these versions, those resources no longer have Helm annotations (e.g. meta.helm.sh/release-name
, meta.helm.sh/release-namespace
). If you need to roll back to an earlier Gloo Edge version, you must manually add the Helm release annotations back to these resources before performing the rollback.
Do not manually edit (e.g. kubectl apply
or kubectl edit
) the Gloo Edge custom resources (e.g. Gateways, Upstreams) that are installed with the Helm chart, as this might cause errors in future upgrades.
If you already manually edited a resource, verify before you upgrade that the resource’s metadata.annotations.kubectl.kubernetes.io/last-applied-configuration
annotation does not contain a resourceVersion
field. This field can cause conflicts during the upgrade process.
If the field exists, you can remove it in either of the following ways:
kubectl edit
the resource and manually delete theresourceVersion
field from themetadata.annotations.kubectl.kubernetes.io/last-applied-configuration
annotation, or- remove the
metadata.annotations.kubectl.kubernetes.io/last-applied-configuration
annotation altogether if not needed, e.g.kubectl annotate gateway -n gloo-system gateway-proxy kubectl.kubernetes.io/last-applied-configuration-
CRD changes
New and updated CRDs
- In the ExtAuth CR, the
spec.configs.oauth2.oidcAuthorizationCode.clientSecretRef
now requires secrets oftype: extauth.solo.io/oauth
. For more information, see the OAuth configuration guide. - The GraphQL CR is renamed to
GraphQLApi
(as of release 1.11.0-beta16), and its version has been changed fromv1alpha1
tov1beta1
(as of release 1.11.0). - The Settings CR is updated to include
consoleOptions
configuration settings for the Gloo Enterprise UI. - The names of the Gloo Edge snapshot emitter metrics are changed to the format
api_gloosnapshot_gloo_solo_io_emitter_*
. For example, the previous metricapi_gloo_solo_io_emitter_resources_in
is now updated toapi_gloosnapshot_gloo_solo_io_emitter_resources_in
.
Deprecated CRDs None
Removed CRDs
- The previous GraphQL CR name,
GraphQLSchema
(as referenced in the 1.10 upgrade guide), is removed.
Upgrade steps
To upgrade Gloo Edge:
-
Follow the steps in Upgrade Steps to prepare for upgrading, and to upgrade
glooctl
. -
If you use OAuth, update your
AuthConfig
resource configuration. Follow the OAuth configuration guide to generate a secret oftype: extauth.solo.io/oauth
and reference that secret in thespec.configs.oauth2.oidcAuthorizationCode.clientSecretRef
field. -
Delete the removed/outdated CRDs (if applicable).
kubectl delete crd graphqlschemas.graphql.gloo.solo.io kubectl delete crd graphqlapis.graphql.gloo.solo.io
-
Apply the new and updated CRDs. Replace the version with the specific patch version that you are upgrading to.
helm repo update helm pull gloo/gloo --version 1.11.0 --untar kubectl apply -f gloo/crds
helm repo update helm pull glooe/gloo-ee --version 1.11.0 --untar kubectl apply -f gloo-ee/charts/gloo/crds # If Gloo Federation is enabled kubectl apply -f gloo-ee/charts/gloo-fed/crds
-
Continue to upgrade the Gloo Edge server components via Helm.
-
Gloo Federation only: Due to the addition of the GraphQLApi CRD in v1.11, the Gloo Federation ClusterRole in each registered cluster must be updated with new permissions. To do so, follow the instructions to re-register each of your clusters.