How to Mock a Kubernetes Rolling Update with maxSurge in Python

Simulate a Kubernetes rolling update with maxSurge policy, tracking peak and final replica counts during roll transitions.

Easy Python 3.9+ Aug 9, 2026 Production deployment patterns 12 views 0 copies

kubernetes rolling-update maxsurge deployment simulation

Python code

36 lines

Python 3.9+

from collections import deque

class RollingUpdateMaxSurge:
    def __init__(self, replicas, max_surge):
        self.replicas = replicas
        self.max_surge = max_surge
        self.available = replicas
        self.history = deque()

    def roll(self, desired_replicas):
        """
        Simulate a rolling update with maxSurge.
        Returns (peak_replicas, final_replicas).
        """
        surge_limit = self.max_surge
        # New replicas that can be added beyond desired
        new_capacity = min(desired_replicas, surge_limit)
        # Peak cannot exceed current + allowed surge
        peak = self.available + surge_limit
        # For simplicity mock: after rolling, available becomes desired
        self.available = desired_replicas
        self.history.append(peak)
        return peak, self.available


if __name__ == "__main__":
    deploy = RollingUpdateMaxSurge(replicas=5, max_surge=2)
    print("Initial:", deploy.available)

    peak1, final1 = deploy.roll(desired_replicas=6)
    print(f"Roll to 6: peak={peak1}, final={final1}")

    peak2, final2 = deploy.roll(desired_replicas=4)
    print(f"Roll to 4: peak={peak2}, final={final2}")

    print("History:", list(deploy.history))

Output

stdout

Initial: 5
Roll to 6: peak=7, final=6
Roll to 4: peak=8, final=4
History: [7, 8]

How it works

The maxSurge field in Kubernetes defines how many extra replicas can be temporarily created beyond the desired count during a rolling update. This mock replicates that behavior by allowing the peak replica count to exceed the desired target by the surge limit. The roll method updates the internal available count to the new desired value and records the peak in a history deque for later inspection. This simple abstraction helps developers reason about capacity limits and rollout safety without deploying a real cluster.

Common mistakes

Forgetting that maxSurge is additional to the current available, not the desired count
Assuming peak is always desired + maxSurge, when actual surge depends on how many old pods remain
Not resetting history between different deployment scenarios
Confusing maxSurge with maxUnavailable, which limits how many pods can be down simultaneously

Variations

Use a list instead of deque for history if you don't need popleft
Implement maxUnavailable logic too for more realistic simulation

Real-world use cases

Predicting capacity spikes during a production rolling update to ensure your cluster can handle the extra pods.
Validating that your autoscaling policies and node pool sizes won't be overwhelmed by the temporary surge.
Writing unit tests for deployment controllers or orchestration helper functions that reason about rollouts.

How to Mock a Kubernetes Rolling Update with maxSurge in Python

Python code

Output

How it works

Common mistakes

Variations

Real-world use cases

More from Production deployment patterns

Tutorials

Quizzes

Python code

Output

How it works

Common mistakes

Variations

Real-world use cases

More from Production deployment patterns

Keep learning

Tutorials

Quizzes