Skip to main content

Pod Lifecycle

Pod Phase​

PendingThe Pod has been accepted by the Kubernetes system, but one or more of the Container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while.
RunningThe Pod has been bound to a node, and all of the Containers have been created. At least one Container is still running, or is in the process of starting or restarting.
SucceededAll Containers in the Pod have terminated in success, and will not be restarted.
FailedAll Containers in the Pod have terminated, and at least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system.
UnknownFor some reason the state of the Pod could not be obtained, typically due to an error in communicating with the host of the Pod.

Pod Conditions​

  • ThelastProbeTimefield provides a timestamp for when the Pod condition was last probed.
  • ThelastTransitionTimefield provides a timestamp for when the Pod last transitioned from one status to another.
  • Themessagefield is a human-readable message indicating details about the transition.
  • Thereasonfield is a unique, one-word, CamelCase reason for the condition's last transition.
  • Thestatusfield is a string, with possible values "True", "False", and "Unknown".
  • Thetypefield is a string with the following possible values:
  • PodScheduled: the Pod has been scheduled to a node;
  • Ready: the Pod is able to serve requests and should be added to the load balancing pools of all matching Services;
  • Initialized: all init containers have started successfully;
  • Unschedulable: the scheduler cannot schedule the Pod right now, for example due to lack of resources or other constraints;
  • ContainersReady: all containers in the Pod are ready.

Container Probes​

A Probe is a diagnostic performed periodically by the kubelet on a Container. To perform a diagnostic, the kubelet calls a Handler implemented by the Container.

There are three types of handlers:

Executes a specified command inside the Container. The diagnostic is considered successful if the command exits with a status code of 0.

Performs a TCP check against the Container's IP address on a specified port. The diagnostic is considered successful if the port is open. The TCPSocket probe (tcpSocket) will attempt to open a socket on a predetermined port, and keep trying based on periodSeconds. Once the port can be opened, the container is considered healthy.

Performs an HTTP Get request against the Container's IP address on a specified port and path. The diagnostic is considered successful if the response has a status code greater than or equal to 200 and less than 400. (200-399)

Each probe has one of three results​

  • Success: The Container passed the diagnostic.
  • Failure: The Container failed the diagnostic.
  • Unknown: The diagnostic failed, so no action should be taken.

The kubelet can optionally perform and react to three kinds of probes on running Containers:

  • livenessProbe

Indicates whether the Container is running. If the liveness probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a liveness probe, the default state isSuccess.

  • readinessProbe

Indicates whether the Container is ready to service requests. If the readiness probe fails, the endpoints controller removes the Pod's IP address from the endpoints of all Services that match the Pod. The default state of readiness before the initial delay isFailure. If a Container does not provide a readiness probe, the default state isSuccess.

  • startupProbe

Indicates whether the application within the Container is started. All other probes are disabled if a startup probe is provided, until it succeeds. If the startup probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a startup probe, the default state isSuccess

Bothreadinessprobe andlivenessprobe seem to have same behavior. They do same type of checks. But the action they take in case of failures is different.

Readiness Probe shuts the traffic from service down. so that service can always send the request to healthy pod whereas the liveness probe restarts the pod in case of failure. It does not do anything for the service. Service continues to send the request to the pods as usual if it is in 'available' status.

It is recommended to use both probes!!

Configure Probes​

  • initialDelaySeconds: Number of seconds after the container has started before liveness or readiness probes are initiated. Defaults to 0 seconds. Minimum value is 0.
  • periodSeconds: How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1.
  • timeoutSeconds: Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1.
  • successThreshold: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1.
  • failureThreshold: When a Pod starts and the probe fails, Kubernetes will tryfailureThresholdtimes before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready. Defaults to 3. Minimum value is 1.

https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes