探针介绍及应用

大洋百度

已于 2023-02-09 10:57:14 修改

阅读量2.4k

点赞数

文章标签： kubernetes 运维 docker

于 2022-12-03 17:55:03 首次发布

本文链接：https://blog.csdn.net/weixin_46476452/article/details/128116163

版权

简介：

一、存活探针功能演示

二、就绪探针功能演示

1、基于上面的yaml文件，把存活探针改成就绪探针，其余内容均不变

2、就绪探针探测失败演示：

3、TCP监测

三、3个探针综合使用

简介：

探针的作用：探针是由 kubelet 对容器执行的定期检测，检测的结果将决定kubelte对容器生命周期的干预
ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
每次探测都将获得以下三种结果之一：
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。
探针类型：
   startupProbe ：启动探针
      判断容器内的应用程序是否已启动完成，如果配置了启动探测，则会先禁用所有其它的探测，直到startupProbe检测成功为止，如果startupProbe探测失败，则kubectl将杀死容器，容器将按照重启策略进行下一步操作，如果容器没有提供启动探测，则默认状态为成功

   livenessProbe：存活探针
     检测容器是否正在运行，如果存活探测失败，则kubectl会杀死容器，并且容器将受到其重启策略的影响，如果容器不提供存活探针，则默认状态为success, livenessProbe用于控制是否重启POD

   readinessProbe：就绪探针
      如果就绪探测失败，端点控制器将从与Pod匹配的所有Service的端点中删除该POD的IP地址，储是延迟之前的就绪状态默认为Failure(失败)，如果
容器不提供就绪探针，则默认状态为Success, readinessProbe用于控制POD是否添加至service

总结：以上三个探针检查失败都会杀死容器，前两个探针同时会重启容器，而就绪探针会把service中把该pod的IP删掉，用户请求就不会转到该POD了

一、存活探针功能演示

1、编写带有存活探针功能的yaml文件

root@k8s-deploy:~/yaml/yl# vim livenessprobe.yaml
kind: Deployment
apiVersion: apps/v1
metadata:
  name: myserver-deployment
  namespace: myserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myserver-myapp-label
  template:
    metadata:
      labels:
        app: myserver-myapp-label
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.20
        ports:
        - containerPort: 80
        livenessProbe:      # 存活探针,用于检测容器是否正在运行，会控制pod是否重启
          httpGet:              #通过存活探针检测这个容器80端口的URL是/index.html
            path: /index.html   #nignx官方镜像的默认网页首页
            port: 80
          initialDelaySeconds: 5  #初始化延迟时间，kubelet在执行第一次探测前应该等待多少秒,这个是官网镜像比较精简因此容器启动会很快5秒够了，如果是生产环境可能需要一两分钟
          periodSeconds: 3      #探测周期间隔时间，指定kubelet每隔3秒执行一次存活探针，默认10S
          timeoutSeconds: 5     #单次探测超时时间，探测超时时间是5秒，默认1S
          successThreshold: 1   # 从失败转为成的重试次数，探测器失败后，被视为成功的最小连接成功数，必须是1
          failureThreshold: 3   #探测失败超过3次后就重启容器；存活探测是重启容器，就绪探测是把pod打上未就绪标签

---
apiVersion: v1
kind: Service
metadata:
  name: myserver-myapp-frontend-service
  namespace: myserver
spec:
  ports:
  - name: http
    port: 81
    targetPort: 80
    nodePort: 40012
    protocol: TCP
  type: NodePort
  selector:
    app: myserver-myapp-label


创建资源
root@k8s-deploy:~/yaml/yl# kubectl apply -f livenessprobe.yaml

查看资源
root@k8s-deploy:~/yaml/yl# kubectl get pod -n myserver
NAME                                   READY   STATUS    RESTARTS   AGE
myserver-deployment-699b54f5cb-499gc   1/1     Running   0          13s

2、修改yaml文件，展示存活探针失败后的状态

删除资源
root@k8s-deploy:~/yaml/yl# kubectl delete -f livenessprobe.yaml

