[Cloud native] Container life cycle callback/strategy/pointer learning in k8s

Personal homepage: Conquering bugs-CSDN blog

kubernetes column: kubernetes_Conquering bug blog-CSDN blog

Table of contents

2 Container lifecycle callbacks/events/hooks

4 Customize the container startup command

1 Container life cycle

Kubernetes tracks the state of each container in a Pod, just as it tracks the stage of the Pod as a whole. You can use container lifecycle callbacks to trigger events at specific points in the container lifecycle.

Once the scheduler dispatches the pod to a node, kubeletthe container runtime starts creating containers for the pod. There are three states for a container: Waiting(waiting), Running(running), and Terminated(terminated).

To check the status of the containers in the Pod, you can use kubectl describe pod <pod 名称>. Its output contains the status of each container in the Pod.

Each state has a specific meaning:

Waiting(wait)

If the container is not in one of the Runningor Terminatedstates, it is in Waitingstate. The container in Waitingthe state is still running and it completes the operations required to start: for example, pulling the container image from a container mirror repository, or applying Secret data to the container, and so on. When you use kubectlto query Waitinga Pod that contains a container in the state, you will also see a Reason field that gives the reason the container is in the waiting state.

Running(running)

RunningStatus indicates that the container is executing and no problems have occurred. If a callback is configured postStart, it has executed and completed. If you use kubectlto query RunningPods that contain containers in state , you will also see Runninginformation about containers entering state.

Terminated(terminated)

A container in Terminatedstate has started executing and either ended normally or failed for some reason. If you use kubectlto query Terminateda Pod that contains a container in the state, you'll see the reason the container entered this state, the exit code, and the start and end times during the container's execution.

If the container is configured with preStopa callback, the callback will Terminatedbe executed before the container enters the state.

2 Container lifecycle callbacks/events/hooks

Similar to many programming language frameworks with lifecycle callback components, such as Angular, Vue, Kubernetes provide lifecycle callbacks for containers. Callbacks enable a container to be aware of events in its management lifecycle and run code implemented in handlers when the corresponding lifecycle callback is executed.

There are two callbacks exposed to the container:

PostStartThis callback is executed immediately after the container is created. However, there is no guarantee that the callback will be executed before the container entry point (ENTRYPOINT). No parameters are passed to the handler.
PreStopThis callback is called before the container is terminated due to an API request or a management event (such as a liveness probe, failure to start a probe, resource preemption, resource competition, etc.). The call to the preStop callback will fail if the container is already in the terminated or completed state. The callback must finish executing before the TERM signal used to stop the container is issued. The Pod's termination grace period PreStopstarts counting before the callback is executed, so regardless of the execution result of the callback function, the container will eventually be terminated within the Pod's termination grace period. No arguments will be passed to the handler.
Using container lifecycle callbacks

# nginx-pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.19
      lifecycle:
        postStart: #容器创建过程中执行
          exec:
            command: ["/bin/sh","-c","echo postStart >> /start.txt"]
        preStop:  #容器终止之前执行
          exec:
            command: ["/bin/sh","-c","echo postStop >> /stop.txt && sleep 5"]
      ports:
            - containerPort: 80

3 Container restart strategy

The Pod speccontains a restartPolicyfield whose possible values include Always(总是重启)、OnFailure(容器异常退出状态码非 0,重启) 和 Never. The default value is Always.

restartPolicyApplies to all containers in the Pod. restartPolicyOnly kubeletrestart actions for containers on the same node. When a container in a Pod exits, kubeleta restart delay (10s, 20s, 40s, ...) is calculated in an exponential back-off manner, with a maximum delay of 5 minutes. Once a container has been running for 10 minutes without issues, kubeletreset the container's restart fallback timer.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.19
      imagePullPolicy: IfNotPresent
  restartPolicy: Always # OnFailure Never

4 Customize the container startup command

Like the Docker container, the container in k8s can also be used to modify the default execution command of the container startup and pass related parameters through command and args. However, it is generally recommended to use command to modify the startup command, and use args to pass parameters for the startup command.

apiVersion: v1
kind: Pod
metadata:
  name: redis
  labels:
    app: redis
spec:
  containers:
    - name: redis
      image: redis:5.0.10
      command: ["redis-server"] #用来指定启动命令
      args: ["--appendonly yes"] # 用来为启动命令传递参数
      #args: ["redis-server","--appendonly yes"] # 单独使用修改启动命令并传递参数
      #args:                                     # 另一种语法格式
      #  - redis-server
      #  - "--appendonly yes"
      imagePullPolicy: IfNotPresent
  restartPolicy: Always

5 container probe

probe is a periodic diagnostic performed by the kubelet on the container. To perform diagnostics, the kubelet can either execute code inside the container or make a network request.

Definition: The container probe is used to periodically check the health of the container.

detection type

For running containers, kubeletyou can choose whether to execute the following three probes, and how to react to the probe results:

