kubernetes concepts -- Pod Lifecycle

Pod Lifecycle

This page describes the lifecycle of a Pod.

Pod phase

A Pod’s status field is a PodStatus object, which has a phase field.

The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle. The phase is not intended to be a comprehensive rollup of observations of Container or Pod state, nor is it intended to be a comprehensive state machine.

The number and meanings of Pod phase values are tightly guarded. Other than what is documented here, nothing should be assumed about Pods that have a given phase value.

Pod的status域是一個PodStatus對象，包含phase域。phase描述了Pod的狀態。

• Pending表示kubernetes接受到請求，可是容器尚未被建立完成。多是由於在調度、下載鏡像。
• Running表示Pod被建立完成，Pod中全部的容器被建立完成，至少一個容器還在運行或者在重啓。
• Successed表示Pod中全部的容器都被終止，且不會被重啓。
• Failed表示Pod中全部容器都被終止，至少一個容器沒有被正常終止，即容器終止後返回非零或者系統終止容器。
• Unknown，沒法獲取Pod的狀態，通常是因爲Pod所在物理機的通訊異常。

 

Here are the possible values for phase:

• Pending: The 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.

• Running: The 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.

• Succeeded: All Containers in the Pod have terminated in success, and will not be restarted.

• Failed: All 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.

• Unknown: For 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

A Pod has a PodStatus, which has an array of PodConditions. Each element of the PodCondition array has a type field and a status field. The type field is a string, with possible values PodScheduled, Ready, Initialized, and Unschedulable. The status field is a string, with possible values True, False, and Unknown.

PodStatus是PodConditions數組。其中PodCondition有type域和status域。 type是一個字符串，可選值有PodScheduled、Ready、Initialized、Unschedulable。status域是一個字符串，可選值有True、False和Unkown。

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:

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

• TCPSocketAction: Performs a TCP check against the Container’s IP address on a specified port. The diagnostic is considered successful if the port is open.

• HTTPGetAction: 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.

探針是kubelet在容器上週期進行的診斷，經過調用容器實現的Handler實現診斷。有三種handler：

• ExecAction，執行容器中的特定命令，返回0時表示診斷成功。
• TCPSocketAction，對容器的IP地址上的特定端口進行TCP檢查。若是端口被監聽，則診斷成功。
• HTTPGetAction，對容器的特定端口和路徑執行HTTP Get請求。若是返回狀態碼大於等於200且小於400，則診斷成功。

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.

每一個探針有三種結果：

• Success，經過診斷
• Failure，沒有經過診斷
• Unknown，診斷過程失敗，so no action should be taken.

The kubelet can optionally perform and react to two 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 is Success.

• 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 is Failure. If a Container does not provide a readiness probe, the default state is Success.

kubelet能夠選擇性地執行兩種探針，並對結果進行處理。探針有：

• livenessProbe，檢查容器是否在運行。若是診斷失敗，kubelet會殺掉容器，根據restart policy處理容器。默認爲Success。
• readinessProbe，檢查容器是否能夠處理service requests。若是readinessProbe失敗了，endpoints controller會將Pod從全部知足條件的service endPoints中刪除。初始化延遲以前，默認readiness 狀態是Failure。若是容器不包含readinessProbe，默認值爲Success。

When should you use liveness or readiness probes?

If the process in your Container is able to crash on its own whenever it encounters an issue or becomes unhealthy, you do not necessarily need a liveness probe; the kubelet will automatically perform the correct action in accordance with the Pod’s restartPolicy.

If you’d like your Container to be killed and restarted if a probe fails, then specify a liveness probe, and specify a restartPolicy of Always or OnFailure.

If you’d like to start sending traffic to a Pod only when a probe succeeds, specify a readiness probe. In this case, the readiness probe might be the same as the liveness probe, but the existence of the readiness probe in the spec means that the Pod will start without receiving any traffic and only start receiving traffic after the probe starts succeeding.

If you want your Container to be able to take itself down for maintenance, you can specify a readiness probe that checks an endpoint specific to readiness that is different from the liveness probe.

Note that if you just want to be able to drain requests when the Pod is deleted, you do not necessarily need a readiness probe; on deletion, the Pod automatically puts itself into an unready state regardless of whether the readiness probe exists. The Pod remains in the unready state while it waits for the Containers in the Pod to stop.

若是容器中的進程能夠在遇到問題或錯誤時本身掛掉，那麼就不須要liveness probe，kubelet會根據Pod的重啓策略自動執行相應的行動。

若是當探針失敗時，須要重啓容器，那麼就設置一個liveness probe，設置restartPolicy爲Always或OnFailure。

若是當探針成功時，想要向Pod開始發送請求，那麼就設置一個readiness probe。這時readiness probe可能相似於liveness probe。可是spec中的readiness probe還表示，只有當readiness probe成功後，pod纔會開始接收到請求。

若是你想讓容器由於維護自行掛掉，那麼須要設置單獨檢查readiness的readiness probe，而且和liveness probe不一樣。

若是你想讓被刪除的Pod不接受請求，那麼不須要設置readiness probe。當Pod被刪除時，pod的狀態變爲unready state，無論是否存在readiness probe，並一直保存這個狀態，等待Pod中的容器被關掉。

Pod and Container status

For detailed information about Pod Container status, see PodStatus and ContainerStatus. Note that the information reported as Pod status depends on the current ContainerState.