修改上面的yaml文件，把探测的url路径改为错误的，再进行探测

创建资源

root@k8s-deploy:~/yaml/yl# kubectl apply -f livenessprobe.yaml

查看资源

# kubectl describe pod myserver-deployment-7749847cf-lghrx -n myserver可以看见报错

总结：存活探针失败后会把pod直接重启，重启超过设置的阈值后就会回退

二、就绪探针功能演示

1、基于上面的yaml文件，把存活探针改成就绪探针，其余内容均不变

查看pod启动了，service也启动了，endpoint也有了pod地址；只有就绪探针检测通过之后才会把pod地址挂到service上（endpoint是记录service对应所有pod的访问地址的资源对象）

此时访问node节点的40012就可以访问到nginx pod首页面

2、就绪探针探测失败演示：

进入容器，把index.html文件移走，这样就绪探针就会探测不到这个url路径，就会探测失败
root@k8s-deploy:~/yaml/yl# kubectl exec -it myserver-deployment-97c9bf8d8-5d78v bash -n myserver
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
root@myserver-deployment-97c9bf8d8-5d78v:/# cd /usr/share/nginx/html/
root@myserver-deployment-97c9bf8d8-5d78v:/usr/share/nginx/html# ls
50x.html  index.html
root@myserver-deployment-97c9bf8d8-5d78v:/usr/share/nginx/html# mv index.html  /tmp/
root@myserver-deployment-97c9bf8d8-5d78v:/usr/share/nginx/html# ls
50x.html

再查看下资源对象，显示有1个pod，0个pod是正常的，说明这个pod已经异常了

可以看见pod并没有重启，因为就绪探针失败不会重启pod，kubectl get ep 看见service后面没有pod_ip了，因为就绪探针只会把pod从service上拿掉

查看pod信息可以看见就绪探针检测失败告警

进入容器重新创建一个index.html文件，这样就绪探针每隔3S检测一次就可以重新探测成功了，然后pod_ip又重新被加载到service上了，查看pod也恢复正常了

重新访问node节点的40012端口就可以看见我们自己创建nignx的index.html首页文件

总结：就绪探针失败后不会重启容器，会把pod从service上拿掉

3、TCP监测

使用探针检测基于TCP检测容器端口是否正常

前面的yaml文件其它内容不变，把httpGet修改成tcpSocket，把监听的项目改成端口80即可

进入容器把nginx监听的80端口改成别的8080，再把nginx -s reload一下

可以看下pod重置过了一次，当探测不通过会基于容器的镜像把容器重置

可以进入重置后的容器看下，之前修改的监听端口全部重置回原始状态了，而后探测又可以通过了

三、3个探针综合使用

root@k8s-deploy:~/yaml/yl# vim probe.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myserver-myapp-deployment
  namespace: myserver
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: myapp-label
  template:
    metadata:
      labels:
        app: myapp-label
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: nginx-container
        image: nginx:1.20
        ports:
        - containerPort: 80
        startupProbe:          #启动探针,检测通过后才会继续进行下面的探针检测
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5 #首次检测延迟5s
          failureThreshold: 3  #从成功转为失败的次数
          periodSeconds: 3 #探测间隔周期
        readinessProbe:        #就绪探针，每隔3s检测下url路径能否访问，如果不能访问，存活探针把pod重启，然后就绪探针把pod从service拿掉
          httpGet:
            #path: /monitor/monitor.html
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
        livenessProbe:        #存活探针，每隔3s检测下url路径能否访问，如果不能访问，将pod重启，如果恢复正常，就绪探针再把pod挂到service
          httpGet:
            #path: /monitor/monitor.html
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3


---
apiVersion: v1
kind: Service
metadata:
  name: myserver-myapp-service
  namespace: myserver
spec:
  ports:
  - name: http
    port: 81
    targetPort: 80
    nodePort: 40012
    protocol: TCP
  type: NodePort
  selector:
    app: myapp-label

查看pod资源