For example, you could optimize for time to start serving the new version, i.e. start the second pod and let elements come “online” as normal, and merge them into the existing system. That works well.

Another thing to optimize for is time to “revert” the new version if there is a problem. For example, if you start draining traffic from the “older version” as soon as “new nodes” come online, then it’s possible it would take a while to revert/back those new versions out. (And need to wait for the older version to start being served again.)

And then, there is the question of resource utilization. If you wait for “all of green” to be up and running and “all of blue” to continue being running, before removing those resources, then that not only takes a long time, but it also means you need to provision 2x the capacity for your service.

… this is all a long way to say I don’t have a single recommendation for you. But I would hope that one day we can put all of this logic/tradeoff into a reusable package, so that someone such as yourself can evaluate the different options/tradeoffs, and easily configure the strategy being used.