關於容器的狀態，能夠參考PodStatus和ContainerStatus。Pod status依賴當前的容器狀態。

Restart policy

A PodSpec has a restartPolicy field with possible values Always, OnFailure, and Never. The default value is Always. restartPolicy applies to all Containers in the Pod. restartPolicy only refers to restarts of the Containers by the kubelet on the same node. Failed Containers that are restarted by the kubelet are restarted with an exponential back-off delay (10s, 20s, 40s …) capped at five minutes, and is reset after ten minutes of successful execution. As discussed in thePods document, once bound to a node, a Pod will never be rebound to another node.

Pod spec有個restartPolicy域，可選值有Always、OnFailure、Never。默認值爲Always。restartPolicy被應用到Pod中的全部容器，只涉及同一節點上kubelet對容器的重啓。掛掉的容器被kubelet重啓時，延時會成指數級增加（10s，20s，40s...），上限爲5分鐘，重啓成功10分鐘後延時被重置。一旦某個Pod被綁定到一個節點，就不再會被綁定到其餘節點。

Pod lifetime

In general, Pods do not disappear until someone destroys them. This might be a human or a controller. The only exception to this rule is that Pods with a phaseof Succeeded or Failed for more than some duration (determined by the master) will expire and be automatically destroyed.

Three types of controllers are available:

• Use a Job for Pods that are expected to terminate, for example, batch computations. Jobs are appropriate only for Pods with restartPolicy equal to OnFailure or Never.

• Use a ReplicationController, ReplicaSet, or Deployment for Pods that are not expected to terminate, for example, web servers. ReplicationControllers are appropriate only for Pods with a restartPolicy of Always.

• Use a DaemonSet for Pods that need to run one per machine, because they provide a machine-specific system service.

All three types of controllers contain a PodTemplate. It is recommended to create the appropriate controller and let it create Pods, rather than directly create Pods yourself. That is because Pods alone are not resilient to machine failures, but controllers are.

If a node dies or is disconnected from the rest of the cluster, Kubernetes applies a policy for setting the phase of all Pods on the lost node to Failed.

通常狀況下，除非人或者controller把Pod刪掉，Pod永遠不會消失。對於Succeeded 或Failed的Pods，當狀態持續時間超過必定時間（master決定）後，就會超時而後被自動消耗。

有三種Controller：

• Job，須要關閉Pods，例如批量計算。要求設置restartPolicy爲OnFailure或Never。
• ReplicationController、ReplicaSet、Deployment，不要求關閉Pods，例如web servers。RC要求restartPolicy爲Always。
• DaemonSet，每一個機器上運行一個Pod，由於提供特定機器的系統服務。

全部的controller都包含Pod template。建議建立適合的controller，而後由controller建立Pods，而不是直接建立Pods。若是節點掛掉或失聯，kubernetes會將該節點上全部Pods的phase設置爲Failed。

Examples

Advanced liveness probe example

Liveness probes are executed by the kubelet, so all requests are made in the kubelet network namespace.

apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - args: - /server image: k8s.gcr.io/liveness livenessProbe: httpGet: # when "host" is not defined, "PodIP" will be used # host: my-host # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed # scheme: HTTPS path: /healthz port: 8080 httpHeaders: - name: X-Custom-Header value: Awesome initialDelaySeconds: 15 timeoutSeconds: 1 name: liveness 

Example states

• Pod is running and has one Container. Container exits with success.
  • Log completion event.
  • If restartPolicy is:
    • Always: Restart Container; Pod phase stays Running.
    • OnFailure: Pod phase becomes Succeeded.
    • Never: Pod phase becomes Succeeded.
• Pod is running and has one Container. Container exits with failure.
  • Log failure event.
  • If restartPolicy is:
    • Always: Restart Container; Pod phase stays Running.
    • OnFailure: Restart Container; Pod phase stays Running.
    • Never: Pod phase becomes Failed.
• Pod is running and has two Containers. Container 1 exits with failure.
  • Log failure event.
  • If restartPolicy is:
    • Always: Restart Container; Pod phase stays Running.
    • OnFailure: Restart Container; Pod phase stays Running.
    • Never: Do not restart Container; Pod phase stays Running.
  • If Container 1 is not running, and Container 2 exits:
    • Log failure event.
    • If restartPolicy is:
      • Always: Restart Container; Pod phase stays Running.
      • OnFailure: Restart Container; Pod phase stays Running.
      • Never: Pod phase becomes Failed.
• Pod is running and has one Container. Container runs out of memory.
  • Container terminates in failure.
  • Log OOM event.
  • If restartPolicy is:
    • Always: Restart Container; Pod phase stays Running.
    • OnFailure: Restart Container; Pod phase stays Running.
    • Never: Log failure event; Pod phase becomes Failed.
• Pod is running, and a disk dies.
  • Kill all Containers.
  • Log appropriate event.
  • Pod phase becomes Failed.
  • If running under a controller, Pod is recreated elsewhere.
• Pod is running, and its node is segmented out.
  • Node controller waits for timeout.
  • Node controller sets Pod phase to Failed.
  • If running under a controller, Pod is recreated elsewhere.

What’s next

• Get hands-on experience attaching handlers to Container lifecycle events.

• Get hands-on experience configuring liveness and readiness probes.

• Learn more about Container lifecycle hooks.