Rolling Update Surge and Availability Bounds

Problem Statement

A Deployment's RollingUpdate strategy is two knobs, maxSurge and maxUnavailable, each an absolute count or a percentage. They decide how many pods may exist above the desired count during a rollout and how many may be missing from it. Resolve a strategy into the absolute numbers so you can tell whether the rollout will hold capacity — and whether your cluster has room for the surge.

Background

Kubernetes converts percentages against spec.replicas, and the two knobs round in opposite directions, deliberately, so the defaults never violate what they promise:

• maxSurge rounds up — you may always add at least one extra pod.
• maxUnavailable rounds down — you never lose more capacity than advertised.

With replicas: 10 and 25% for both, that is a surge of ceil(2.5) = 3 and unavailability of floor(2.5) = 2. Rounding both the same way is the usual bug.

From there:

min_available = replicas - max_unavailable      # the floor on serving capacity
max_pods      = replicas + max_surge            # peak pods, i.e. peak resource use

Your Task

Implement:

def rollout_bounds(replicas, max_surge, max_unavailable):

Return a dict with keys "max_surge", "max_unavailable", "min_available", "max_pods", in that order, all ints.

Input Format

• replicas: positive int.
• max_surge, max_unavailable: either an int, or a percentage string like "25%".

Output Format

• A dict of four ints.

Sample

print(rollout_bounds(10, "25%", "25%"))

Output:

{'max_surge': 3, 'max_unavailable': 2, 'min_available': 8, 'max_pods': 13}

Surge rounds up to 3, unavailability rounds down to 2 — so the rollout never drops below 8 serving pods, and the cluster must have headroom for 13.