Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to configure Pod's liveness and readiness probes in Kubernetes". In daily operation, I believe many people have doubts about how to configure Pod's liveness and readiness probes in Kubernetes. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the questions of "how to configure Pod's liveness and readiness probes in Kubernetes". Next, please follow the editor to study!

When you use kuberentes, have you ever encountered a vicious cycle in which Pod dies soon after startup and then restarts? Have you ever wondered how kubernetes detects whether pod is still alive? Although the container has been started, how does kubernetes know if the process of the container is ready to provide services? Let's find out through this article on kuberentes's official website, Configure Liveness and Readiness Probes.

This article shows you how to configure the container's survival and readability probes.

Kubelet uses liveness probe (Survival probe) to determine when to restart the container. For example, when the application is running but cannot do anything further, the liveness probe will capture the deadlock and restart the container in that state so that the application can continue to run in the presence of bug (whose program does not have a few bug).

Kubelet uses the readiness probe (ready probe) to determine if the container is ready to accept traffic. It is only when all the containers in the Pod are ready that the kubelet determines that the Pod is ready. The function of this signal is to control which Pod should be used as the back end of the service. If the Pod is not ready, they will be removed from the load balancer of the service.

Define liveness commands

Many long-running applications eventually transition to the broken state and cannot be restored unless they are restarted. Kubernetes provides liveness probe to detect and remedy this situation.

In this lab, you will create a Pod that runs a container based on a gcr.io/google_containers/busybox image. The following is the configuration file exec-liveness.yaml for Pod:

ApiVersion: v1kind: Podmetadata: labels: test: liveness name: liveness-execspec: containers:-name: liveness args:-/ bin/sh-- c-touch / tmp/healthy; sleep 30; rm-rf / tmp/healthy; sleep 600 image: gcr.io/google_containers/busybox livenessProbe: exec: command:-cat-/ tmp/healthy initialDelaySeconds: 5 periodSeconds: 5

This configuration file configures a container for Pod. PeriodSeconds requires kubelet to execute liveness probe every 5 seconds. InitialDelaySeconds tells kubelet to wait five seconds before executing probe for the first time. The probe detection command executes the cat / tmp/healthy command in the container. If the command is executed successfully, it will return 0century Kubelet and will think that the container is alive and healthy. If a non-zero value is returned, kubelet kills the container and restarts it.

When the container starts, execute this command:

/ bin/sh-c "touch / tmp/healthy; sleep 30; rm-rf / tmp/healthy; sleep 600"

There is a / tmp/healthy file within the first 30 seconds of the container's life, during which time the cat / tmp/healthy command returns a successful return code. After 30 seconds, cat / tmp/healthy will return the failed return code.

Create a Pod:

Kubectl create-f https://k8s.io/docs/tasks/configure-pod-container/exec-liveness.yaml

Within 30 seconds, view the event of Pod:

Kubectl describe pod liveness-exec

The results show that there are no failed liveness probe:

