kubectl: Pod with deletionTimestamp shown as Terminating after Failed/Succeeded

[alculquicondor]

What happened?

A pod with a finalizer and a deletion timestamp is listed as "Terminating" in kubectl get and describe, even after the phase is Failed/Succeeded

What did you expect to happen?

The phase Failed or Succeeded to be shown

How can we reproduce it (as minimally and precisely as possible)?

1. Create a long running pod with a finalizer
2. Issue a pod delete
3. Use kubectl get -o wide or kubectl describe to see the pod.

Anything else we need to know?

This causes confusion, as the Pod doesn't account for any resource usage when its Failed or Succeeded. This should be backported to all supported versions.

Kubernetes version

master

Cloud provider

N/A

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

[k8s-ci-robot]

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.

[alculquicondor]

/sig cli

[lowang-bh]

/assign

[alculquicondor]

any progress on this?

[lowang-bh]

Hi, @alculquicondor , one thing to be comfirm: just need to change the Terminating to what as phase shows when use kubect get pod if pod has deletionTimestamp, right?

[alculquicondor]

Yes, I would say Succeeded or Failed. Terminating only makes sense if the Pod is in phase Running and has the deletionTimestamp. Although I don't know if anyone in SIG CLI disagrees. Worth confirming.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[alculquicondor]

/remove-lifecycle stale

[brianpursley]

/transfer kubectl

[mpuckett159]

In addition to the linked PR, in pkg/describe it looks like this is being set statically/manually (search for "Terminating") and this will probably be confusing and need to be cleaned up as well so that describe is not setting things that contradict get.

/triage accepted

[brianpursley]

My only concern is whether users need to know that a finalizer is pending, but "Terminating" status doesn't distinguish between waiting for containers to exit and waiting for finalizers to complete, so this proposed change makes it more clear what is happening.

If people need to know that finalizers are pending, versus just seeing Completed or Failed, we could potentially show a status of "Finalizing", but that hasn't been asked for yet as far as I know.