@@ -13,7 +13,8 @@ of its primary containers starts OK, and then through either the `Succeeded` or
|
|||||||
|
|
||||||
Whilst a Pod is running, the kubelet is able to restart containers to handle some
|
Whilst a Pod is running, the kubelet is able to restart containers to handle some
|
||||||
kind of faults. Within a Pod, Kubernetes tracks different container
|
kind of faults. Within a Pod, Kubernetes tracks different container
|
||||||
[states](#container-states) and handles
|
[states](#container-states) and determines what action to take to make the Pod
|
||||||
|
healthy again.
|
||||||
|
|
||||||
In the Kubernetes API, Pods have both a specification and an actual status. The
|
In the Kubernetes API, Pods have both a specification and an actual status. The
|
||||||
status for a Pod object consists of a set of [Pod conditions](#pod-conditions).
|
status for a Pod object consists of a set of [Pod conditions](#pod-conditions).
|
||||||
@@ -32,7 +33,7 @@ Like individual application containers, Pods are considered to be relatively
|
|||||||
ephemeral (rather than durable) entities. Pods are created, assigned a unique
|
ephemeral (rather than durable) entities. Pods are created, assigned a unique
|
||||||
ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled
|
ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled
|
||||||
to nodes where they remain until termination (according to restart policy) or
|
to nodes where they remain until termination (according to restart policy) or
|
||||||
deletion.
|
deletion.
|
||||||
If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node
|
If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node
|
||||||
are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
|
are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user