Skip to content

pod watch: delete dead pods#1972

Merged
landism merged 3 commits into
masterfrom
matt/delete_pods
Aug 7, 2019
Merged

pod watch: delete dead pods#1972
landism merged 3 commits into
masterfrom
matt/delete_pods

Conversation

@landism

@landism landism commented Aug 2, 2019

Copy link
Copy Markdown
Member

fixes #1862

Problem

If a manifest loses its pod and doesn't get a new pod to replace it, we never remove that pod from its podset, so every time PodLogController's OnChange gets called, it tries to watch the old pod and immediately fails and logs an error, resulting in spam.

Our normal mechanism for removing dead pods from a manifest's podset only kicks in when the podset has one more than one pod (which is normally the case because normally a pod gets deleted when a new pod gets created).

Solution

Delete pods from podset as soon as we see they've been deleted.

@landism
landism requested review from maiamcc and nicks August 2, 2019 16:05

@nicks nicks left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

i have some concerns that it won't be this simple, but it seems safe to try! lgtm

Comment thread internal/engine/pod.go Outdated
ns := k8s.NamespaceFromPod(pod)
hasSynclet := sidecar.PodSpecContainsSynclet(pod.Spec)

if pod.DeletionTimestamp != nil && !pod.DeletionTimestamp.IsZero() && ms.PodSet.Pods != nil {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

i thought we had a separate prunePods function for removing pods? does this logic make more sense there?

Comment thread internal/engine/pod.go Outdated
hasSynclet := sidecar.PodSpecContainsSynclet(pod.Spec)

if pod.DeletionTimestamp != nil && !pod.DeletionTimestamp.IsZero() && ms.PodSet.Pods != nil {
delete(ms.PodSet.Pods, podID)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

hmmm...will the short-lived pod log stuff still work if we remove the pod immediately?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

depends on what you mean by "short-lived pod log stuff"

The case covered by the unit test is a Job, where "short-lived" simply means it isn't in state "Running" for very long - it transitions to "Completed" or "Failed", but doesn't actually get deleted - it still shows up in kubectl get pods, and doesn't have a DeletionTimestamp.

IIUC, the case that might stop working is if a pod gets deleted, we have a chance to grab its logs while it's in the "Terminating" state, but getting logs from a "Terminating" pod is always going to be a race condition, because it might be gone by the time we try to get the logs.

@maiamcc maiamcc left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🙌 amazing! (tbh my solution was just gonna be changing the log level of "error streaming logs" so this is much better 😬 )

@landism
landism merged commit 7e3e81e into master Aug 7, 2019
@landism
landism deleted the matt/delete_pods branch August 7, 2019 20:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

"error streaming ___ logs" spam after pod terminates

3 participants