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

This article mainly introduces the use of K8S to check Istio Service traffic health lecture, the content of the article is carefully selected and edited by the author, the use of K8S to check Istio Service traffic health lecture has a certain pertinence, for everyone's reference significance is still relatively great, the following with the author to understand the next topic content.

Istio uses the probe of K8s to check the traffic health of service. There are two kinds of probes to choose from, which are liveness and readiness:

The liveness probe is used to detect when the container needs to be restarted. For example, when the liveness probe captures a deadlock that occurs while the program is running, restarting the container can make the program easier to use.

The readiness probe is used to prepare the container to receive traffic. When all containers are ready, they are considered pod and ready at this time. For example, if you use this signal to control a backend service, when the pod is not in the ready state, the service will be removed from the load balancer.

Use the scene:

Liveness probes are used to remove abnormal pod, and liveness probes are often used in applications that cannot be recovered without restarting pod. For example, in the deadlock mentioned earlier, the process will always be active, and K8s will consider it normal and continue to send traffic. However, after using the liveness probe, you will find that the application no longer processes the request, and then restarts the exception pod.

The readiness probe is used to control traffic into the pod. For example, the application needs to load a large file or do some configuration after startup. However, by default, traffic will be sent as soon as the container process is started. Using the readiness probe, it waits until all loading or configuration is completed before allowing traffic to enter.

The configuration of the two probes is similar, except that the livenessProbe or readinessProbe fields are used.

Probe configuration parameters:

The probe has the following parameters:

InitialDelaySeconds: delay between container startup and startup probe

PeriodSeconds: the loop execution time of the probe. The minimum unit is 1 second.

TimeoutSeconds: probe timeout. Default is 1 second.

SuccessThreshold: success threshold, the minimum number of consecutive success signals after failure. Liveness must be 1.

FailureThreshold: the number of failure thresholds. When the probe fails, K8s attempts to re-execute the probe before abandoning. If the liveness probe abandons means restarting the container, the readiness probe means that pod is marked as unready. The default value is 3 times.

The HTTP probe has the following additional parameters:

Host: the hostname of the connection. The default value is pod IP.

Scheme: HTTP or HTTPS

Path: the path to access HTTP CVM

HttpHeaders: access the header of HTTP

Port: the port that accesses the container

The probe can perform three operations:

Command line: command the command line operation in the container, exit 0 is successful

HTTP request: sends a HTTP GET request to the container. If the returned value is between 200,400, the status is successful.

TCP request: sends a TCP request to the specified port. If the port is open for listening, it is successful.

Let's demonstrate the following health check operations:

Command line operation

First, prepare the busybox image and set the following yaml configuration file:

In the configuration file, we set a liveness probe to access / tmp/healthy this file every 5 seconds after the container starts. If the operation returns 0 successfully, the container is healthy. If the returned value is not 0, the container will be restarted.

When the container starts, it executes:

Touch / tmp/healthy; sleep 30; rm-rf / tmp/healthy; sleep 600

The / tmp/healthy file will be created in the first 30 seconds and deleted after 30 seconds. An error will be returned in this case.

Use kubectl create-f. / your-exec-liveness.yaml to establish pod

Check the pod status through kubectl describe pod liveness-exec within 30 seconds, which is healthy:

Check the status of pod after 30s and find that the file cannot be accessed and the result is unhealthy:

After checking the status of pod, the number of restarts of pod is 1. At this time, an unhealthy state has been detected by liveness probe and pod has been restarted.

If you use the readiness probe, you need to modify the red box field of the above your-exec-liveness.yaml:

Using the same method as above, check the status of pod before 30s, which is ready:

Check the pod status after 30 seconds. The readiness probe sets the application container to unready, and the ready container is istio-proxy:

You can see that the readiness probe does not restart the container.

HTTP request

Another way to use the liveness probe is the HTTP GET request, which can be used to monitor the running status of the web page. We use the google liveness image to demonstrate:

Here, we return the OK status of 200 in the first 10 seconds of the HTTP CVM / healthz path, and the status 500 after 10 seconds.

Set up the following configuration file:

The liveness probe sends a request for access / healthz to port 8080 of the container, every 3 seconds after the container starts. We set up the pod and view the running status of the pod kubectl describe pod liveness-http:

It will be found that 10 seconds later, the liveness probe detected a return value of 500 and the status was marked as unhealthy.

TCP request

The two probes can also be used together. Take the TCP request as an example. The TCP and HTTP connections are similar. Use the goproxy image of google, which opens the TCP socket connection on port 8080, using the following configuration file:

We use a probe to access port 8000 to check the pod status; in theory, it should not be possible to connect:

You can see that the readiness probe will monitor every 10 seconds. If it cannot be accessed, the pod will be placed in the unready state, and the liveness probe will be monitored for 20s. If it is not successful, restart the pod.

From the above demonstration, we learned how to configure two probes and perform three operations. Through reasonable probe configuration, the running status of each pod of Istio can be monitored in real time, and convenient application governance means can be provided.

After reading the above about using K8S to check Istio Service traffic health analysis, many readers must have some understanding, if you need to get more industry knowledge and information, you can continue to pay attention to our industry information column.

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.