the upgrade documentation here:
states
Upgrading across more than one minor version (e.g., 1.6.x to 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
Hi Andrew,
The Istio team is fairly careful to not claim support for any process we haven’t thoroughly tested, and this has been the case for direct upgrades across multiple minor versions. Starting in Istio 1.10, however, we have begun to offer support for direct upgrades across two minor versions, specifically from 1.8 to 1.10, and this support will continue with the release of 1.11 next month (upgrades from 1.9 to 1.11 will be supported). We have a series of automated tests for this case, so we have reasonable confidence that these upgrades can proceed safely.
While direct upgrades across four minor versions are not likely to be supported soon, I know we have some power users who are working to automate such a process for themselves, and I’ll let them chime in as they see fit. Keep in mind that the OSS community only supports releases for about six months, so unless you have purchased support from an Istio Vendor, your Istio installation hasn’t been updated in about nine months, and still contains all the vulnerabilities which Istio has addressed since then.
Keeping your Service Mesh Installation up-to-date is a critical part of Day 2 Operations, and we recognize that this is not easy. That is why our 2021 roadmap focuses specifically on reducing the cost of Day 2 Operations with options like Direct Upgrades. Let me know if you have any questions, and I’d be happy to help!
Mitch