今天继续给大家介绍Linux运维相关知识，本文主要内容是Pod就绪性探针实战。
一、Pod就绪性探针概述
再某些应用场景中，Pod对象在运行成功后，还需要进行一些初始化过程，执行一些指令，才能够正常提供服务。例如加载数据或配置，或者说程序的运行需要某些类的预热等等。但是，Kubernetes本身无法感知到Pod对象的初始化阶段，如果在这个节点Kubernetes集群给该Pod对象引入了服务请求，那么该Pod对象就无法正常提供服务。
为了解决这个问题，Kubernetes集群引入了就绪性探针的配置。与存活性探针类似，就绪性探针也会对Pod容器中的指定内容进行周期性探测，当探测成功时，就表示容器已经就绪。但是与存活性探针不同的是，就绪性探针当探测到失败后，不会杀死或重启容器，而是使得该容器处于“不可用”状态，并触发依赖于其就绪状态的操作，以确保不会有请求接入该Pod。
二、Pod就绪性探针HTTP实战
Pod的就绪性探针也有Exec、HTTP和TCP三种类型，下面，我们就来进行Pod就绪性探针的实战，在本实战中，我们使用的是HTTP类型的探针，其他类型的探针与之类似，因此在这里就不过多赘述了。
我们创建一个Pod的资源配置清单ready-probe.yaml，并向其中写入如下内容：
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
- name: http
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
在该配置文件中，我们引入了HTTP类型的就绪性探针，该探针会探测web服务器下index.html文件的存在性，如果该文件不存在，就说明该容器存在异常。
完成上述配置后，我们运行该清单，创建Pod，执行结果如下：
可以看到，我们的Pod运行正常。接下来，我们来检验就绪性探针的效果。进入该Pod容器，删除我们web服务根目录下的index.html文件，然后观察Pod容器的状态，结果如下所示：
从上图中可以看出，当我们删除该文件后，探针会探测到异常，该容器仍然处于运行状态，但是已经设置为不可用。我们的Pod就绪性探针配置成功！
原创不易，转载请说明出处：https://blog.csdn.net/weixin_40228200
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/weixin_40228200/article/details/124286758
