A stated requirement for many customers to adopt ambient mode will be zero-downtime upgrades. Based on current capabilities, long-lived connections may be dropped when ZTunnel is upgraded. Upstream Istio makes a recommendation for "node cordoning and blue/green node pools to limit the blast radius" and tells users to "See your Kubernetes provider documentation for details." (ie us for OpenShift). While OpenShift does provide documentation on draining nodes with a "cordon" command, it does not provide anything related to blue/green node pools. It is not clear how these procedures could be used in combination with the OSSM operator (Sail Operator)'s upgrade procedures.

We need to provide a documented procedure or recommendation for this to minimize the possibility of application impact when upgrading workloads that are part of Istio ambient mode using the OSSM operator. The "out of the box" procedure from Istio that drops long lived connections is likely not acceptable for many customers.

Istio's ambient mode also does not support revision based upgrades, which may also reduce the possibility of application interruptions.

Expected outcome: A tested/documented procedure for Istio ambient mode that will minimize the likelyhood of application workload impacts (service unavailability, dropped connections, etc). In addition to enhancing the Sail Operator for this, we should look for opportunities to enhance this is in community Istio.