import Alert from ‘@material-ui/lab/Alert’;
You can upgrade from any version of $AESproductName$ or $OSSproductName$ to any version of either by installing the new version in a new Kubernetes cluster, then copying over configuration as needed. This is the way to be absolutely certain that each installation cannot affect the other: it is extremely safe, but is also significantly more effort.
For example, to upgrade from some other version of $AESproductName$ or $OSSproductName$ to $productName$ $versionTwoX$:
Install $productName$ $versionTwoX$ in a completely new cluster.
Create Listener
s for $productName$ $versionTwoX$.
When $productName$ $versionTwoX$ starts, it will not have any Listener
s, and it will not
create any. You must create Listener
resources by hand, or $productName$ $versionTwoX$
will not listen on any ports.
Copy the entire configuration from the $productName$ 1.X cluster to the $productName$
$versionTwoX$ cluster. This is most simply done with kubectl get -o yaml | kubectl apply -f -
.
This will create getambassador.io/v2
resources in the $productName$ $versionTwoX$ cluster.
$productName$ $versionTwoX$ will translate them internally to getambassador.io/v3alpha1
resources.
Each $productName$ instance has its own cluster, so you can test the new instance without disrupting traffic to the existing instance.
If you need to make changes, you can change the getambassador.io/v2
resource, or convert the
resource you’re changing to getambassador.io/v3alpha1
by using kubectl edit
.
Once everything is working with both versions, transfer incoming traffic to the $productName$ $versionTwoX$ cluster.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.