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

fix daemon set rolling update hang #77773

Merged
merged 1 commit into from
May 20, 2019
Merged

Conversation

DaiHao
Copy link
Contributor

@DaiHao DaiHao commented May 11, 2019

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind bug

What this PR does / why we need it:

daemon set rolling update hang when there exsits not-ready node in cluster

Which issue(s) this PR fixes:

Fixes #63465

Special notes for your reviewer:
When daemon controller delete pod on not-ready node, pod will stuck in terminating state.
Then informer will not receives pod delete event, which cause expectation never be satisfied and daemon controller not exec manage method.

Does this PR introduce a user-facing change?:

Fix a bug that causes DaemonSet rolling update to hang when its pod gets stuck at terminating. 

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-kind Indicates a PR lacks a `kind/foo` label and requires one. needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels May 11, 2019
@k8s-ci-robot
Copy link
Contributor

Hi @DaiHao. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. 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 needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels May 11, 2019
@DaiHao
Copy link
Contributor Author

DaiHao commented May 11, 2019

/sig apps
/kind bug
/priority important-soon

@k8s-ci-robot k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. and removed needs-kind Indicates a PR lacks a `kind/foo` label and requires one. labels May 11, 2019
@DaiHao
Copy link
Contributor Author

DaiHao commented May 11, 2019

@krmayankk @janetkuo @Kargakis @k82cn PTAL

@k8s-ci-robot k8s-ci-robot added priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. and removed needs-priority Indicates a PR lacks a `priority/foo` label and requires one. labels May 11, 2019
@draveness
Copy link
Contributor

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels May 12, 2019
@draveness
Copy link
Contributor

/assign @soltysh

@DaiHao
Copy link
Contributor Author

DaiHao commented May 12, 2019

/test pull-kubernetes-kubemark-e2e-gce-big

dsc.deletePod(curPod)
return
}

Choose a reason for hiding this comment

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

i am confused how this fixes the issue ? Did you try with this fix and it solves the issue ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The reason why ds rolling update stucked is expectations not be satisfied. In this fix, we lower deletion expectation once pod's DeletionTimestamp is not nil to satisfy expectation and let syncloop resume.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Before this fix, if a pod stucked in terminating, deamonset will never satisfy expectation.

Choose a reason for hiding this comment

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

shouldnt lowering of expectation be done using dsc.expectations.DeletionObserved(dsKey) ?

Choose a reason for hiding this comment

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

@janetkuo could you help understand this fix ? Do we need a test ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

shouldnt lowering of expectation be done using dsc.expectations.DeletionObserved(dsKey) ?

of course you could just use dsc.expectations.DeletionObserved(dsKey)
but in this fix we could reuse the code in "deletePod" and keep code consistent with replicas-controller and job-controller. see #77773 (comment)

@DaiHao
Copy link
Contributor Author

DaiHao commented May 15, 2019

ping @soltysh @janetkuo

pkg/controller/daemon/daemon_controller.go Outdated Show resolved Hide resolved
@janetkuo
Copy link
Member

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DaiHao, 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 May 15, 2019
@janetkuo
Copy link
Member

I just reworded release note.

@janetkuo
Copy link
Member

/assign @k82cn

@answer1991
Copy link
Contributor

awesome work!

@zhangxiaoyu-zidif

@zhangxiaoyu-zidif
Copy link
Contributor

ping @k82cn for lgtm

@answer1991
Copy link
Contributor

answer1991 commented May 16, 2019

is there same issue in ReplicaSet-Controller?

@DaiHao
Copy link
Contributor Author

DaiHao commented May 16, 2019

is there same issue in ReplicaSet-Controller?

job controller and replicaset controller has already contains this logic.

func (jm *JobController) updatePod(old, cur interface{}) {
curPod := cur.(*v1.Pod)
oldPod := old.(*v1.Pod)
if curPod.ResourceVersion == oldPod.ResourceVersion {
// Periodic resync will send update events for all known pods.
// Two different versions of the same pod will always have different RVs.
return
}
if curPod.DeletionTimestamp != nil {
// when a pod is deleted gracefully it's deletion timestamp is first modified to reflect a grace period,
// and after such time has passed, the kubelet actually deletes it from the store. We receive an update
// for modification of the deletion timestamp and expect an job to create more pods asap, not wait
// until the kubelet actually deletes the pod.
jm.deletePod(curPod)
return
}

func (rsc *ReplicaSetController) updatePod(old, cur interface{}) {
curPod := cur.(*v1.Pod)
oldPod := old.(*v1.Pod)
if curPod.ResourceVersion == oldPod.ResourceVersion {
// Periodic resync will send update events for all known pods.
// Two different versions of the same pod will always have different RVs.
return
}
labelChanged := !reflect.DeepEqual(curPod.Labels, oldPod.Labels)
if curPod.DeletionTimestamp != nil {
// when a pod is deleted gracefully it's deletion timestamp is first modified to reflect a grace period,
// and after such time has passed, the kubelet actually deletes it from the store. We receive an update
// for modification of the deletion timestamp and expect an rs to create more replicas asap, not wait
// until the kubelet actually deletes the pod. This is different from the Phase of a pod changing, because
// an rs never initiates a phase change, and so is never asleep waiting for the same.
rsc.deletePod(curPod)
if labelChanged {
// we don't need to check the oldPod.DeletionTimestamp because DeletionTimestamp cannot be unset.
rsc.deletePod(oldPod)
}
return
}

@k82cn
Copy link
Member

k82cn commented May 16, 2019

I'm going to review this PR today :)

@@ -535,6 +535,15 @@ func (dsc *DaemonSetsController) updatePod(old, cur interface{}) {
return
}

if curPod.DeletionTimestamp != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

if oldPod.DeletionTimestamp == nil && curPod.DeletionTimestamp != nil {
...
}

Check oldPod's DeletionTimestamp will be better. Same as ReplicaSet-Controller.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it might reduce the nonsense syncloop.
The only risk I have considered is that once handler(updatePod or deletePod) returns before lowering of expectation, we will also lose the chance to satisfy the expectation.
@k82cn please help to review this PR, thanks

Copy link
Contributor

Choose a reason for hiding this comment

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

If my suggestion is acceptable, please create another PR to fix ReplicaSet-Controller.

@k82cn
Copy link
Member

k82cn commented May 20, 2019

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label May 20, 2019
@k8s-ci-robot k8s-ci-robot merged commit 6ba13bf into kubernetes:master May 20, 2019
@DaiHao DaiHao deleted the daemon branch May 21, 2019 08:33
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. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. 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/XS Denotes a PR that changes 0-9 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

daemonset rollingupdate hang
9 participants