FirstSeen LastSeen Count From SubobjectPath Type Reason Message--24s 24s 1 {default- Scheduler} Normal Scheduled Successfully assigned liveness-exec to worker023s 23s 1 {kubelet worker0} spec.containers {liveness} Normal Pulling pulling image "gcr.io/google_containers/busybox" 23s 23s 1 {kubelet worker0} spec.containers {liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/busybox" 23s 23s 1 {kubelet worker0} spec. Containers {liveness} Normal Created Created container with docker id 86849c15382e Security: [seccomp = unconfined] 23s 23s 1 {kubelet worker0} spec.containers {liveness} Normal Started Started container with docker id 86849c15382e

35 seconds after startup, check the event of pod again:

Kubectl describe pod liveness-exec

At the bottom there is a message that liveness probe failed and the container was deleted and recreated.

FirstSeen LastSeen Count From SubobjectPath Type Reason Message--37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker036s 36s 1 {kubelet worker0} spec.containers {liveness} Normal Pulling pulling image "gcr.io/google_containers/busybox" 36s 36s 1 {kubelet worker0} spec.containers {liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/busybox" 36s 36s 1 {kubelet worker0} spec.containers {liveness} Normal Created Created container with docker id 86849c15382e Security: [seccomp = unconfined] 36s 36s 1 {kubelet worker0} spec.containers {liveness} Normal Started Started container with docker id 86849c15382e2s 2s 1 {kubelet worker0} spec.containers {liveness} Warning Unhealthy Liveness probe failed: cat: can't open'/ tmp/healthy': No such file or directory

Wait another 30 seconds to confirm that the container has been restarted:

Kubectl get pod liveness-exec

The RESTARTS value is increased by 1 from the output.

NAME READY STATUS RESTARTS AGEliveness-exec 1 move 1 Running 1 1m defines an liveness HTTP request

We can also use HTTP GET requests as liveness probe. The following is an example of running a container's Pod based on a gcr.io/google_containers/liveness image: http-liveness.yaml:

ApiVersion: v1kind: Podmetadata: labels: test: liveness name: liveness-httpspec: containers:-name: liveness args:-/ server image: gcr.io/google_containers/liveness livenessProbe: httpGet: path: / healthz port: 8080 httpHeaders:-name: X-Custom-Header value: Awesome initialDelaySeconds: 3 periodSeconds: 3

The configuration file defines only one container, and livenessProbe specifies that kubelete needs to execute liveness probe every 3 seconds. InitialDelaySeconds specifies that kubelet needs to wait 3 seconds before performing the first probe. The probe will send a HTTP GET request to port 8080 of server in the container. If the handler of the / healthz path of server returns a successful return code, kubelet determines that the container is alive and healthy. If a failed return code is returned, kubelet will kill the container and restart it.

Any return code greater than 200 and less than 400 will be considered a successful return code. Other return codes are considered to be failed return codes.

Check the source code of the server: server.go.

The container is alive for the first 10 seconds, and / healthz handler returns a status code of 200. A return code of 500 will be returned after that.

Http.HandleFunc ("/ healthz", func (w http.ResponseWriter, r * http.Request) {duration: = time.Now (). Sub (started) if duration.Seconds () > 10 {w.WriteHeader (500) w.Write ([] byte (fmt.Sprintf ("error:% v", duration.Seconds ()} else {w.WriteHeader (200) w.Write ([] byte ("ok")}})

Three seconds after the container starts, kubelet begins to perform a health check. The first health monitoring will be successful, but after 10 seconds, the health check will fail and kubelet will kill and restart the container.

Create a Pod to test the HTTP liveness detection:

Kubectl create-f https://k8s.io/docs/tasks/configure-pod-container/http-liveness.yaml

After 10 seconds, view Pod events to verify that liveness probes have failed and the Container has been restarted:

10 seconds later, check the event of Pod, confirm that liveness probe failed and restart the container.

Kubectl describe pod liveness-http defines TCP liveness probe

The third liveness probe uses TCP Socket. With this configuration, kubelet will attempt to open the container's socket on the specified port. If a connection can be established, the container is considered healthy, and if not, it is considered a failure.

As you can see, the configuration of TCP inspection is very similar to that of HTTP inspection. This example uses both readiness and liveness probe. Five seconds after the container starts, kubelet sends the first readiness probe. This will attempt to connect to the goproxy container on port 8080. If the probe is successful, the pod will be marked as ready. Kubelet will perform this check every 10 seconds.

In addition to readiness probe, this configuration also includes liveness probe. Fifteen seconds after the container starts, kubelet will run the first liveness probe. Just like readiness probe, this will attempt to connect to port 8080 on the goproxy container. If the liveness probe fails, the container will restart.

Use named port

You can use a named ContainerPort as a HTTP or TCP liveness check:

Ports:- name: liveness-port containerPort: 8080 hostPort: 8080livenessProbe: httpGet: path: / healthz port: liveness-port defines readiness probe

Sometimes, the application is temporarily unable to serve external traffic. For example, an application may need to load a large amount of data or configuration files during startup. In this case, you don't want to kill the application, but you don't want to send the request either. Kubernetes provides readiness probe to detect and mitigate these conditions. Containers in Pod can report that they are not ready to handle traffic sent by Kubernetes services.

The configuration of Readiness probe is similar to that of liveness probe. The only difference is to use readinessProbe instead of livenessProbe.

ReadinessProbe: exec: command:-cat-/ tmp/healthy initialDelaySeconds: 5 periodSeconds: 5

Readiness probe's HTTP and TCP detectors are configured the same as liveness probe.

Readiness and livenss probe can be used in the same container in parallel. Using both ensures that traffic cannot reach the unprepared container and that the container restarts if it fails.

Configure Probe

There are many precise and detailed configurations in Probe, through which you can accurately control liveness and readiness checks:

InitialDelaySeconds: how many seconds does it take to perform the probe for the first time after the container is started.

PeriodSeconds: the frequency at which probes are performed. The default is 10 seconds, with a minimum of 1 second.

TimeoutSeconds: probe timeout. Default 1 second, minimum 1 second.

SuccessThreshold: after a probe fails, at least how many consecutive probes are successful before they are considered successful. The default is 1. Must be 1 for liveness. The minimum value is 1.

FailureThreshold: after a successful probe, at least how many consecutive probe failures can be considered as failures. The default is 3. The minimum value is 1.

Other configuration items can be set for httpGet in HTTP probe:

Host: the hostname of the connection, which is connected to the IP of pod by default. You may want to set "Host" in http header instead of using IP.

Scheme: the schema used for the connection. The default is HTTP.

Path: the path of the HTTP server visited.

HttpHeaders: header of the custom request. HTTP runs a duplicate header.

Port: the port name or port number of the container being accessed. The port number must be between 1 and 65525.

For the HTTP probe, the kubelet sends an HTTP request to the specified path and port to perform the check. Kubelet sends the probe to the IP address of the container unless the address is overridden by the optional host field in the httpGet. In most cases, you do not want to set the host field. There is a case where you can set it. Suppose the container is listening on 127.0.0.1 and the hostNetwork field of Pod is true. Then, the host under httpGet should be set to 127.0.0.1. If your pod depends on a virtual host, it may be more common that you should not use host, but instead set the Host header in httpHeaders.

At this point, the study on "how to configure Pod liveness and readiness probes in Kubernetes" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.