在相亲网站做红娘做网站 你的出路在哪里

deployment只保证pod的状态为running。如果pod状态是running，但是里面丢失了文件，导致用户不能访问数据，则deployment是不管用的，此时就需要probe来检测pod是否正常工作。
probe是定义在容器里的，可以理解为容器里加的一个装置，来探测容器是不是正常工作，分为liveness probe和readiness probe。

liveness probe

liveness探测到某个pod运行有问题的话，就会通过重启pod来解决问题，重启即为把旧的pod删除，然后创建出来一个新的同名的pod。

command探测方式

该方式就是，在容器内部执行一条命令，如果这个命令的返回值为0，即命令正确执行了，则认为容器是正常的，如果返回值非0，则认为容器出现了问题，然后通过重启来解决问题。

• 创建liveness1.yaml文件并修改，修改后内容如下

apiVersion: v1
kind: Pod
metadata:labels:run: liveness1name: liveness1
spec:terminationGracePeriodSeconds: 5containers:- image: busyboximagePullPolicy: IfNotPresentname: liveness1args:- /bin/sh- -c- touch /tmp/healthy;sleep 20;rm -rf /tmp/healthy;sleep 1000livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5successThreshold: 1failureThreshold: 3timeoutSeconds: 10

pod启动后，会创建/tmp/healthy，20秒后删除它，然后等待1000秒之后终止。
定义了livenessProbe，探测/tmp/healthy是否存在。如果该文件不存在，命令执行失败，返回值为零，则认为容器出问题了。

参数：
initialDelaySeconds：pod启动多少秒内不探测
periodSeconds：探测间隔时间
successThreshold：探测失败后，最少连续探测多少次才被认定成功
failureThreshold：探测失败后连续探测次数。
设置了terminationGracePeriodSeconds为5秒，默认30秒删除等待时间太长不利于观察。

• 创建pod并查看pod的运行情况

kubectl apply -f liveness1.yaml
kubectl get pod
kubectl exec liveness1 -- ls /tmp/

pod创建后，可以看到文件夹，20s后看不到文件夹，探测三次后，pod在40s后自动重启，以此类推。

httpGet探测方式

该方式指的是HTTP协议的数据包能否通过指定端口访问到指定文件，如果能访问到，则认为容器是正常的，如果访问不到，则认为pod是不正常的。

• 创建liveness2.yaml文件，内容如下

apiVersion: v1
kind: Pod
metadata:labels:run: liveness2name: liveness2
spec:terminationGracePeriodSeconds: 5containers:- image: nginximagePullPolicy: IfNotPresentname: liveness2livenessProbe:successThreshold: 1failureThreshold: 3initialDelaySeconds: 5periodSeconds: 5httpGet:path: /index.htmlport: 80scheme: HTTP

• 创建pod，并查看状态

kubectl apply -f liveness2.yaml
kubectl get pod
kubectl exec liveness2 -- ls /usr/share/nginx/html
# 删除文件进行测试
kubectl exec liveness2 -- rm /usr/share/nginx/html/index.html
kubectl get pod
kubectl exec liveness2 -- ls /usr/share/nginx/html

删除文件后，探测不到文件，pod重启，重启后，该文件存在。

tcpSocket探测方式

• 创建liveness3.yaml文件，内容如下

apiVersion: v1
kind: Pod
metadata:labels:run: liveness3name: liveness3
spec:terminationGracePeriodSeconds: 5containers:- image: nginximagePullPolicy: IfNotPresentname: liveness3livenessProbe:successThreshold: 1failureThreshold: 3initialDelaySeconds: 5periodSeconds: 5tcpSocket:port: 808

• 创建pod，并查看状态

kubectl apply -f liveness3.yaml
kubectl get pod

nginx默认使用的80端口，而我们探测是808，探测失败后，连续探测3次失败(15S)后重新启动pod，+5s删除时间，20秒后重启。

readiness probe

readiness探测和liveness探测类似，只是处理方式不一样。readiness探测到pod有问题之后并不会重启，只是service接收到请求后不再转发到此pod。

• 创建三个具有相同标签run=app的pod

apiVersion: v1
kind: Pod
metadata:labels:run: appname: pod1
spec:containers:- name: c1image: nginximagePullPolicy: IfNotPresentlifecycle:postStart:exec:command: ["/bin/bash","-c","touch /tmp/healthy"]readinessProbe:exec:command:- cat- /tmp/healthy

• 创建pod

kubectl apply -f readiness1.yaml
sed 's/pod1/pod2/' readiness1.yaml | kubectl apply -f -
sed 's/pod1/pod3/' readiness1.yaml | kubectl apply -f -
kubectl get pod --show-labels

• 修改每个pod默认页面

kubectl exec -ti pod1 -- bash
echo 111 > /usr/share/nginx/html/index.html
kubectl exec -ti pod2 -- bash
echo 222 > /usr/share/nginx/html/index.html
kubectl exec -ti pod3 -- bash
echo 333 > /usr/share/nginx/html/index.html

• 创建一个服务，并查看服务，过去IP

kubectl expose --name=readiness0 pod pod1 --port=80
kubectl get service

• 访问服务，由于三个pod标签相同，请求被负载均衡到三个pod。

curl 10.245.249.86

• 删除readiness3的测试文件，探测失败后pod3状态不再为ready

kubectl exec -it pod3 -- rm /tmp/healthy
kubectl exec -it pod3 -- ls /tmp
kubectl get pod
# 再次访问服务，已不再把请求转发给pod3了
curl 10.245.249.86

pod3状态是不健康的