Using Surge strategy with Pod Disruption Budgets (Feature Request?)

I searched and wasn’t able to find any discussion about applying the surge strategy from RollingUpdates (Deployments) while handling voluntary disruptions / evictions. Has this been discussed at all? Looking at the documentation, I don’t see any way to do it, so I’m assuming it’s not currently possible.

Just to clarify, the “RollingUpdate” strategy for Deployments will add new pods and wait for them to become live before terminating old pods, so that there are always at least the “desired” number of replicas running for the given Deployment. This way there’s no disruption in service even if your Deployment only has 1 or 2 replicas. That strategy does not apply to voluntary pod disruptions though, and I think it should be an option.

I guess the main trick in including this functionality within PodDisruptionBudgets from a conceptual perspective is that PDBs aren’t related to Deployments, ReplicaSets or StatefulSets, but perhaps the PodDisruptionBudgetSpec could be modified to have an optional surge_strategy property with an associated replica_set or stateful_set, or something to that effect? (It is currently in beta so still malleable, right? :D)

The use-case is that I’d like to set my replicas to the amount I want, and expect them to be maintained at that level during normal operation (as is facilitated by maxSurge and maxUnavailable within a DeploymentSpec), but there seems to be no way to facilitate this policy when it comes to voluntary disruptions (other than deployment updates, which are only one kind of voluntary disruption). For now, I’m stuck with budgeting for 1 or 2 unavailable, and increasing the amount of desired replicas to offset that in cases where there are only one or two replicas running, which is not ideal, because that means I’m running extra replicas 100% of the time rather than just during the update process when they’re needed.

(Alternately: Is there a more appropriate/productive place to discuss/request new features, or is this the place?)

Cluster information:

Kubernetes version: 1.14
Cloud being used: Google
Installation method: GKE