podStatusPhases support containercreating status

[lovejoy]

Is your feature request related to a problem? Please describe.

some network issue or cni issue may cause pods always containercreating
sth like #62
Describe the solution you'd like

podStatusPhases now only support Running and Pending should add some other status

[damemi]

ContainerCreating isn't a valid pod status phase, which is what we check for: https://github.com/kubernetes/api/blob/v0.21.1/core/v1/types.go#L2506-L2526. I'm not sure how kubectl determines the ContainerCreating status but we could look into what that technically is so that we can check for it

[lovejoy]

@damemi https://github.com/kubernetes/api/blob/v0.21.1/core/v1/types.go#L2415-L2421

[damemi]

Thanks @lovejoy
So it looks like to add this, we would need to add logic to do the following:

for each pod
  for each container
    if containerStatus.State.Waiting != nil && containerStatus.State.Waiting.Reason == "ContainerCreating"
      evict this pod

We could add this logic into where we currently check status phases.

[bytetwin]

If a pod has multiple containers and only one of them is stuck in ContainerCreating state, how should we deal with the eviction ? The pod may be unusable with the stuck container, so does it make sense to evict ?

[damemi]

That is a good question. I don't think we will be able to accurately answer it without gathering more user feedback, though it sounds like from this request if any container is ContainerCreating, that will trigger the kubectl output status that @lovejoy is requesting to act on

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[seanmalloy]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[a7i]

Thanks @lovejoy So it looks like to add this, we would need to add logic to do the following:

for each pod
  for each container
    if containerStatus.State.Waiting != nil && containerStatus.State.Waiting.Reason == "ContainerCreating"
      evict this pod

We could add this logic into where we currently check status phases.

This would also help with CrashLoopBackoff containers. i.e. containerStatus.State.Waiting.Reason == "CrashLoopBackoff". We are moving off of an in-house tool so I would be open to proposing a PR in the next few days. Any ideas on what the schema should look like?

  "PodLifeTime":
     enabled: true
     params:
       podLifeTime:
         maxPodLifeTimeSeconds: 86400
         reasons:
         - "CrashLoopBackoff"
         - "ContainerWaiting"
         podStatusPhases:
         - "Pending"
         - "Running"

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[damemi]

/remove-lifecycle rotten

@a7i sorry, this slipped for me... I think it might be confusing for some users to have phases and reasons as separate fields. We've seen a couple reports of people asking why podStatusPhases doesn't support a specific phase, when it's not actually a phase (similar to this one)

It might be easier for people if we just lump everything into a single field, so they don't need to know the technical details of what the status they see from kubectl is. Do you think there's any potential problems with that?

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[a7i]

/remove-lifecycle rotten

[a7i]

It might be easier for people if we just lump everything into a single field, so they don't need to know the technical details of what the status they see from kubectl is

@damemi I do not see any issues with that. Will work on a PR soon-ish.

[a7i]

/assign