当前位置:   article > 正文

Kubernetes 0-1 Pod中的livenessProbe和readinessProbe解读_liveness probe

liveness probe

写在前面

K8S对Pod的健康状态可以通过两类探针来检查:livenessProbe和readinessProbe,kubelet通过定期执行这两类探针来诊断容器的健康状况。

livenessProbe简介

存活指针,判断Pod(中的应用容器)是否健康,可以理解为健康检查。我们使用livenessProbe来定期的去探测,如果探测成功,则Pod状态可以判定为Running;如果探测失败,可kubectl会根据Pod的重启策略来重启容器。

如果未给Pod设置livenessProbe,则默认探针永远返回Success。

当我们执行kubectl get pods命令,输出信息中STATUS一列我们可以看到Pod是否处于Running状态。

readinessProbe简介

就绪指针,就绪的意思是已经准备好了,Pod的就绪我们可以理解为这个Pod可以接受请求和访问。我们使用readinessProbe来定期的去探测,如果探测成功,则Pod 的Ready状态判定为True;如果探测失败,Pod的Ready状态判定为False。

与livenessProbe不同的是,kubelet不会对readinessProbe的探测情况有重启操作。

当我们执行kubectl get pods命令,输出信息中READY一列我们可以看到Pod的READY状态是否为True。

定义参数

livenessProbe和readinessProbe的定义参数是一致的,可以通过kubectl explain pods.spec.containers.readinessProbekubectl explain pods.spec.containers.livenessProbe命令了解:

就绪探针的几种类型:

httpGet

向容器发送Http Get请求,调用成功(通过Http状态码判断)则确定Pod就绪;

使用方式:

  1. livenessProbe:
  2. httpGet:
  3. path: /app/healthz
  4. port: 80

exec

在容器内执行某命令,命令执行成功(通过命令退出状态码为0判断)则确定Pod就绪;

使用方式:

  1. livenessProbe:
  2. exec:
  3. command:
  4. - cat
  5. - /app/healthz

tcpSocket

打开一个TCP连接到容器的指定端口,连接成功建立则确定Pod就绪。

使用方式:

  1. livenessProbe:
  2. tcpSocket:
  3. port: 80

一般就绪探针会在启动容器一段时间后才开始第一次的就绪探测,之后做周期性探测。所以在定义就绪指针时,会给以下几个参数:

  • initialDelaySeconds:在初始化容器多少秒后开始第一次就绪探测;
  • timeoutSeconds:如果该次就绪探测超过多少秒后还未成功,判定为超时,该次探测失败,Pod不就绪。默认值1,最小值1;
  • periodSeconds:如果Pod未就绪,则每隔多少秒周期性的做就绪探测。默认值10,最小值1;
  • failureThreshold:如果容器之前探测成功,后续连续几次探测失败,则确定容器未就绪。默认值3,最小值1;
  • successThreshold:如果容器之前探测失败,后续连续几次探测成功,则确定容器就绪。默认值1,最小值1。

使用示例

目前我在docker hub有一个测试镜像:med1tator/helloweb:v1,容器启动后,有一个健康检查路由/healthz/return200,访问该路由状态码返回200;有一个检查路由/health/return404,访问该路由状态码返回404。

readinessProbe示例

在实验之前先了解一下Pod和Service的负载均衡关系:在K8S中,Service作为Pod的负载均衡器,是通过Label Selector匹配Pod的。但是这句话没有说完整,因为还有一个必要条件:Pod当前已经就绪。也就是说,Service通过Label Selector匹配当前就绪的Pod,还未就绪的Pod就算labelSelector匹配上了,也不会出现在Service的endpoints中,请求是不会被转发过去的,如下图示例。

示例说明:我们使用med1tator/helloweb:v1镜像启动三个Pod,三个Pod的Label都设置成一样,为了使Service匹配到;三个Pod其中两个readinessProbe使用httpGet探测/health/return200,模拟探测成功,一个readinessProbe使用httpGet探测/health/return404,模拟探测失败。

编写我们的helloweb-readinessProbe.yaml文件如下:

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: helloweb1
  5. labels:
  6. app: helloweb
  7. spec:
  8. containers:
  9. - name: helloweb
  10. image: med1tator/helloweb:v1
  11. readinessProbe:
  12. httpGet:
  13. path: /healthz/return200
  14. port: 80
  15. initialDelaySeconds: 30
  16. timeoutSeconds: 10
  17. ports:
  18. - containerPort: 80
  19. ---
  20. apiVersion: v1
  21. kind: Pod
  22. metadata:
  23. name: helloweb2
  24. labels:
  25. app: helloweb
  26. spec:
  27. containers:
  28. - name: helloweb
  29. image: med1tator/helloweb:v1
  30. readinessProbe:
  31. httpGet:
  32. path: /healthz/return200
  33. port: 80
  34. initialDelaySeconds: 30
  35. timeoutSeconds: 10
  36. ports:
  37. - containerPort: 80
  38. ---
  39. apiVersion: v1
  40. kind: Pod
  41. metadata:
  42. name: helloweb3
  43. labels:
  44. app: helloweb
  45. spec:
  46. containers:
  47. - name: helloweb
  48. image: med1tator/helloweb:v1
  49. readinessProbe:
  50. httpGet:
  51. path: /healthz/return404
  52. port: 80
  53. initialDelaySeconds: 30
  54. timeoutSeconds: 10
  55. ports:
  56. - containerPort: 80
  57. ---
  58. apiVersion: v1
  59. kind: Service
  60. metadata:
  61. name: helloweb
  62. spec:
  63. selector:
  64. app: helloweb
  65. type: ClusterIP
  66. ports:
  67. - name: http
  68. port: 80
  69. targetPort: 80

运行命令部署Pod和Service:

kubectl apply -f helloweb-readinessProbe.yaml

之后,我们查看Pod的就绪情况:

可以看到Pod只有helloweb1和helloweb2当前使处于READY(就绪)的状态,helloweb3尚未Ready,我们接着查看helloweb service的endpoints:

可以看到Service的EndPoints只将helloweb1、helloweb2 pod的IP负载上了。

查看日志访问情况:

可以看到每隔10秒(readniessProbe.periodSeconds默认10s)就会做一次就绪探测。

livenessProbe示例

编写我们的helloweb-livenessProbe.yaml文件如下:

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: helloweb4
  5. labels:
  6. app: helloweb
  7. spec:
  8. containers:
  9. - name: helloweb
  10. image: med1tator/helloweb:v1
  11. livenessProbe:
  12. httpGet:
  13. path: /healthz/return200
  14. port: 80
  15. initialDelaySeconds: 30
  16. timeoutSeconds: 10
  17. ports:
  18. - containerPort: 80
  19. ---
  20. apiVersion: v1
  21. kind: Pod
  22. metadata:
  23. name: helloweb5
  24. labels:
  25. app: helloweb
  26. spec:
  27. containers:
  28. - name: helloweb
  29. image: med1tator/helloweb:v1
  30. livenessProbe:
  31. httpGet:
  32. path: /healthz/return404
  33. port: 80
  34. initialDelaySeconds: 30
  35. timeoutSeconds: 10
  36. ports:
  37. - containerPort: 80

运行命令部署Pod和Service:

kubectl apply -f helloweb-livenessProbe.yaml

之后,我们查看Pod的就绪情况:

可以看到helloweb4的STATUS状态为Running,而helloweb5的STATUS状态最终变为CrashLoopBackOff,并且一直在重启。

相信到这里,你已经对readniessProbelivenessProbe有一个清晰的了解了。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Monodyee/article/detail/247403?site
推荐阅读
相关标签
  

闽ICP备14008679号