When a sidecar injector is upgraded, it upgrades all pods to the new version of proxy when the pod is created. Are there any plans to support selective/gradual upgrade of proxys using the sidecar injector ? Say we would like to rollout the proxy to less risky services first and go from there and upgrade the rest. We would still want the injector to have control vs. give the service owner control over what proxy version to inject.
We’re actually building our own injector for this exact purpose. cc @michaelkipper
Curious what criteria you are using to selectively rollout ? And if that is generic enough so that it can be included in the istio sidecar injector for wider consumption.
We have the ability to deploy the istio-proxy container and enabling the initContainer separately. This allows us to ensure we can actually deploy the containers in the pod before relying on their existence.
We also have the ability to control the deploy percentage of the proxy within a since Deployment. This will allow us to slowly roll out the mesh without accidentally overwhelming the control plane, which we’ve seen cause issues in our staging clusters. Eventually, we can also use this mechanism to do a version upgrade.
Finally, our injector reads from our own CRD, which we use to control several different parts of the overall workflow. This ensures that we have a single source of truth for service info. It also insulates us from the mesh implementation, and allows us to move to something else oneday, if the need arises.
Thanks. Once a proxy is rolled out, how do you plan to selectively rollout a newer version of the proxy to existing mesh service deployments ?