the upgrade documentation here:
Upgrading across more than one minor version (e.g.,
1.8.x ) in one step is not officially tested or recommended.
I’m interested in what exactly is tested (is it just the upgrade process itself?) and why it isn’t recommended.
I presently run 1.6.x and want to get to 1.10.x but need to backout if any issues are encountered:
I use istioctl manifest generate to create a control plane yaml which is then altered to fit my kube cluster then applied with kubectl
at face value, the following seems the process to follow:
upgrade control plane (apply yaml) to 1.7, restart pods, redeploy gateway deployments @1.7
upgrade control plane to 1.8, restart pods, redeploy gateway deployments @1.8
upgrade control plane to 1.9, restart pods, redeploy gateways deployments @1.9
upgrade control plane to 1.10, restart pods, redeploy gateways deployments @1.10
the backout would be to do the whole thing in reverse
however are there alternatives?
given the statement above I guess I can’t just apply my 1.10 control plane yaml (but would still like to understand why not …) so how about:
upgrade control plane (apply yaml) to 1.7
upgrade control plane to 1.8
upgrade control plane to 1.9
upgrade control plane to 1.10
restart pods @1.10
redeploy gateway deployments @ 1.10