Frequently-Asked Questions

• Is the upgrade procedure any different if I’m playing with Gloo in a non-production/sandbox environment?

If downtime is not a concern for your use case, the easiest upgrade procedure is simply to completely uninstall Gloo and start from scratch, thereby avoiding any annoyances around breaking changes. Use glooctl uninstall --all followed by the normal installation procedure for the version of your choice.

• What is the recommended way to upgrade if I’m running Gloo in a production environment, where downtime is unacceptable?

In Gloo 1.2 and newer, we recommend helm upgrade with the proper readiness probes and healthchecks configured (see the 1.3.0+ upgrade guide). For versions prior to Gloo 1.2, enterprise customers have found success performing a blue/green deployment using two simultaneous deployments of Gloo. For a brief example, see the 1.0.0 example upgrade.

If you have concerns not addressed in the docs here, reach out to us on our public Slack.

• What will happen to my upstreams, virtual services, settings, and Gloo state in general?

A normal upgrade of Gloo across minor versions should not cause any disruption to existing Gloo state. In the case of a breaking change, we will communicate through the changelog or other channels if some other adjustment must be made to perform the upgrade.

As of open-source Gloo version 0.21.1, there is a command available in glooctl that can help mitigate some concern about Gloo state: glooctl debug yaml can be used to dump the current Gloo state to one large YAML manifest. While this command is not yet really suitable as a robust backup tool, it is a useful debug tool to have available.

• How do I handle upgrading across a breaking change?

See above; the short answer is that we will try to clearly communicate what, if anything, should be done to accommodate preserving Gloo state during an upgrade.

• Is the upgrade procedure any different if I am not an administrator of the cluster being installed to?

If you are not an administrator of your cluster, you may have trouble creating both custom resource definitions and other cluster-scoped resources (like RBAC ClusterRoles/ClusterRoleBindings). If you run into trouble with this during an installation, you can disable the creation of these resources by overriding the values:

global:
  glooRbac:
    create: false
crds:
  create: false

You may also try performing an installation of Gloo that is scoped to a single namespace:

global:
  glooRbac:
    namespaced: true

• Why do I get an error about re-creating CRDs when upgrading using helm install or helm upgrade?

See the explanation in the upgrade steps. Helm v2 does not manage CRDs well, so you may have to delete the CRDs and try again, or install using some other method.