首页 > 其他分享> > Kubernetes-探针readinessProbe、livenessProbe和startupProbe

Kubernetes-探针readinessProbe、livenessProbe和startupProbe

2021-07-10 01:31:06 作者：互联网

更多相关资料见 : K8S Basic-Pod资源管理进阶（Pod声明周期、相位、资源限制）

一、Pod三种探针方式

一、Pod三种探针方式

readinessProbe
livenessProbe
startupProbe（v1.16版本增加）

livenessProbe和readnessProbe、startupProbe：一般支持的命令都是三种
- exec 执行命令来做健康状态检测且此命令一定时容器内部支持的命令
- httpGet 如果资源为web服务，也可以直接服务请求一个资源，如果请求成功为成功，无响应则为不健康
- tcpSocket 探测服务监听的某个端口，发起请求，根据响应判断健康与否
- failureThreshold （错误阈值）探测的多少次没有响应才视为服务出现问题，默认为三次
- successThreshold （成功阈值）探测连续成功多少次才视为成功，默认值为1，成功探测一次则视为成功,不可修改
- periodSeconds （检查周期）每次探测的时间间隔，默认为10s,最低值为1s
- initialDelaySeconds 资源初始化多久以后在进行探测检查，如果不定义默认为启动资源则开始执行探测
- timeoutSeconds （探测的超时时间间隔）每次检查资源未响应等待时间，比如请求发出一直等待响应的时间，默认1s
每次探测都将获得以下三种结果之一：
- 成功：容器通过了诊断。
- 失败：容器未通过诊断。
- 未知：诊断失败，因此不会采取任何行动。

1.1、readinessProbe存活探针

readinessProbe : 指示容器是否准备好服务请求（是否启动完成并就绪）。绪探针初始延迟之前的就绪状态默认为Failure，待容器启动成功弹指指标探测结果为成功后，状态变更为 Success。如果未配置就绪探针，则默认状态为Success。
只有状态为 Success ，才会被纳入 pod 所属 service 中，也就是 service 接收到请求后才有可能会被分发处理请求。

如果ReadinessProbe探针检测到失败，则Pod的状态被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。

1.1.1、存活探针 - HTTP协议

containers:
  - name: xxx
    image: xxx

    # 存活检查
    livenessProbe:
      httpGet:
        scheme: HTTP             # 协议
        path: /actuator/health   # 路径
        port: 8080               # 端口
      initialDelaySeconds: 30    # 延迟探测时间(秒) 【 在k8s第一次探测前等待秒 】
      periodSeconds: 10          # 执行探测频率(秒) 【 每隔秒执行一次 】
      timeoutSeconds: 1          # 超时时间
      successThreshold: 1        # 健康阀值 
      failureThreshold: 3        # 不健康阀值

1.1.2、存活探针 - TCP协议

containers:
  - name: xxx
    image: xxx

    # 存活检查
    livenessProbe:
      tcpSocket:                 # TCP
        port: 8090               # 端口
      initialDelaySeconds: 50    # 延迟探测时间(秒) 【 在k8s第一次探测前等待秒 】
      periodSeconds: 10          # 执行探测频率(秒) 【 每隔秒执行一次 】
      timeoutSeconds: 1          # 超时时间
      successThreshold: 1        # 健康阀值 
      failureThreshold: 3        # 不健康阀值 

# 上面配置的意思是容器启动50s后，每10s检查一次，允许失败的次数是3次。如果失败次数超过3则会触发restartPolicy。

1.2、readnessProbe就绪探针

readnessProbe : 用于判断容器是否存活（running状态），如果LivenessProbe探针探测到容器不健康（你可以配置连续多少次失败才记为不健康），则 kubelet 会杀掉该容器，并根据容器的重启策略做相应的处理。如果未配置存活探针，则默认状态为Success。即探针返回的值永远是 Success。

1.2.1、就绪探针 - HTTP协议

HTTP协议和TCP协议配置方法和存活探测相同

containers:
  - name: xxx
    image: xxx

    # 就绪检查
    readinessProbe:
      httpGet:
        scheme: HTTP             # 协议
        path: /actuator/health   # 路径
        port: 8080               # 端口
      initialDelaySeconds: 30    # 延迟探测时间(秒)【 在k8s第一次探测前等待秒 】
      periodSeconds: 2           # 执行探测频率(秒) 【 每隔秒执行一次 】
      timeoutSeconds: 1          # 超时时间
      successThreshold: 1        # 健康阀值 
      failureThreshold: 3        # 不健康阀值

1.3、startupProbe启动探针

startupProbe是在k8s v1.16加入了alpha版，官方对其作用的解释是：

Indicates whether the application within the Container is started. All other probes are disabled if a startup probe is provided, until it succeeds. If the startup probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a startup probe, the default state is Success

大概是意思是：判断容器内的应用程序是否已启动。如果提供了启动探测，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet将杀死容器，容器将服从其重启策略。如果容器没有提供启动探测，则默认状态为成功。

注意：不要将startupProbe和readinessProbe混淆。

1.3.1、启动探针

startupProbe 脚本内容和 readinessProbe 相比，除了名字不同之外，其他配置和含义相同；
通常将 startupProbe 和 livenessProbe 组合使用，livenessProbe 的时间是从 startupProbe 状态成功后开始计算；

livenessProbe:
  httpGet:
    path:/test
    prot:80
  failureThreshold:1
  initialDelay：10
  periodSeconds:10

startupProbe:
  httpGet:
    path:/test
    prot:80
  failureThreshold:10
  initialDelay：10
  periodSeconds:10

# 上面的配置是只有startupProbe探测成功后再交给livenessProbe。咱们startupProbe配置的是10*10s，也就是说只要应用在100s内启动都是OK的，并且应用挂掉了10s就会发现问题

标签：容器,livenessProbe,探针,探测,存活,readinessProbe,startupProbe
来源： https://www.cnblogs.com/dai-zhe/p/14992936.html