当前位置: 首页 > news >正文

k8s 探针

1.前言

Kubernetes探针(Probe)是用于检查容器运行状况的一种机制。探针可以检查容器是否正在运行,容器是否能够正常响应请求,以及容器内部的应用程序是否正常运行等。在Kubernetes中,探针可以用于确定容器的健康状态,如果容器的健康状态异常,Kubernetes将会采取相应的措施,例如重启容器或将其从服务中删除

2.探针类型

k8s有三种类型的探针分别是Liveness Probe(存活探针)、Readiness Probe(就绪探针)、Startup Probe(启动探针)

Liveness Probe:用于检查容器是否正在运行,如果Liveness Probe检查失败,则Kubernetes将重启容器

Readiness Probe:用于检查容器是否能够正常响应请求,如果Readiness Probe检查失败,则Kubernetes将停止将流量发送到该容器

Startup Probe:用于检查容器内部的应用程序是否已经启动并且已经准备好接受流量,如果Startup Probe检查失败,则Kubernetes将重启容器

总的来说存活探针、启动探针在检测容器的探针失败时重启容器,就绪探针在检测容器的探针失败时禁止将流量调度到该容器,一般都是将就绪探针和存活探针一起使用,启动探针只在启动较慢的容器中结合使用,避免因为容器启动时间较长导致存活探针检测容器以为是不存活而一直重启容器,但是也可以将存活探针的检测时间设置长一点来解决此问题

3.探针的检测流程

同时使用三种探针的情况下

启动探针检测:在容器启动时,Kubernetes 将首先执行启动探针。如果启动探针失败,则 Kubernetes 将重启容器。启动探针只会在容器启动时执行一次

定期检测存活探针:存活探针用于检测容器是否处于运行状态。Kubernetes 将定期执行存活探针来确保容器仍然处于运行状态。如果探针失败,则 Kubernetes 将重启容器

定期检测就绪探针:就绪探针用于检测容器是否已准备好接收流量。Kubernetes 将定期执行就绪探针来确保容器已准备好接收流量。如果探针失败,则 Kubernetes 将从服务的端点中删除该容器,直到探针再次成功

4.探针的使用

 4.1启动探针

编辑yaml文件

vi deployment-nginx.yaml 

apiVersion: apps/v1
kind: Deployment
metadata: labels:app: nginxname: nginxnamespace: default
spec:replicas: 5progressDeadlineSeconds: 600minReadySeconds: 10strategy:rollingUpdate:maxSurge: 1maxUnavailable: 0type: RollingUpdateselector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec: containers:- name: nginximage: nginx:1.21imagePullPolicy: IfNotPresentports:- containerPort: 80startupProbe:httpGet:path: /port: 81scheme: HTTPinitialDelaySeconds: 20timeoutSeconds: 5successThreshold: 1failureThreshold: 3periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:name: nginxnamespace: default
spec:selector:app: nginx
#  type: NodePorttype: ClusterIP clusterIP:
#  sessionAffinity: ClientIPports:- port: 80targetPort: 80
#      nodePort: 30001protocol: TCP

该yaml的启动探针配置检测一个不存在服务的端口来检测启动探针的效果,执行yaml看看效果

kubectl create -f deployment-nginx.yaml 

kubectl get pod

可以看到因为配置的启动探针探测失败的原因pod一直处于重启的状态,而且也是未准备的状态,未准备的状态,集群是不会调度流量到这些pod上面的

kubectl get svc

curl 10.98.231.214

也可以通过查看pod的详细信息查看状态

 

 4.2就绪探针

编辑yaml文件

vi deployment-nginx.yaml 

apiVersion: apps/v1
kind: Deployment
metadata: labels:app: nginxname: nginxnamespace: default
spec:replicas: 5progressDeadlineSeconds: 600minReadySeconds: 10strategy:rollingUpdate:maxSurge: 1maxUnavailable: 0type: RollingUpdateselector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec: containers:- name: nginximage: nginx:1.21imagePullPolicy: IfNotPresentports:- containerPort: 80readinessProbe:httpGet:   #配置探测的http信息path: /port: 81scheme: HTTP     initialDelaySeconds: 2  #首次发出探测请求的延迟时间,即多少秒后才开始探测periodSeconds: 5    #探测频率,默认为10秒timeoutSeconds: 5   #探测超时时间,默认为1秒successThreshold: 1  #处于失败状态时,需要探测成功多少次才算成功failureThreshold: 5   #处于成功状态时,需要探测失败多少次才算失败,默认为3

