For most applications, we will add appropriate monitoring when deploying, especially for running carrier containers. kubernetes provides liveness probes to check our application. It is executed periodically by the kubelet on the node.
First of all, let's talk about the whole life stage of Pod:
- Pending: Indicates that the cluster system is creating a Pod, but all the containers in the Pod have not been created, which also includes the time when the cluster creates a network for the container or downloads an image;
- Running: Indicates that the pod has been running on a node for negotiation, and all containers have been created. But it does not mean that all containers are running, it only means that at least one container is running or the process is starting or restarting;
- Succeeded: All containers in the Pod have been terminated successfully, and there is no container that is restarting;
- Failed: All containers in the Pod have been terminated, but at least one container has not been terminated normally (the exit code at the time of termination is not 0)
There are also several fixed optional values for the results of liveness probes:
- Success: Indicates passing the test
- Failure: Indicates that the test did not pass
- Unknown: Indicates that the detection is not performed normally
Types of Liveness Probes:
- ExecAction: Execute the specified command in the container. When its execution succeeds, set its exit code to 0;
- TCPSocketAction: Performs a TCP check using the container's IP address and the specified port as the socket. If the port is open, it is considered to be successful;
HTTPGetAcction: Execute an HTTP default request using the container's IP address and the specified port and the requested path as the url, the user can set the requested address through the host parameter, and set the protocol type through the scheme parameter (HTTP , HTTPS) if its response code is between 200 and 400, set it as successful.
The current kubelet has two detectors, which correspond to different triggers (execute further actions according to the structure of the trigger):
- Liveness Probe: Indicates whether the container is in a live state. If LivenessProbe fails, LivenessProbe will notify the kubelet that the corresponding container is unhealthy. Then the kubelet will kill the container and perform further operations according to the RestarPolicy. By default, LivenessProbe is initialized as Success before the first detection. If the container does not provide LivenessProbe, it is also considered to be Success;
- ReadinessProbe: Indicates whether the container is in a state that can accept service requests. If the ReadinessProbe fails, the endpoints controller will remove the container's IP address from the list of endpoints matched by the service. Therefore, the core of the maintenance of the endpoint matched by the Service is ReadinessProbe. The default initial value of Readiness is Failure. If a container does not provide Readiness, it is considered to be Success.
The usage is the same for both LivenessProbe and ReadinessProbe, with the same parameters and the same monitoring methods.
- initialDelaySeconds: used to indicate the initialization delay time, that is, to tell how long the monitoring will start running, in seconds
- timeoutSeconds: used to indicate the monitoring timeout period, if it exceeds this period, the monitoring will be considered to have failed
Currently, a different restartpolicy can be set for each Container, and there are three values that can be set:
- Always: Restart whenever the container exits
- OnFailure: restarts when the container exits abnormally
- Never: never reboot
如果restartpolicy没有设置，那么默认值是Always。如果container需要重启，仅仅是通过kubelet在当前节点进行container级别的重启。
最后针对LivenessProbe如何使用，请看下面的几种方式，如果要使用ReadinessProbe只需要将livenessProbe修改为readinessProbe即可：
apiVersion: v1
kind: Pod
metadata:
name: probe-exec
namespace: coocla
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
exec:
command:
- cat
- /tmp/health
initialDelaySeconds: 5
timeoutSeconds: 1
---
apiVersion: v1
kind: Pod
metadata:
name: probe-http
namespace: coocla
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
httpGet:
path: /
port: 80
host: www.baidu.com
scheme: HTTPS
initialDelaySeconds: 5
timeoutSeconds: 1
---
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
namespace: coocla
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
initialDelaySeconds: 5
timeoutSeconds: 1
tcpSocket:
port: 80
我们使用上面的construct创建资源：
# kubectl create -f probe.yaml
# kubectl get event
通过event我们可以发现对应的container由于probe监测失败一直处于循环重启中，其事件原因：unhealthy
