feat: Progressive delivery of deployment without changing strategy to Recreate

[furykerry]

Note: this is a candidate program of google summer of code , and will be assign to the selected mentee

Currently OpenKruise rollout pause the deployment, and change the updateStrategy of deployment to Recreate during the progressive delivery. However such hack cause concerns about the risk of recreate all pods if deployment is not paused properly, especially during the process of rollout disable or removal. See reported [issue | https://github.com//issues/305] for more detail.

Alternatively, OpenKruise rollout can increase the minReadySeconds and progressDeadlineSeconds to a quite large value and keep the deployment strategy as RollingUpdate. Since large minReadySeconds can keep the updated pods at "unavailable" state, the rollout can control the delivery process by gradually increase the maxUnavailable.

[pradhyum6144]

Hi @furykerry,

I'm interested in working on this GSoC project. I've been exploring the OpenKruise codebase and understand the problem:

Current approach (Recreate strategy):

• Risky if deployment isn't paused properly - could recreate all pods at once
• Requires strategy mutation which feels hacky

Proposed approach (minReadySeconds):

• Keep deployment strategy as RollingUpdate
• Set large minReadySeconds + progressDeadlineSeconds to keep updated pods in "unavailable" state
• Control rollout by gradually increasing maxUnavailable
• Safer since pods are created incrementally, not all at once

I've already submitted a small PR to the main kruise repo (#2352) to familiarize myself with the contribution process.

I'd love to discuss:

1. How should the rollout controller coordinate minReadySeconds changes with the deployment controller?
2. Should there be a fallback mechanism if the new approach fails?

Looking forward to contributing to this!

[Nazihbenbrahim]

Hi @furykerry,

I’m interested in implementing the alternative progressive delivery strategy for Deployments in #323 and started tracing the current Recreate-based path.

Current behavior (where it happens)

• Webhook mutator forces spec.strategy.type = Recreate:
  pkg/webhook/workload/mutating/workload_update_handler.go (~248–251)
  (“always Recreate to disable native controller”).
• Partition-style deployment control patches the workload with paused=true + Recreate:
  pkg/controller/batchrelease/control/partitionstyle/deployment/control.go (~112),
  and restores in the finalization path (~154–155).

This matches the safety concern: if disable/removal/crash leaves the Deployment in a partially restored state, Recreate can cause an outage.

Alternative direction
Keep RollingUpdate, set very large minReadySeconds + progressDeadlineSeconds so new pods remain “not available”, then gate progression by adjusting maxUnavailable gradually. This should degrade more safely (native controller behavior) instead of a catastrophic Recreate edge case.

What I want to confirm

1. Should the alternative path be introduced behind an explicit “mode” (opt-in) first?
2. Any preference for how to store/restore original fields (annotation vs status)?
3. Any recommended constraints for maxUnavailable progression (e.g., step-driven percent vs computed based on replicas)?

I’ve already validated basic local checks (go mod verify, go vet ./...) and I’m ready to draft a design note + start with a small PR before the larger feature.

[kartikloops]

Hi, I'm interested in working on this as part of GSoC 2026. I've been studying the current BatchRelease implementation for Deployments and I understand the concern the current approach mutates updateStrategy to Recreate, which creates a window where if the pause doesn't happen in time, all pods could be recreated simultaneously.

I'm exploring the alternative approach using maxSurge and maxUnavailable to gate each batch. A few questions to make sure my design direction is right before I draft a proposal:

Should the new strategy be additive (a new option alongside the current one) or intended to eventually replace it?
For rollback mid-batch is the expectation that we restore the original maxSurge/maxUnavailable values from before the rollout began, or is there a preferred rollback UX documented somewhere?

Are there known edge cases (e.g. HPA-managed replicas, or Deployments with maxUnavailable > 0 set by the user) that I should prioritize in my design?

Happy to share a draft design doc once I have a clearer picture. Thanks for the detailed issue writeup.

[Xio-Shark]

Hi @furykerry,

I'm very interested in this GSoC 2026 project. I've been working with Go and Kubernetes, and after studying the issue and related #305, I've drafted an initial design sketch for the alternative approach.

Proposed Implementation Sketch

Core Mechanism

The key insight is that Kubernetes considers a pod "available" only after it has been Ready for minReadySeconds. By temporarily inflating this value, we can keep newly updated pods in a "Ready but not Available" state, giving the Rollout controller full control over delivery pacing:

Phase 1 — Prepare: Before triggering the Deployment update:

• Save original minReadySeconds, progressDeadlineSeconds, and maxUnavailable in Deployment annotations
• Set minReadySeconds to a sentinel value (e.g., 2147483647)
• Set progressDeadlineSeconds to a similarly large value
• Keep strategy as RollingUpdate with maxUnavailable: 0 initially

Phase 2 — Progressive Rollout: For each batch:

• Increase maxUnavailable by the batch size
• The Deployment controller creates new pods (they become Ready but NOT Available due to large minReadySeconds)
• Wait for the new pods to be Ready and pass any canary/analysis checks
• Temporarily restore minReadySeconds to original value for current batch pods (or use a readiness gate approach)

Phase 3 — Finalize: On completion or rollback:

• Restore all original values from annotations
• The Deployment controller handles the rest natively

Safety Advantages over Current Recreate Approach

Scenario	Current (Recreate)	Proposed (minReadySeconds)
Controller crash mid-rollout	Risk of recreating ALL pods	Pods stay as-is, RollingUpdate is safe
Rollout disabled/removed	Must restore strategy first	Only need to restore minReadySeconds
Unexpected scale event	Unpredictable with Recreate	RollingUpdate handles scaling naturally

Key Implementation Questions

1. Pod-level vs Deployment-level control: minReadySeconds is a Deployment-level field, so we can't selectively make individual batch pods "available". Would a ReadinessGate-based approach be worth exploring as a complement, or should we keep it simple with Deployment-level maxUnavailable adjustments?

2. Interaction with PodDisruptionBudget: When minReadySeconds is inflated, updated pods won't count as "available" for PDB calculations. Should we document this as a known limitation, or actively handle it?

I'm ready to start coding a proof-of-concept this week. Would you prefer I submit it as a draft PR, or start with a design doc in the Discussions tab?

[Akash-Adak]

Hi @furykerry 👋

I’ve been studying the current rollout mechanism and the concerns around switching Deployment strategy to Recreate during progressive delivery.

From my understanding, the main risk is that if the Deployment is not properly paused or if rollout is disabled unexpectedly, it could lead to all pods being recreated at once, which defeats the purpose of safe progressive delivery.

The alternative approach using large minReadySeconds and controlled maxUnavailable seems promising, since it allows us to keep the RollingUpdate strategy while still controlling the pace of rollout by keeping new pods in an “unavailable” state.

I’m thinking of exploring an implementation where:

• minReadySeconds is dynamically adjusted to delay readiness of updated pods
• maxUnavailable is gradually increased to control batch size
• rollout controller manages progression without modifying Deployment strategy

Before diving deeper, I had a couple of questions:

1. Are there any known limitations or edge cases with relying heavily on minReadySeconds for rollout control?
2. Should this be implemented as a completely new rollout strategy, or as an optional mode within the existing controller?
3. Are there any existing design discussions or documents I should refer to before proposing a detailed design?

I’d love to explore this further and contribute to a robust solution here.

Thanks!