As discussed in OTA-1384, our mid-term goal is to drop replicas again. But to derisk in the meantime, this ticket is about moving replicas from MIN_REPLICAS to MAX_REPLICAS to avoid:

• The Deployment returning to MIN_REPLICAS and terminating any additional (but required to serve the current load) pods. Keda will quickly reset to its suggested replicas, but we'll have OTA-1376 style disruption while those replacement pods are created and slowly come online (OTA-1375, OTA-1379).

With the pivot to MAX_REPLICAS, the unfortunate drop to MIN_REPLICAS followed by a return to Keda's preferred replicas (which terminates slow-to-get-replaced Pods) will be replaced by an unfortunate surge to MAX_REPLICAS followed by a a return to Keda's preferred replicas. So still unfortunate, but the termination route reduces our capacity to serve client requests, and could cause an outage, while the surge route just costs us a bit more money, as we scale up new Machines to hold the extra Pods before terminating the new Pods and scaling the extra Machines back down. Seems like it's worth paying that cost if we need to deploy again before OTA-1384 removes this disruption from Template redeploys for good.