Ⅰ. Motivation

The current RoleBasedGroup (RBG) relies on multiple external workloads such as Deployment, StatefulSet, and LeaderWorkerSet (LWS).
This dependency limits RBG's extensibility and increases the complexity for users who are not deeply familiar with the Kubernetes workload ecosystem.

To better serve large-model (LLM) inference/training scenarios and reduce user cognitive overhead, this PR proposes introducing InstanceSet as a first-class workload type in RBG.
InstanceSet enables:

• Orchestration of both single-node and multi-node inference instances.
• Instance as a minimal orchestration unit, with richer lifecycle control.
• Features such as in-place update, gang scheduling, and traffic lifecycle binding at instance-level.

Ⅱ. Modifications

Introduce InstanceSet KEP docs:

• Added support for a new InstanceSet workload type within RBG.
• Defined Instance concept and CRD abstraction:
  • An Instance can contain one or more Pods, supporting differentiated templates and replica counts.
  • Pod lifecycle binding within an Instance: synchronized start, stop, and traffic drain.
  • Pod affinity/topology settings and gang scheduling support within an Instance.
• Implemented upgrade policies:
  • Instance-level and Pod-level in-place/recreate upgrade rules based on changed fields.
• Added feature comparison table between InstanceSet and LWS.
• Documented user stories covering in-place updates, rolling updates with MaxSurge, etc.

Ⅲ. Does this pull request fix one issue?

fixes #3 #21

Ⅳ. List the added test cases

TBD — Will add unit tests and integration tests for:

• Instance creation and orchestration
• In-place upgrade behavior
• rolling update upgrade behavior
• gang scheduler and ready policy
• Field-change based upgrade path validation
  (No backward compatibility tests for switching existing RBG workloads to InstanceSet as it’s out of scope.)

Ⅴ. Describe how to verify it

VI. Special notes for reviews

• This PR only supports newly created RBGs using InstanceSet and does not support swapping existing RBG workloads to InstanceSet directly.
• Consider aligning on which RBG API exposure option (Option 1 or Option 2) should be accepted.

Checklist

• Format your code make fmt.
• Add unit tests or integration tests.
• Update the documentation related to the change.