-
Notifications
You must be signed in to change notification settings - Fork 39.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support parallel scaling on StatefulSets #44899
Conversation
3a141ba
to
03b3e2f
Compare
pkg/apis/apps/v1beta1/types.go
Outdated
// StatefulsetBurstAnnotation instructs the stateful set controller to not wait when replacing pods from the set, | ||
// and that it may create pods out of order. If enabling this annotation, ensure that your set is capable of | ||
// forming a safe quorum even if pod creation is out of order. Accepts "true". | ||
StatefulSetBurstAnnotation = "statefulset.alpha.kubernetes.io/burst" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider just making it a field in the Spec? We know we need this functionality, and we already have use cases for it. Starting with an annotation might be more trouble than its worth if we intend to upgrade to a field before GA.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I need to circle back on what exactly what we want to do for this. Will hunt that down.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial proposal in the issue was for an annotation, @bgrant0607 seems to favor just adding the field if we want to evolve it from an annotation to a field. I prefer the field primarily for validation integration and API clarity, but, as the annotation is functionally equivalent, if you want to go in that direction I'm on board.
} | ||
return nil | ||
} | ||
|
||
var _ StatefulSetControlInterface = &defaultStatefulSetControl{} | ||
|
||
// setAllowsBurst is true if the alpha burst annotation is set. | ||
func setAllowsBurst(set *apps.StatefulSet) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move the helper to utils. If you keep the annotation instead of going with a field you're going to have to validate it here. You should report an error to runtime.ReportError if annotations value is not boolean.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we report error here it will rate limit the controller. Argument for a field for sure. I'd say either way we can validate the annotation.
// is created while any pod is unhealthy, and pods are terminated in descending order. The burst | ||
// strategy allows these constraints to be relaxed - pods will be created eagerly and terminated | ||
// in bulk. Clients using the burst strategy should be careful to ensure they understand the consistency | ||
// implications of having unpredictable numbers of pods available. | ||
func (ssc *defaultStatefulSetControl) UpdateStatefulSet(set *apps.StatefulSet, pods []*v1.Pod) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update method internal comments to be consistent with the behavior of out of order creation and termination.
pkg/apis/apps/v1beta1/types.go
Outdated
@@ -25,6 +25,10 @@ import ( | |||
const ( | |||
// StatefulSetInitAnnotation if present, and set to false, indicates that a Pod's readiness should be ignored. | |||
StatefulSetInitAnnotation = "pod.alpha.kubernetes.io/initialized" | |||
// StatefulsetBurstAnnotation instructs the stateful set controller to not wait when replacing pods from the set, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't respect ordered termination either. Basically it preserves uniqueness but not ordering. This is captured in the control loop method comments and should be captured here as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should consider using a field in the Spec instead of an annotation. Comments need to be updated. If you decide to keep the annotation we should do some validation as validation.go won't check for an actual boolean value. Other than that looks good.
@kubernetes/sig-apps-pr-reviews |
Do we need an issue in the features repo? |
One already exists |
Sounds like we have consensus on a field. Although I'm not sure whether we want a struct for "change policy" or whether this is eventually part of the strategy for rollout. I can imagine that the policy during an update is different than normal behavior or initial rollout. |
// if the set does not allow bursting, return immediately | ||
if monotonic { | ||
return nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You want to continue here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, if you are in burst mode we scale all them up immediately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean
if !isCreated(replicas[i]) {
if err := ssc.podControl.CreateStatefulPod(set, replicas[i]); err != nil {
return err
}
if monotonic {
return nil
}
continue
}
since the replica you just created is not going to fall under any of the following cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes, thanks.
The original issue is about forming initial quorum. We can constrain burst during a rollout with rollout-specific parameters (maxSurge-maxUnavailable?). |
It seems appropriate that deployment specific policy overrides / replaces steady state requirements. |
? Better description than "replacementPolicy"? |
Barring broken tests, can I get a final review pass on the rest of the PR (got one for the annotation version)? |
sort.Sort(ascendingOrdinal(pods)) | ||
for ord := 0; ord < len(pods); ord++ { | ||
if !storageMatches(set, pods[ord]) { | ||
return fmt.Errorf("Pods %s does not match the storage specification of StatefulSet %s ", pods[ord].Name, set.Name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/Pods/pod/
} | ||
} | ||
|
||
if !identityMatches(set, pods[ord]) { | ||
return fmt.Errorf("Pods %s does not match the identity specification of StatefulSet %s ", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/Pods/pod/
fnName = fnName[i+1:] | ||
} | ||
t.Run( | ||
fmt.Sprintf("%s/Monotonic", fnName), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
t.Logf ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is the name of the test case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, you get is an an arg, ack
Not sure what do you mean with this one, code lgtm |
I.e. previously this had LGTM before we talked about changing to field.
Just wanted to get a LGTM on this after the field change.
…On Sat, May 20, 2017 at 11:33 AM, Michail Kargakis ***@***.*** > wrote:
got one for the annotation version
Not sure what do you mean with this one, code lgtm
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#44899 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABG_p-5jd2G82UlzX73I0tUtqIzmxfbrks5r7wfXgaJpZM4NG_mo>
.
|
fields lgtm too |
a6b5f3d
to
0b9532b
Compare
The alpha field podManagementPolicy defines how pods are created, deleted, and replaced. The new `Parallel` policy will replace pods as fast as possible, not waiting for the pod to be `Ready` or providing an order. This allows for advanced clustered software to take advantage of rapid changes in scale.
Use subtests to avoid duplicating entire suite of control logic.
@smarterclayton: The following test(s) failed:
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Any other comments? Ready for final review. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kow3ns, smarterclayton
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
Automatic merge from submit-queue (batch tested with PRs 38990, 45781, 46225, 44899, 43663) |
Fixes #41255