k8s 探针

文章介绍了Kubernetes中的三种探针——存活探针、就绪探针和启动探针,它们分别用于检查容器运行、响应请求及应用程序启动情况。当探针检查失败时,系统会采取相应措施,如重启容器或停止流量调度。文章还通过示例yaml配置展示了如何设置这三种探针,并解释了其在实际操作中的影响。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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: nginx
  name: nginx
  namespace: default
spec:
  replicas: 5
  progressDeadlineSeconds: 600
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec: 
      containers:
      - name: nginx
        image: nginx:1.21
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        startupProbe:
          httpGet:
            path: /
            port: 81
            scheme: HTTP
          initialDelaySeconds: 20
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx
#  type: NodePort
  type: ClusterIP 
  clusterIP:
#  sessionAffinity: ClientIP
  ports:
    - port: 80
      targetPort: 80
#      nodePort: 30001
      protocol: 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: nginx
  name: nginx
  namespace: default
spec:
  replicas: 5
  progressDeadlineSeconds: 600
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec: 
      containers:
      - name: nginx
        image: nginx:1.21
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:   #配置探测的http信息
            path: /
            port: 81
            scheme: 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: nginx
  name: nginx
  namespace: default
spec:
  replicas: 5
  progressDeadlineSeconds: 600
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec: 
      containers:
      - name: nginx
        image: nginx:1.21
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 81
            scheme: HTTP
          initialDelaySeconds: 30  #首次发出探测请求的延迟时间,即多少秒后才开始探测,可以根据自己的项目适当调大存活探针的首次探测时间,以免服务需要启动得时间较长,导致服务还没启动就被判定检测失败
          periodSeconds: 3          #探测频率,默认为10秒
          successThreshold: 1    #处于失败状态时,需要探测成功多少次才算成功
          timeoutSeconds: 2        #探测超时时间,默认为1秒
          failureThreshold: 3    #处于成功状态时,需要探测失败多少次才算失败,默认为3
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx
#  type: NodePort
  type: ClusterIP 
  clusterIP:
#  sessionAffinity: ClientIP
  ports:
    - port: 80
      targetPort: 80
#      nodePort: 30001
      protocol: TCP

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

kubectl create -f deployment-nginx.yaml 

kubectl get pod

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

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

kubectl describe pod nginx-ffcf76b97-6xplz

 

### Kubernetes探针的使用方法 在 Kubernetesk8s)中,探针被用来监控容器的状态并决定如何响应异常情况。以下是关于存活探针(Liveness Probe)、就绪探针(Readiness Probe)以及启动探针(Startup Probe)的具体配置方式。 #### 存活探针(Liveness Probe) 存活探针用于检测容器是否处于正常运行状态。如果探测失败,Kubernetes 的 kubelet 会杀死该容器,并依据其重启策略重新创建它。如果没有定义存活探针,默认情况下 kubelet 认为容器始终存活[^4]。 下面是一个 YAML 文件中的 `livenessProbe` 配置示例: ```yaml apiVersion: v1 kind: Pod metadata: name: liveness-exec-probe spec: containers: - name: liveness image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep infinity livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5 ``` 此例子通过执行命令来验证文件 `/tmp/healthy` 是否存在以确认容器健康状况[^1]。 #### 就绪探针(Readiness Probe) 就绪探针的作用在于判断容器是否准备好接收流量。即使容器正在运行,但如果未通过就绪检查,则不会收到服务负载均衡器分发过来的数据包。这意味着可以控制何时让应用进入可用队列[^3]。 这里展示了一个基于 HTTP 请求实现的 `readinessProbe` 设置实例: ```yaml apiVersion: v1 kind: Pod metadata: name: readiness-http-get-pod spec: containers: - name: webserver image: nginx ports: - containerPort: 80 readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5 ``` 上述代码片段展示了如何利用 GET 方法访问根路径 (`/`) 来评估 Nginx 容器的服务能力[^2]。 #### 启动探针(Startup Probe) 自 Kubernetes 版本 1.16 起引入了启动探针功能,专门针对那些初始化时间较长的应用场景设计。只有当首次成功完成一次完整的生命周期循环之后才会激活常规的存活性与准备度测试流程;在此之前仅依赖于 startupProbe 结果作为唯一评判标准。 这是一个简单的 `startupProbe` 实现方案: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: startup-probe-example spec: replicas: 1 selector: matchLabels: app: example template: metadata: labels: app: example spec: containers: - name: slow-start-container image: my-slow-app-image startupProbe: tcpSocket: port: 9999 failureThreshold: 30 periodSeconds: 10 ``` 在这个部署对象里,我们指定了 TCP 握手端口为 9999 ,允许最多连续三次尝试失败才判定为不可用,并每隔十秒钟再次发起新一轮试探直至满足条件为止。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值