首页 > 其他分享 >就绪探针(Readiness Probe)

就绪探针(Readiness Probe)

时间:2022-08-28 10:45:11浏览次数:85  
标签:Readiness name Probe 探针 nginx ready Pod

一个新Pod创建后,Service就能立即选择到它,并会把请求转发给Pod,那问题就来了,通常一个Pod启动是需要时间的,如果Pod还没准备好(可能需要时间来加载配置或数据,或者可能需要执行一个预热程序之类),这时把请求转给Pod的话,Pod也无法处理,造成请求失败。

Kubernetes解决这个问题的方法就是给Pod加一个业务就绪探针Readiness Probe,当检测到Pod就绪后才允许Service将请求转给Pod。

Readiness Probe同样是周期性的检测Pod,然后根据响应来判断Pod是否就绪,与存活探针(Liveness Probe)相同,就绪探针也支持如下三种类型。

  • Exec:Probe执行容器中的命令并检查命令退出的状态码,如果状态码为0则说明已经就绪。
  • HTTP GET:往容器的IP:Port发送HTTP GET请求,如果Probe收到2xx或3xx,说明已经就绪。
  • TCP Socket:尝试与容器建立TCP连接,如果能建立连接说明已经就绪。

Readiness Probe的工作原理

通过Endpoints就可以实现Readiness Probe的效果,当Pod还未就绪时,将Pod的IP:Port从Endpoints中删除,Pod就绪后再加入到Endpoints中,如下图所示。

图1 Readiness Probe的实现原理

Exec

Exec方式与HTTP GET方式一致,如下所示,这个探针执行ls /ready命令,如果这个文件存在,则返回0,说明Pod就绪了,否则返回其他状态码。

 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:alpine
        name: container-0
        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        readinessProbe:      # Readiness Probe
          exec:              # 定义 ls /ready 命令
            command:
            - ls
            - /ready
      imagePullSecrets:
      - name: default-secret

 将上面Deployment的定义保存到deploy-read.yaml文件中,删除之前创建的Deployment,用deploy-read.yaml创建这个Deployment。

# kubectl delete deploy nginx
deployment.apps "nginx" deleted

# kubectl create -f deploy-read.yaml
deployment.apps/nginx created

这里由于nginx镜像不包含/ready这个文件,所以在创建完成后容器不在Ready状态,如下所示,注意READY这一列的值为0/1,表示容器没有Ready。

# kubectl get po
NAME                     READY     STATUS    RESTARTS   AGE
nginx-7955fd7786-686hp   0/1       Running   0          7s
nginx-7955fd7786-9tgwq   0/1       Running   0          7s
nginx-7955fd7786-bqsbj   0/1       Running   0          7s

创建Service。

apiVersion: v1
kind: Service
metadata:
  name: nginx        
spec:
  selector:          
    app: nginx
  ports:
  - name: service0
    targetPort: 80   
    port: 8080       
    protocol: TCP    
  type: ClusterIP

查看Service,发现Endpoints一行的值为空,表示没有Endpoints。

$ kubectl describe svc nginx
Name:              nginx
......
Endpoints:         
......

如果此时给容器中创建一个/ready的文件,让Readiness Probe成功,则容器会处于Ready状态。再查看Pod和Endpoints,发现创建了/ready文件的容器已经Ready,Endpoints也已经添加。

# kubectl exec nginx-7955fd7786-686hp -- touch /ready

# kubectl get po -o wide
NAME                     READY     STATUS    RESTARTS   AGE       IP
nginx-7955fd7786-686hp   1/1       Running   0          10m       192.168.93.169 
nginx-7955fd7786-9tgwq   0/1       Running   0          10m       192.168.166.130
nginx-7955fd7786-bqsbj   0/1       Running   0          10m       192.168.252.160

# kubectl get endpoints
NAME       ENDPOINTS           AGE
nginx      192.168.93.169:80   14d

HTTP GET

Readiness Probe的配置与存活探针(livness probe)一样,都是在Pod Template的containers里面,如下所示,这个Readiness Probe向Pod发送HTTP请求,当Probe收到2xx或3xx返回时,说明Pod已经就绪。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:alpine
        name: container-0
        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        readinessProbe:           # readinessProbe
          httpGet:                # HTTP GET定义
            path: /read
            port: 80
      imagePullSecrets:
      - name: default-secret

TCP Socket

同样,TCP Socket类型的探针如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:alpine
        name: container-0
        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        readinessProbe:             # readinessProbe
          tcpSocket:                # TCP Socket定义
            port: 80
      imagePullSecrets:
      - name: default-secret

Readiness Probe高级配置

与Liveness Probe相同,Readiness Probe也有同样的高级配置选项,上面nginx Pod的describe命令回显有中有如下行。

Readiness: exec [ls /var/ready] delay=0s timeout=1s period=10s #success=1 #failure=3

这一行表示Readiness Probe的具体参数配置,其含义如下:

  • delay=0s 表示容器启动后立即开始探测,没有延迟时间
  • timeout=1s 表示容器必须在1s内做出相应反馈给probe,否则视为探测失败
  • period=10s 表示每10s探测一次
  • #success=1 探测连续1次成功表示成功
  • #failure=3 探测连续3次失败表示失败

这些是创建时默认设置的,您也可以手动配置,如下所示。

        readinessProbe:      # Readiness Probe
          exec:              # 定义 ls /readiness/ready 命令
            command:
            - ls
            - /readiness/ready
          initialDelaySeconds: 10    # 容器启动后多久开始探测
          timeoutSeconds: 2          # 表示容器必须在2s内做出相应反馈给probe,否则视为探测失败
          periodSeconds: 30          # 探测周期,每30s探测一次
          successThreshold: 1        # 连续探测1次成功表示成功
          failureThreshold: 3        # 连续探测3次失败表示失败

标签:Readiness,name,Probe,探针,nginx,ready,Pod
From: https://www.cnblogs.com/liyangspace/p/16632343.html

相关文章

  • 存活探针(Liveness Probe)
    存活探针Kubernetes提供了自愈的能力,具体就是能感知到容器崩溃,然后能够重启这个容器。但是有时候例如Java程序内存泄漏了,程序无法正常工作,但是JVM进程却是一直运行的,对于......
  • pod资源的健康检查-readiness探针的httpGet使用
    livenessProbe:健康状态检查,周期性检查服务是否存活,检查结果失败,将重启容器readinessProbe:可用性检查,周期性检查服务是否可用,不可用将从service的endpoints中移除同一个容......
  • h3c s6800交换机probe命令
    <H3C>sysSystemView:returntoUserViewwithCtrl+Z.[H3C]probe[H3C-probe]?Probeviewcommands:INTEGER<0-1>SwitchNObcmBCM[H3C-p......
  • k8s控制器探针
    HealthCheck:由发起者对容器进行周期性检测 dockershealthcheck实现方式:#第一种方式:docker-composecat<<EOF>docker-compose.yamlversion:'3.6'service: ......