Pod life cycle

Pod can have multiple containers in which applications run, but it may also have one or more Init containers that start before the application container

The Init container is very similar to an ordinary container, except for the following two points:

• The Init container always runs until successful completion
• Each Init container must complete successfully before the next Init container starts

If the Init container of the Pod fails, Kubernetes will restart the Pod continuously until the Init container succeeds. However, if the restart policy corresponding to Pod is Never, it will not restart

Because the Init container has a separate image from the application container, their startup related code has the following advantages:

• They can contain and run utilities, but for security reasons, including these utilities in the application container image is not recommended
• Application mirroring can separate the roles of creation and deployment without the need to combine them to build a separate image
• The Init container uses the Linux Namespace, so it has a different view of the file system than the application container. Therefore, they can have access to Secret, while application containers cannot
• They must run before the application container starts, and the application container runs in parallel, so the Init container can provide a simple way to block or delay the start of the application container until a set of prerequisites are met

Special instructions:

• During Pod startup, the Init container starts sequentially after the initialization of the network and data volume. Each container must exit successfully before the next container starts
• If the container fails to start due to runtime or exit failure, it will retry according to the policy specified in the restart policy of Pod. However, if the restart policy of Pod is set to Always, the Init container will use the restart policy if it fails
• Before all Init containers fail, Pod will not become Ready. The port of Init container will not be aggregated in Service. The Pod being initialized is in Pending state, but the Initializing state should be set to true
• If the Pod restarts, all Init containers must be re executed
• The modification of Init container spec is limited to the container image field, and the modification of other fields will not take effect. Changing the image field of Init container is equivalent to restarting the Pod

Init container

init template

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.34.1
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.34.1
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.34.1
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
---
kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377

The Init container has all the fields of the application container. Except readinessProbe, because the Init container cannot define a state other than readiness different from completion. This is enforced during validation

The name of each app and Init container in Pod must be unique; Sharing the same name with any other container will throw an error during validation

The probe is a periodic diagnosis of the container performed by kubelet. To perform diagnostics, kubelet calls the Handler implemented by the container. There are three types of handlers:

• ExecAction: executes the specified command in the container. If the return code is 0 when the command exits, the diagnosis is considered successful.
• TCPSocketAction: TCP checks the IP address of the container on the specified port. If the port is open, the diagnosis is considered successful.
• HTTPGetAction: execute an HTTP Get request on the IP address of the container on the specified port and path. If the status code of the response is greater than or equal to 200 and less than 400, the diagnosis is considered successful

Each probe will get one of the following three results:

• Success: the container passed the diagnosis
• Failed: container failed diagnostics
• Unknown: diagnosis failed, so no action will be taken

livenessProbe: indicates whether the container is running. If the survival probe fails, kubelet will kill the container and the container will be affected by its restart strategy. If the container does not provide a survival probe, the default state is Success

readinessProbe: indicates whether the container is ready for Service requests. If the ready probe fails, the endpoint controller will delete the IP address of the Pod from the endpoints of all services matching the Pod. The ready state before the initial delay defaults to Failure. If the container does not provide a ready probe, the default state is Success

Detection probe - ready detection

readinessProbe-httpget

apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace: default
  labels: 
    app: myapp
spec:
  containers:
  - name: readiness-httpget-container
    image: wangyanglinux/myapp:v1
    imagePullPolicy: IfNotPresent
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3

Detection probe - survival detection

livenessProbe-exec

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: busybox:1.34.1
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh", "-c", "touch /tmp/live; sleep 60; rm -rf /tmp/live; sleep 3600"]
    livenessProbe:
      exec:
        command: ["test", "-e", "/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3

livenessProbe-httpget

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: wangyanglinux/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 3

livenessProbe-tcp

apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
spec:
  containers:
  - name: nginx
    image: wangyagnlinux/myapp:v1
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 80

Pod Hook is initiated by kubelet managed by Kubernetes. It runs before the process in the container starts or before the process in the container terminates, which is included in the life cycle of the container. You can configure hook for all containers in the pod at the same time

There are two types of hooks:

• exec: execute a command
• Http: send HTTP request

Start and exit actions

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: wangyanglinux/myapp:v1
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the poststop handler > /usr/share/message"]

Comprehensive example

apiVersion: v1
kind: Pod
metadata: 
  labels:
    app: myapp
  name: test
  namespace: default
spec:
  containers:
  - image: wangyanglinux/myapp:v1
    name: myapp
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 3
    livenessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 3
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the poststop handler > /usr/share/message"]
  - name: busybox-1
    image: busybox:1.34.1
    command: ["/bin/sh", "-c", "touch /tmp/live; sleep 60; rm -rf /tmp/live; sleep 3600"]
    readinessProbe:
      exec:
        command: ["test", "-e", "/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3
    livenessProbe:
      exec:
        command: ["test", "-e", "/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3
  initContainers:
  - name: init-myservice
    image: busybox:1.34.1
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.34.1
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']