livenessProbe Indicates whether the container is running . If the liveness probe fails, the kubelet will kill the container, and the container will decide the future according to its restart policy. If the container does not provide a liveness probe, the default state is Success.
readinessProbeIndicates whether the container is ready to serve requests . If the readiness probe fails, the endpoint controller removes the pod's IP address from the endpoint list for all services that match the pod. The state value of ready before the initial delay defaults to Failure. If the container does not provide a readiness probe, the default state is Success.
startupProbe 1.7+Indicates whether the application in the container has been started . If a startup probe is provided, all other probes are disabled until this one succeeds. If the start probe fails, kubeletthe container will be killed, and the container will be restarted according to its restart policy. The default state is if the container does not provide a start probe Success.

probe mechanism

There are four different ways to use probes to inspect containers. Each probe must be precisely defined as one of these four mechanisms:

exec

Execute the specified command inside the container. The diagnostic is considered successful if the command exits with a return code of 0.
grpc

Execute a remote procedure call using gRPC. The target should implement gRPC health checks. The diagnosis is considered successful if the status of the response is "SERVING". The gRPC probe is an Alpha feature and will only work if you enable the "GRPCContainerProbe" feature gate.
httpGet

Executes an HTTP request to the specified port and path on the container's IP address GET. A diagnosis is considered successful if the response has a status code greater than or equal to 200 and less than 400.
tcpSocket

Performs a TCP check on the specified port on the container's IP address. The diagnosis is considered successful if the port is open. It is considered healthy if the remote system (container) closes the connection immediately after opening it.

Probe Results

Each probe will have one of three results:

Success(Success) The container passed the diagnostics.
Failure(FAIL) The container failed diagnostics.
UnknownThe (unknown) diagnostic failed, so no action will be taken.

Probe parameters

initialDelaySeconds: 5 #Initialization time 5s
periodSeconds: 4 #Detection interval time 4s
timeoutSeconds: 1 #The default detection timeout is 1s
failureThreshold: 3 #The default number of failures is 3 times, and restart the pod after reaching 3 times
successThreshold: 1 #The default number of successes is 1, and 1 successful detection means success

use probe

exec

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  labels:
    exec: exec
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80
    args:
    - /bin/sh
    - -c
    - sleep 7;nginx -g "daemon off;" #这一步会和初始化同时开始运行，也就是在初始化5s后和7秒之间，会检测出一次失败，7秒后启动后检测正常，所以pod不会重启
    imagePullPolicy: IfNotPresent
    livenessProbe:
      exec:    #这里使用 exec 执行 shell 命令检测容器状态
        command:  
        - ls
        - /var/run/nginx.pid  #查看是否有pid文件
      initialDelaySeconds: 5   #初始化时间5s
      periodSeconds: 4    #检测间隔时间4s
      timeoutSeconds: 1   #默认检测超时时间为1s
      failureThreshold: 3   #默认失败次数为3次，达到3次后重启pod
      successThreshold: 1   #默认成功次数为1次，1 次代表成功

说明：

1. If sleep 7s, the first detection fails, but after the second detection succeeds, the container is always in a healthy state and will not restart.
1. If sleep for 30s, the first detection fails, and more than 3 detections also fail, k8s will kill the container and restart it, and repeat this process.

tcpSocket

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcpsocket
  labels:
    tcpsocket: tcpsocket
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80
    args:
    - /bin/sh
    - -c
    - sleep 7;nginx -g "daemon off;"  #这一步会和初始化同时开始运行，也就是在初始化5s后和7秒之间，会检测出一次失败，7秒后启动后检测正常，所以pod不会重启
    imagePullPolicy: IfNotPresent
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5   #初始化时间5s
      periodSeconds: 4    #检测间隔时间4s
      timeoutSeconds: 1   #默认检测超时时间为1s
      failureThreshold: 3   #默认失败次数为3次，达到3次后重启pod
      successThreshold: 1   #默认成功次数为1次，1 次代表成功

httpGet

# probe-liveness-httget.yml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget
  labels:
    httpget: httpget
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80
    args:
    - /bin/sh
    - -c
    - sleep 7;nginx -g "daemon off;" #这一步会和初始化同时开始运行，也就是在初始化5s后和7秒之间，会检测出一次失败，7秒后启动后检测正常，所以pod不会重启
    imagePullPolicy: IfNotPresent
    livenessProbe:
      httpGet:     #httpget
        port: 80   #访问的端口
        path: /index.html   #访问的路径
      initialDelaySeconds: 5   #初始化时间5s
      periodSeconds: 4    #检测间隔时间4s
      timeoutSeconds: 1   #默认检测超时时间为1s
      failureThreshold: 3   #默认失败次数为3次，达到3次后重启pod
      successThreshold: 1   #默认成功次数为1次，1 次代表成功

GRPC probe

Official reference address: Configure Survival, Readiness and Startup Probes | Kubernetes