Today, I will continue to introduce the relevant knowledge of Linux operation and maintenance. The main content of this article is the actual combat of Pod readiness probe.
1. Overview of Pod Readiness Probes
In some application scenarios, after the Pod object runs successfully, it needs to perform some initialization processes and execute some instructions before it can provide services normally. For example, loading data or configuration, or the operation of the program requires the warm-up of certain classes, etc. However, Kubernetes itself cannot perceive the initialization phase of the Pod object. If the Kubernetes cluster on this node introduces a service request to the Pod object, the Pod object cannot provide services normally.
To solve this problem, Kubernetes clusters introduce the configuration of readiness probes. Similar to the liveness probe, the readiness probe also periodically probes the specified content in the Pod container. When the probe is successful, it means that the container is ready. But unlike the liveness probe, the readiness probe does not kill or restart the container when it detects a failure, but makes the container in an "unavailable" state and triggers operations that depend on its ready state. to ensure that no requests are made to the Pod.
2. Pod readiness probe HTTP combat
There are also three types of Pod readiness probes: Exec, HTTP and TCP. Next, we will conduct the actual combat of Pod readiness probes. In this actual combat, we use HTTP type probes and other types of probes. It is similar, so I won't go into details here.
We create a Pod's resource configuration manifest, ready-probe.yaml, and write the following to it:
apiVersion: v1
kind: Pod
metadata:
name: ready-pod
namespace: default
labels:
probe: ready
spec:
containers:
- name: ready-probe
image: nginx:1.14
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
path: /index.html
port: http
scheme: HTTP
In this configuration file, we introduce an HTTP-type readiness probe, which detects the existence of the index.html file under the web server. If the file does not exist, it means that the container is abnormal.
After completing the above configuration, we run the manifest to create a Pod, and the execution result is as follows: As
you can see, our Pod is running normally. Next, let's examine the effect of the readiness probe. Enter the Pod container, delete the index.html file in the root directory of our web service, and then observe the status of the Pod container. The results are as follows:
As can be seen from the above figure, when we delete the file, the probe will detect Exception, the container is still running, but has been set to unavailable. Our Pod Readiness Probe was configured successfully!
Originality is not easy, please indicate the source for reprinting: https://blog.csdn.net/weixin_40228200