该yaml的就绪探针配置检测一个不存在服务的端口来检测就绪探针的效果,执行yaml看看效果

 kubectl get pod

 可以看到因为配置的就绪探针探测失败的原因,虽然pod状态是running,但是pod都是未准备的,接下来访问一下pod服务看看

kubectl get svc

curl 10.100.21.201

可以看到是拒绝连接的,所以因为就绪探针的原因,是没有流量调度 到这些pod上的 

也可以通过describe命令去查看pod的详细信息

 4.3存活探针

编辑yaml文件

vi deployment-nginx.yaml 

apiVersion: apps/v1
kind: Deployment
metadata: labels:app: nginxname: nginxnamespace: default
spec:replicas: 5progressDeadlineSeconds: 600minReadySeconds: 10strategy:rollingUpdate:maxSurge: 1maxUnavailable: 0type: RollingUpdateselector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec: containers:- name: nginximage: nginx:1.21imagePullPolicy: IfNotPresentports:- containerPort: 80livenessProbe:httpGet:path: /port: 81scheme: HTTPinitialDelaySeconds: 30  #首次发出探测请求的延迟时间,即多少秒后才开始探测,可以根据自己的项目适当调大存活探针的首次探测时间,以免服务需要启动得时间较长,导致服务还没启动就被判定检测失败periodSeconds: 3          #探测频率,默认为10秒successThreshold: 1    #处于失败状态时,需要探测成功多少次才算成功timeoutSeconds: 2        #探测超时时间,默认为1秒failureThreshold: 3    #处于成功状态时,需要探测失败多少次才算失败,默认为3
---
apiVersion: v1
kind: Service
metadata:name: nginxnamespace: default
spec:selector:app: nginx
#  type: NodePorttype: ClusterIP clusterIP:
#  sessionAffinity: ClientIPports:- port: 80targetPort: 80
#      nodePort: 30001protocol: TCP

该yaml的存活探针配置检测一个不存在服务的端口来检测存活探针的效果,执行yaml看看效果

kubectl create -f deployment-nginx.yaml 

kubectl get pod

可以看到因为存活探针检测失败得问题pod一直在重启

 也可以通过查看pod得详细信息来看到

kubectl describe pod nginx-ffcf76b97-6xplz

 

http://www.lryc.cn/news/93263.html

相关文章:

  • 【爬虫】4.4 Scrapy 爬取网站数据
  • PureComponent和Component的区别和底层处理机制
  • python3 爬虫相关学习9:BeautifulSoup 官方文档学习
  • 物联网Lora模块从入门到精通(九)Flash的读取与存储--结题
  • STM32MP157_PRO开发板的第一个驱动程序
  • 你“被”全链路了么?全链路压测实践之理论
  • 基于Tensorflow+SDD+Python人脸口罩识别系统(深度学习)含全部工程源码及模型+视频演示+图片数据集
  • abc200 D 鸽巢原理
  • QT day1 (图形界面设计)
  • JS逆向系列之猿人学爬虫第9题-动态cookie2
  • Java ~ Reference ~ FinalizerHistogram【总结】
  • 【MySQL】一文带你了解SQL
  • python基础学习3【NumPy矩阵与通用函数【矩阵相乘+平方+广播机制+转置】+ save、load、sort、repeat、unique、鸢尾花1】
  • 【Spring学习之更简单的读取和存储Bean对象】教会你使用五大类注解和方法注解去存储 Bean 对象
  • 微客云原生淘宝客APP小程序系统如何定制
  • QT CTK插件开发(六) 多对一插件
  • 【Spring Boot整合MyBatis教程】
  • ThinkPHP3.2.3通过局域网手机访问项目
  • 2306C++虚继承
  • 使用oracle遇到问题笔记
  • 我和老刘又被搞惨了
  • DDD--基本概念
  • chatgpt赋能python:Python多行注释
  • JSP详细基础教学
  • mysql修改登录用户的密码
  • SNAT和DNAT
  • 好程序员:月薪2万程序员的简历,原来长这个样子!
  • STM32之FreeRTOS
  • 有趣的图(二)(56)
  • Linux之环境变量