Skip to content

[FEATURES] Support Parallel Release Strategy Between Roles in RBG #18

@veophi

Description

@veophi

Background

When using the RBGS (RoleBasedGroupSet) orchestration model, each RBG (RoleBasedGroup) is responsible for the smallest functional unit.

During system releases, we usually expect:

  • Between RBGs: Follow a serial order or a rollingUpdate strategy to ensure service stability and dependency order.
  • Inside a single RBG: Since it is already the smallest orchestration and scheduling unit, fine-grained rolling updates are not necessary; we hope all Roles&Pods within an RBG can be updated in parallel — meaning destroyed and started at the same time — to shorten the release window and reduce waiting time.

Requirement Description

Currently, the release strategy for RBGs defaults to rollingUpdate. Even when an RBG is already the smallest scheduling unit, updates still occur Pod-by-Pod, leading to:

  1. Longer Release Time
    For RBGs with multiple Pods (replicas), updating one Pod at a time significantly lengthens the release process.
  2. Unnecessary Gradual Rollout
    Since an RBG is already the smallest functional unit, there’s no need for the same gradual rollout applied between RBGs.
  3. RBG-Level Downtime, RBGS-Level Availability
    While a single RBG may experience temporary unavailability during parallel updates, the overall RBGS-level service remains available due to other RBGs continuing to operate.

Therefore, we propose supporting a "full parallel" update strategy within RBGs, allowing all Pods in the group to be terminated and rebuilt simultaneously.


Expected Outcome

Add a new rollingPolicy field under the spec of an RBG to define the internal Pod update strategy:

  • Serial (default)
    Roles are updated sequentially (or in batches), suitable for scenarios requiring gradual rollout or smooth transitions.
  • Parallel
    All Roles inside this RBG are destroyed at the same time and started again simultaneously, suitable for stateless workloads or cases where short RBG-level downtime is acceptable.

Example:

kind: RoleBasedGroup
spec:
  rollingPolicy:
     type: Serial | Parallel

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions