K8s-存活探针-就绪探针

K8s-存活探针-就绪探针_第1张图片

  • readiness probe(就绪探针)
  • 用于判断容器是否启动完成,即容器的Ready是否为True,可以接收请求,如果ReadinessProbe探测失败,则容器的Ready将为False,控制器将此Pod的Endpoint从对应的service的Endpoint列表中移除,从此不再将任何请求调度此Pod上,直到下次探测成功。通过使用Readiness探针,Kubernetes能够等待应用程序完全启动,然后才允许服务将流量发送到新副本。

  • 比如使用tomcat的应用程序来说,并不是简单地说tomcat启动成功就可以对外提供服务的,还需要等待spring容器初始化,数据库连接没连上等等。对于spring boot应用,默认的actuator带有/health接口,可以用来进行启动成功的判断。

K8s-存活探针-就绪探针_第2张图片

  • liveness probe(存活探针)
  • 用于判断容器是否存活,即Pod是否为running状态,如果LivenessProbe探针探测到容器不健康,则kubelet将kill掉容器,并根据容器的重启策略是否重启。如果一个容器不包含LivenessProbe探针,则Kubelet认为容器的LivenessProbe探针的返回值永远成功。

  • 有时应用程序可能因为某些原因(后端服务故障等)导致暂时无法对外提供服务,但应用软件没有终止,导致K8S无法隔离有故障的pod,调用者可能会访问到有故障的pod,导致业务不稳定。K8S提供livenessProbe来检测应用程序是否正常运行,并且对相应状况进行相应的补救措施。
    K8s-存活探针-就绪探针_第3张图片

  • 例1. 基于TCP的存活性探测(TCPSocketAction)用于向容器的特定端口发起TCP请求并尝试建立连接,连接成功即为通过检测。
cat <nginx.yaml
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
          - containerPort: 80
        livenessProbe:
          initialDelaySeconds: 15
          tcpSocket:
            port: 80
          periodSeconds: 300
          timeoutSeconds: 10
          failureThreshold:  2
---
apiVersion: v1
kind: Service
metadata:
  name: nacos-hs
spec:
  clusterIP: None
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  type: ClusterIP
  selector:
    app: nginx
END
  • 检测80是否存在
livenessProbe: 
  initialDelaySeconds: 15 #pod启动10秒执行第一次检查
  tcpSocket:  #检测80是否存在
    port: 80
  periodSeconds: 300  #第一次检查后每隔300秒检查一次
  timeoutSeconds: 3  # 检查超时的时间,默认为1秒,最小为1秒
  failureThreshold: 3        #最少连续探测失败多少次才被认定为失败
  • 两个同时使用,Kubelet将尝试在指定的端口上打开容器上的套接字,如果能建立连接,则表明容器健康
      - name: nginxhttps
        image: ymqytw/nginxhttps:1.5
        command: ["/home/auto-reload-nginx.sh"]
        ports:
          - containerPort: 80
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 15
          successThreshold: 1
          failureThreshold: 3
          timeoutSeconds: 1
		  
        readinessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 3
          timeoutSeconds: 1
  • TCP检查方式和HTTP检查方式非常相似,示例中两种探针都使用了,在容器启动5秒后,kubelet将发送第一个readinessProbe探针,这将连接到容器的80端口,如果探测成功,则该Pod将被标识为ready,10秒后,kubelet将进行第二次连接.除此之后,此配置还包含了livenessProbe探针,在容器启动15秒后,kubelet将发送第一个livenessProbe探针,仍然尝试连接容器的80端口,如果连接失败则重启容器。
  • ReadinessProbe探针配置

  • 1 ReadinessProbe探针的使用场景livenessProbe稍有不同,有的时候应用程序可能暂时无法接受请求,比如Pod已经Running了,但是容器内应用程序尚未启动成功,在这种情况下,如果没有ReadinessProbe,则Kubernetes认为它可以处理请求了,然而此时,我们知道程序还没启动成功是不能接收用户请求的,所以不希望kubernetes把请求调度给它,则使用ReadinessProbe探针。
  • 2 ReadinessProbe和livenessProbe可以使用相同探测方式,只是对Pod的处置方式不同,ReadinessProbe是将Pod IP:Port从对应的EndPoint列表中删除,而livenessProbe则Kill容器并根据Pod的重启策略来决定作出对应的措施。
  • 3 ReadinessProbe探针探测容器是否已准备就绪,如果未准备就绪则kubernetes不会将流量转发给此Pod
  • 5 ReadinessProbe探针与livenessProbe一样也支持exec、httpGet、TCP的探测方式,配置方式相同,只不过是将livenessProbe字段修改为ReadinessProbe。
readinessProbe:
 exec:
   command:
   - cat
   - /tmp/healthy
 initialDelaySeconds: 5
 periodSeconds: 5
  • pods没有健康检测的情况下,默认是监听主进程,如果主进程不再了,pods就会重启重新初始化

你可能感兴趣的:(Kubernetes,k8s)