kubernetes - 启动探测器 - startupProbe

• 官方定义
• startupProbe的存在意义
• 实际案例
  • 说明：很明显启动探测是先进行验证的，验证以后才有所谓的存活探测。但是，在此 pod 中特别设计了一下启动探测的错误，所以在 5 分钟后，此 pod 会发生重载，满足预期
• 其它

官方定义

可以定义一个启动探针，该探针将推迟所有其他探针，直到 Pod 完成启动为止，于 1.17 版本以后完成支持

startupProbe的存在意义

startupProbe 和 livenessProbe 最大的区别就是 startupProbe 在探测成功之后就不会继续探测了，而 livenessProbe 在 pod 的生命周期中一直在探测

如果没有 startupProbe 探针的话我们只设置 livenessProbe 探针话会存在如下问题： 一个服务如果前期启动需要很长时间，那么它后面死亡未被发现的时间就越长，为什么会这么说呢？假设我们一个服务 A 启动完成需要 2 分钟，那么我们如下开始定义 livenessProbe

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

如果我们这样定义的话，那 pod 5s 就会根据重启策略进行一次重启，这个时候你会发现 pod 一直会陷入死循环，那我们可以按照上面的猜想把配置改成这样

livenessProbe:
  httpGet:
    path: /test
    prot: 80
failureThreshold: 6
initialDelay：40
periodSeconds: 5

你肯定会说你看这样不就行了吗？这样的话pod就不会陷入死循环能启动起来了，确实这样 pod 能够启动起来了，但是你有没有考虑过这样一个问题，当我们启动完成之后，在后期的探测中，你需要 6*5=30s 才能发现这个 pod 不可用，这个时候你的服务已经停止运行了 30s 你才发现，这在生产中有可能是不会被原谅的。还有就是这边只是我们假设一个服务 A 需要 1 分钟才能起来，但是在实际生产中你如何定义这些值呢？？？针对上面这两个问题引入startupProbe之后都解决了

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

livenessProbe:
  httpGet:
    path: /test
    prot: 80
failureThreshold: 60
initialDelay：5
periodSeconds: 5

我们这样设置之后，由于启动探针的存在，程序有 60 x 5s=300s 的启动时间，一旦启动探针探测成功之后，就会被 livenessProbe 接管，这样在运行中出问题 livenessProbe 就能在 1*5=5s 内发现。如果启动探测是 3 分钟内还没有探测成功，则接受 Pod 的重启策略进行重启

实际案例

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: wangyanglinux/myapp:v1
    livenessProbe:
      httpGet:
        path: /hostname.html
        port: 80
      failureThreshold: 1
      periodSeconds: 10
    startupProbe:
      httpGet:
        path: /hostname.html
        port: 81
      failureThreshold: 30
      periodSeconds: 10

# 结果显示
[root@k8s-master01 ~]# kubectl describe  pod myapp-pod
    Events:
      Type     Reason     Age                   From                   Message
      ----     ------     ----                  ----                   -------
      Normal   Scheduled  <unknown>             default-scheduler      Successfully assigned default/myapp-pod to k8s-master01
      Normal   Pulled     19m                   kubelet, k8s-master01  Container image "wangyanglinux/myapp:v1" already present on machine
      Normal   Created    19m                   kubelet, k8s-master01  Created container myapp
      Normal   Started    19m                   kubelet, k8s-master01  Started container myapp
      Normal   Killing    9m7s (x2 over 14m)    kubelet, k8s-master01  Container myapp failed startup probe, will be restarted
      Warning  Unhealthy  4m50s (x86 over 19m)  kubelet, k8s-master01  Startup probe failed: Get http://10.244.0.9:81/hostname.html: dial tcp 10.244.0.9:81: connect: connection refused

说明：很明显启动探测是先进行验证的，验证以后才有所谓的存活探测。但是，在此 pod 中特别设计了一下启动探测的错误，所以在 5 分钟后，此 pod 会发生重载，满足预期

其它

探测有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为

• initialDelaySeconds：容器启动后要等待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0
• periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1
• timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1
• successThreshold：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1
• failureThreshold：当探测失败时，Kubernetes 的重试次数。 存活探测情况下的放弃就意味着重新启动容器。 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1