in the past month, our team has made some contributions to the new Istio installer that is able to separately install the different Istio components.
We are in favour of having such an installer, but we have some questions regarding the way the installer performs updates.
Based on the information from different PRs and working group meetings, our understanding of the currently planned update procedure is:
Deploy a new version of Istio next to an existing one.
Assure that both versions of Istio work.
Switch between the different components.
- How to perform the switch from old to new is unclear for all components but istio-control. If it is done manually it is difficult to scale. If not how can an operator implement this logic so that it works with reconciliation?
- The k8s objects (services, deployments) of two different Istio versions have to have different names in order not to clash. This means they have to differ in shortname or in namespace. What happens with applications (e.g. the bookinfo application) that need to reference Istio services explicitly, like ingressgateway?
It seems that an Istio upgrade would be a breaking change for them.
Thank you, any help is appreciated!