You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/user-manuals/cloneset.md
+96-1Lines changed: 96 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -529,6 +529,102 @@ spec:
529
529
paused: true
530
530
```
531
531
532
+
### Progress Deadline Seconds
533
+
534
+
**FEATURE STATE:** Kruise v1.9.0
535
+
536
+
The `.spec.progressDeadlineSeconds` field is an optional field that defines the maximum time (in seconds) the CloneSet controller waits before determining that a rollout has failed to make progress. When this deadline is exceeded without progress, the CloneSet controller records the following condition in the resource status:
537
+
```yaml
538
+
type: Progressing
539
+
status: False
540
+
reason: ProgressDeadlineExceeded
541
+
```
542
+
543
+
By default, the CloneSet controller will continuously retry rollout operations for 600 seconds. Higher level orchestrators can take advantage of it and act accordingly, e.g.rollback the CloneSet (even when this Failed status is marked, it does not affect the underlying CloneSet controller's continued rolling updates of Pods).
544
+
545
+
> **Note:**
546
+
>
547
+
> If specified, this field value must be greater than `.spec.minReadySeconds`.
548
+
549
+
Therefore, by configuring `.spec.progressDeadlineSeconds`, a CloneSet will traverse multiple states during its lifecycle:
550
+
- Progressing: the rollout is ongoing.
551
+
- Complete: the partition update is successful or the rollout is successful.
552
+
- Failed: the rollout is timeout.
553
+
554
+
#### Progressing CloneSet
555
+
A CloneSet is marked as Progressing when performing any of the following operations:
556
+
557
+
- Rolling out a new revision.
558
+
- Scaling up the newest revision during upgrade.
559
+
- Scaling down older revisions during upgrade.
560
+
- New Pods are ready or available (satisfying MinReadySeconds condition).
561
+
562
+
When the rollout enters the "Progressing" state, the CloneSet controller adds the following condition to the CloneSet's `.status.conditions`:
563
+
```yaml
564
+
type: Progressing
565
+
status: "True"
566
+
reason: CloneSetUpdated
567
+
```
568
+
569
+
#### Complete CloneSet
570
+
The Complete state is divided into two substates:
571
+
572
+
**Partition Paused:**
573
+
574
+
A CloneSet enters the partition paused state when:
575
+
- All replicas associated with the CloneSet partition have been updated to the specified latest revision.
576
+
- All replicas associated with the CloneSet partition are available.
577
+
578
+
The CloneSet controller adds the following condition to the CloneSet's `.status.conditions`:
579
+
```yaml
580
+
type: Progressing
581
+
status: "True"
582
+
reason: ProgressPartitionAvailable
583
+
```
584
+
585
+
**Available:**
586
+
587
+
A CloneSet is marked as available when:
588
+
589
+
- All replicas have been updated to the latest specified revision.
590
+
- All replicas are available.
591
+
- No old revision replicas are running.
592
+
593
+
The CloneSet controller adds the following condition to the CloneSet's `.status.conditions`:
594
+
```yaml
595
+
type: Progressing
596
+
status: "True"
597
+
reason: CloneSetAvailable
598
+
```
599
+
600
+
The Progressing condition maintains a status value of "True" until a new revision is initiated. This condition persists even when replica availability changes (which affects the Available condition instead).
601
+
602
+
#### Failed CloneSet
603
+
A CloneSet enters the Failed state when it cannot successfully deploy the latest revision. Common causes include:
604
+
605
+
- Insufficient quota
606
+
- Readiness probe failures
607
+
- Image pull errors
608
+
- Insufficient permissions
609
+
- Limit ranges
610
+
- Application runtime misconfiguration
611
+
612
+
This condition can be detected by configuring the `.spec.progressDeadlineSeconds` parameter. Once the deadline is exceeded, the CloneSet controller adds the following condition to the CloneSet's `.status.conditions`:
613
+
```yaml
614
+
type: Progressing
615
+
status: "False"
616
+
reason: ProgressDeadlineExceeded
617
+
```
618
+
619
+
> **Note:**
620
+
>
621
+
> When a CloneSet rollout is paused, the controller stops progress checking against the specified deadline. Users can safely pause and resume a CloneSet rollout in the middle of the rollout without triggering the deadline exceeded condition.
622
+
623
+
#### Operations on Failed CloneSet
624
+
All operations applicable to a Complete CloneSet can also be applied to a Failed CloneSet, including:
625
+
- Rolling back to a previous revision.
626
+
- Pausing the rollout to make multiple adjustments to the Pod template.
627
+
532
628
### In-Place Update Support for Modifying Resources
533
629
534
630
**FEATURE STATE:** Kruise v1.8.0
@@ -762,4 +858,3 @@ Currently, both status and metadata changes of Pods will trigger the reconcile o
762
858
763
859
However, for larger clusters or scenarios with frequent Pod update events, these unnecessary reconciles will block the real CloneSet reconciles, resulting in delayed rolling updates and other changes.
764
860
To solve this problem, you can enable the **feature-gate CloneSetEventHandlerOptimization** to reduce some unnecessary reconcile enqueues.
0 commit comments