Skip to content
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

Make StatefulSet restart pods with phase Succeeded #120398

Merged

Conversation

aleksandra-malinowska
Copy link
Contributor

@aleksandra-malinowska aleksandra-malinowska commented Sep 4, 2023

What type of PR is this?

/kind bug
/sig apps

What this PR does / why we need it:

After the changes in #115331, pod phase determination changed. It is now possible for StatefulSet pods to get in Succeeded pod phase. This can happen when a pod is evicted or a node is stopped and the pod container exists with 0. StatefulSet should restart such pods. It is not possible for a StatefulSet pod to ever truly complete, as validation enforces restartPolicy=Always.

Which issue(s) this PR fixes:

Part of #118310

Does this PR introduce a user-facing change?

Fixes an issue where StatefulSet might not restart a pod after eviction or node failure.

/cc @mimowo

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/bug Categorizes issue or PR as related to a bug. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Sep 4, 2023
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

@k8s-ci-robot k8s-ci-robot added needs-priority Indicates a PR lacks a `priority/foo` label and requires one. sig/apps Categorizes an issue or PR as relevant to SIG Apps. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Sep 4, 2023
Copy link
Contributor

@mimowo mimowo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also like to have an integration test, if feasible.

//
// Also note that it is impossible for StatefulSet pods to ever truly complete,
// as validation allows only restartPolicy=Always.
if isFinished(replicas[i]) {
ssc.recorder.Eventf(set, v1.EventTypeWarning, "RecreatingFailedPod",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is better to issue a dedicated event RecreatingSucceededPod. This is what we do for daemon set in the analogous case: https://github.com/kubernetes/kubernetes/pull/117073/files

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this level of granularity in event type tbh. Maybe we could have event like RecreatingPod (both here and elsewhere - happy to fix), and add the more detailed reason only in description?

Or:
event type - what happened
reason/message - why it happened

kind of like scheduler only has generic event type for failed scheduling, but gives detailed information in the reason. WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially, but I'm concerned about backwards compatibility as this would mean renaming an existing event type. I would suggest decoupling this to a dedicated discussion / PR. @alculquicondor wdyt?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I would do it all over again, I would call it: RecreatingTerminatedPod. But since it says Failed, I prefer we keep the existing one and add a new one for Succeeded, like we did for DaemonSet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on discussion on sig-apps slack:

  • we need to be careful with renaming events of type warning (so, RecreateFailedPod stays as it is),
  • just recreating a pod should be emitted as a normal event, not warning.

@alculquicondor DaemonSet events are already different - I might be missing something, but I haven't found any 'recreate' events, only FailedDaemonPod and SucceededDaemonPod informing of deleting the pod. So I'm not sure if we need to name the new event RecreateSucceededPod, as there's already little consistency. I think we can use RecreateTerminatedPod here, and it'll be much clearer to the user.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I mean about Daemonset is that there used to be only one event FailedDaemonPod and we added SucceededDaemonPod. So for StatefulSet we should do something similar and add RecreateSucceededPod. A normal event makes sense.

t.Error(err)
}
if isCreated(pods[0]) {
t.Error("StatefulSet did not recreate failed Pod")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
t.Error("StatefulSet did not recreate failed Pod")
t.Error("StatefulSet did not recreate succeeded Pod")

Comment on lines 386 to 387
// Also note that it is impossible for StatefulSet pods to ever truly complete,
// as validation allows only restartPolicy=Always.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would remove this last paragraph. It is confusing, as we can see that it will actually complete in case of VM preemption or node pressure.

if err != nil {
t.Error(err)
}
pods[0].Status.Phase = v1.PodSucceeded
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the only difference with RecreatesFailedPod? Can we deduplicate by adding a function that returns a function?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's leave it for a follow up, given the cherry-pick deadline.

Copy link
Member

@alculquicondor alculquicondor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve
/assign @soltysh @janetkuo

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Sep 8, 2023
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: a0b3260f4d222dff23d857bb72b8bff0c446eb00

@aleksandra-malinowska
Copy link
Contributor Author

/retest

Copy link
Member

@janetkuo janetkuo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alculquicondor, aleksandra-malinowska, janetkuo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 13, 2023
@alculquicondor
Copy link
Member

/retest
#119600

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/bug Categorizes issue or PR as related to a bug. lgtm "Looks good to me", indicates that a PR is ready to be merged. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/apps Categorizes an issue or PR as relevant to SIG Apps. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants