The Init container for the Pod lifecycle
Init container
A Pod can have multiple containers in which the application runs, but it may have one or more Init containers started before the application container
The Init container is very much like a normal container, except for the following:
- The Init container always runs until it completes successfully
- Each Init container must complete successfully before the next Init container starts
If the Pod’s Init container fails, Kubernetes will continue to restart the Pod until the Init container succeeds. However, if the Pod’s corresponding restartPolicy is Nerver, it will not restart
Because Init containers have a separate image from the application container, their boot-related code has the following advantages:
- They can contain and run utilities, but for security reasons, it is not recommended to include them in the application container
- They can include utilities and customizations to install, but they cannot appear in application images, for example, there is no need to create an image FROM another image, just use a tool like sed, AWk, Python, or DIG during installation
- Application mirroring can separate the roles created and deployed without the need to combine them to build a single image
- Init containers use Linux namespaces, so they have a different view of the file system than application containers, so they have access to Secret that application containers do not
- They must be 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
Init template
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox
command: ['sh'.'-c'.'echo The app is runing! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox
command: ['sh'.'-c'.'until nslookup myservice; do echo waiting for myservice; sleep 2; done; ']
- name: init-mydb
image: busybox
command: ['sh'.'-c'.'until nslookup mydb; do echo waiting for mydb; sleep 2; done; ']
Copy the code
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
Copy the code
Special instructions
- During Pod startup, Init containers are started sequentially after network and data volume initialization, and each container must exit successfully before the next container starts
- If exit due to runtime or failure causes the container to start, it will restart according to the policy specified by Pod’s restartPolicy. However, if Pod’s restartPolicy is set to Always, the restartPolicy will be used when the Init container fails
- The Pod will not become Ready until all Init containers have succeeded, and the ports of the Init container will not be aggregated in the Service. The Pode being initialized is in a Pending state, but the Initalizing state should be set to true
- If Pod restarts, all Init containers must be re-executed
- Changes to the spec of the Init container are limited to the image field. Changes to other fields do not take effect. If you change the image field of the Init container, you will restart the Pod
- The Init container has all the fields of the application container, except for readinessProbe, because the Init container cannot define a state other than Readiness for completion, which is enforced during validation
- Each app and Init container in a Pod must have a unique name; sharing a name with any other container throws an error at validation
Container probe for Pod lifecycle
The probe has periodic diagnostics performed by Kubelet on the container. To perform diagnostics, Kubelet calls the Handler implemented by the container. There are three types of handlers:
- ExecAction: Execute 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: Executes a Get request to the container’s IP address 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 yields one of three results:
- Success: The container passed the diagnosis
- Failed: The container failed the diagnosis
- Unknown: Diagnosis failed, so no action will be taken
LivenessProbe probe
Indicates whether the container is running, kubelet kills the container if the survival probe fails, and the container is subject to a restart policy. If the container does not provide a survival probe, the default state is Success
Live detection
livenessProbe-exec
apiVersion: v1
kind: Pod
metadata:
name: liveness-exec-pod
namespace: dafault
spec:
containers:
- name: liveness-exec-container
image: busybox
imagePullPolicy: IfNotPresent
command: ['/bin/sh'.'-c'."touch /tmp/live; sleep 60; rm -rf /tmp/live; sleep 3600"]
livenessProbe:
exec:
command: ["test"."-c"."/tmp/live"]
initialDeyaySeconds: 1
periodSeconds: 3
Copy the code
livenessProbe-httpget
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget-pod
namespace: default
spec:
containers:
- name: liveness-httpget-container
image: myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
livenessProbe:
httpGet:
port: http
path: /index.html
initialDelaySeconds: 1
periodSenconds: 3
timeoutSeconds: 10
Copy the code
lienessProbe-tcp
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
spec:
containers:
- name: nginx
image: myapp:v1
livenessProbe:
initialDelaySeconds: 5
timeoutSeconds: 1
tcpSocket:
port: 8080
periodSeconds: 3
Copy the code
readinessProbe
Indicates whether the container is ready for a Service request. If the ready probe fails, the endpoint controller will remove the Pod’s IP address from the endpoints of all services matching the Pod. The ready state before the initial delay defaults to Failure, and if the container does not provide a ready probe, the default state is Success
Ready to detect
readinessProbe-httpget
apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget-pod
namespace: default
spec:
containers:
- name: readiness-httpget-container
image: myapp:v1
imagePullPolicy: IfNotPresent
readinessProbe:
httpGet:
port: http
path: /index1.html
initialDelaySeconds: 1
periodSeconds: 3
Copy the code
Pod life cycle start exit
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: myapp:v1
lifecycle:
postStart:
exec:
command: ["/bin/bash"."-c"."echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/usr/sbin/nginx"."-s"."quit"]
Copy the code
The Pod state for the Pod life cycle
- Pending: The Pod has been accepted by Kubernetes system, but one or more container images have not been created. The waiting time includes the time to schedule the Pod and the time to download the image over the network
- Runing: The Pod has been bound to a node, all containers in the Pod have been created, and at least one container is running or being started or restarted
- Successed: All containers in the Pod were successfully terminated and will not restart
- Failed: All containers in the Pod have been terminated, and at least one container has been terminated because of failure, that is, the container has exited non-zero or has been terminated by the system
- Unknown: The Pod status cannot be obtained for some reason, usually because communication with the Pod host fails