Pod lifecycle in kubernetes

stay Kubernetes in Pod Is the smallest unit of container management , There are all kinds of Pod Manager . So one Pod From start to release , What process did you go through during this period ?

Pod Created since , To normal operation , To release , Its time span and stages are as follows :

Let's talk about the role of each stage and what problems it aims to solve . The process of container scheduling and downloading images is ignored , Nothing to say .

init

stay Pod When you start a container , There can be a group init The container starts first ( Of course, there can be no ), these init The container executes in turn , And after the previous success , The latter will execute . It also monitors init The exit state of the container , if init The container exited abnormally , Will be configured according to restartPolicy Select restart or exit according to the restart policy of ( Exit here , explain Pod Failed to start ). Through the pod.spec.initContainers To configure , Its configuration items are the same as containers identical

init Containers can be applied to the following scenarios :

• Service creation and deployment can be decoupled . To prevent the main container from becoming too bulky
• Detect dependency . Services such as A Must wait for service B Only after the startup is successful can it run , Then you can use the service A Of init Stage to perform cycle detection and wait , Until the service B It's working , Start the service A
• Have access to Secret Authority . Secret It is used to store some sensitive data , Will be encrypted . The main container does not have access , It's easy to understand , If a container is broken , If you can get Secret The data of , It is likely that a series of services will be broken . and init The container in Pod Quit before providing services , Can improve data security .
• wait

Pod stay init Before the container is started , It's not going to provide services to the outside world , Its status is always Pending

start/stop

Hooks that run when the container is started and released . Through the pod.spec.containers.lifecycle.postStart and pod.spec.containers.lifecycle.preStop To configure . The configuration is the same , Here we use postStart For example . The specific configuration can be realized through kubectl explain pod.spec.containers.lifecycle.postStart see , The official documents are very detailed .

#  Execute a set of orders 
postStart: 
  command: ["/bin/sh", "-c", "sleep 1"]
---
#  call  http  Interface notification 
postStart: 
  host: baidu.com
  path: /start
  port: 80

readiness

Ready probe . Check whether the service in the container has been started successfully and can provide external access . Only after the test is successful , Will change the status to ready status (Running). Defined in the configuration file pod.spec.containers.readinessProbe Location . Default success

readiness To solve the problem of service startup time , For example, the container has been started successfully , But the process of providing services has not been started yet , At this point, there will be problems when providing external services . Kubernetes The following three probes are provided :

• ExecAction: Execute the specified command in the container . If the command returns 0, The successful
• TCPSocketAction: The specified port TCP Check , If the port is open , Then you think it's successful
• HTTPGetAction: The specified port HTTP Get request , If the response code interval is [200, 400), Then you think it's successful

Its configuration file is roughly as follows :

#  Command probe 
readinessProbe: 
  exec: 
    command: ["cat", "/tmp/file"]
  #  The following fields are generic ,  The following is not repeated 
  
  #  Maximum number of retries for probe failure ,  If the number exceeds this number, it will be deemed that the detection fails ,  Container start failed .  Default 3
  failureThreshold: 3
  #  Cycle of detection , n Next probe in seconds .  And  failureThreshold  Cooperate to determine the starting time .  Default 10s
  periodSeconds: 1
  #  Wait before performing the first probe 5s.  Default 0s
  initialDelaySeconds: 5
  #  Detection timeout .  Default 1s
  timeoutSeconds: 1
  #  When the probe fails ,  Continuous detection is required 3 Only once do you think you are successful .  Default 1
  successThreshold: 3
  #  When the probe fails ,  Gracefully release the waiting time .  If it exceeds, it will be forced to release 
  terminationGracePeriodSeconds: 5
---
# tcp  probe 
readinessProbe: 
  tcpSocket: 
    host: baidu.com
    port: 80
---
# http  probe 
readinessProbe: 
  httpGet: 
    host: baidu.com
    path: /
    port: 80
    #  Set the requested  header,  It's an array of objects 
    httpHeaders: 
      - name: headerName
        value: headerValue
    #  Request mode . HTTP  or  HTTPS.  Default  HTTP
    scheme: HTTP

liveness

Both survival detection , While the container is executing , Detect whether the container is alive , If the service is no longer available , You need to restart the container . Defined in the configuration file pod.spec.containers.livenessProbe Location . Its configuration items are the same as readiness identical , I won't repeat . Default success

During the operation of the container , Maybe the container is still alive , But the process of providing services inside is dead ( For example, a deadlock ). At this time, the container can no longer provide external services . Such a mechanism is needed to detect whether the service can be provided normally .

Be careful , liveness It's not in readiness It will not start until the detection is completed . It starts almost at the same time , and liveness After the probe failed , This will cause the container to restart , therefore liveness Of initialDelaySeconds Configuration requires a little effort , It will take some time , Wait for the service to start successfully . Otherwise, it may lead to readiness We haven't finished the detection task yet , I was liveness The probe failed and restarted .

startup

Above said liveness And readiness It's running at the same time , By configuring liveness Of initialDelaySeconds Parameter to wait . But for some services , We are not sure how long it will take to start , It would be too uneconomical to prolong the waiting time .

and startup Just to solve it liveness And readiness The question of the order of execution , Completely separate service readiness detection from service survival detection . Defined in the configuration file pod.spec.containers.startupProbe Location , Probe term and readiness identical .

startup After the probe is successfully detected , Then the detection task is handed over to the subsequent detection task . Default success

So we use liveness and startup Cooperate with detection , readiness It seems that there is no place to play .

Link to the original text : https://hujingnb.com/archives/707