Since Emissary-ingress's configuration is entirely stored in Kubernetes resources, upgrading between minor
versions is straightforward.
Migration is a two-step process:
Install new CRDs.
Before installing Emissary-ingress 2.5.1 itself, you need to update the CRDs in
your cluster; Helm will not do this for you. This is mandatory during any upgrade of Emissary-ingress.
Emissary-ingress 2.5.1 includes a Deployment in the `emissary-system` namespace called emissary-apiext. This is the APIserver extension that supports converting Emissary-ingress CRDs between getambassador.io/v2and getambassador.io/v3alpha1. This Deployment needs to be running at all times.
If the emissary-apiext Deployment's Pods all stop running, you will not be able to use getambassador.io/v3alpha1 CRDs until restarting the emissary-apiext Deployment.
There is a known issue with the emissary-apiext service that impacts all Emissary-ingress 2.x and 3.x users. Specifically, the TLS certificate used by apiext expires one year after creation and does not auto-renew. All users who are running Emissary-ingress/Ambassador Edge Stack 2.x or 3.x with the apiext service should proactively renew their certificate as soon as practical by running kubectl delete --all secrets --namespace=emissary-system to delete the existing certificate, and then restart the emissary-apiext deployment with kubectl rollout restart deploy/emissary-apiext -n emissary-system. This will create a new certificate with a one year expiration. We will issue a software patch to address this issue well before the one year expiration. Note that certificate renewal will not cause any downtime.
Install Emissary-ingress 2.5.1.
After installing the new CRDs, use Helm to install Emissary-ingress 2.5.1. Start by
making sure that your datawire Helm repo is set correctly:
Then, update your Emissary-ingress installation in the emissary namespace.
If necessary for your installation (e.g. if you were running with
AMBASSADOR_SINGLE_NAMESPACE set), you can choose a different namespace.