This is not strictly correct though, because a pod can cease to be "ready" but not die. We've intentionally NOT drawn this as a state-machine because conditions are really orthogonal concepts. We report a singular status as part of kubectl, so maybe we should document THAT, but it's more complicated than this diagram captures.

@dchen1107 @yujuhong since the kubelet drives most of this.

Yes it'd be useful. Reason is especially until wait conditions are implemented, it's difficult to wait for example until a pod is "at least" started, or "at least" running (i.e. may be terminated already).

There's a bounty on diagrams: kubernetes/website#84

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale