专栏首页乔边故事kubernetes中启动探针startupProbe

kubernetes中启动探针startupProbe

16.1、startupProbe

因为k8s中采用大量的异步机制、以及多种对象关系设计上的解耦,当应用实例数 增加/删除、或者应用版本发生变化触发滚动升级时,系统并不能保证应用相关的service、ingress配置总是及时能完成刷新。在一些情况下,往往只是新的Pod完成自身初始化,系统尚未完成EndPoint、负载均衡器等外部可达的访问信息刷新,老得Pod就立即被删除,最终造成服务短暂的额不可用,这对于生产来说是不可接受的,所以k8s就加入了一些存活性探针:livenessProbereadinessProbe以及我们今天要介绍的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混淆。

那么在什么时候会用startupProbe呢? 正常情况下,我们会在pod template中配置livenessProbe来探测应用程序是否正常运行,如果异常则会触发restartPolicy重启Pod(因为默认情况下restartPolicy设置的是always)。 如下:

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

上面配置的意思是容器启动10s后每10s检查一次,允许失败的次数是1次。如果失败次数超过1则会触发restartPolicy。 但是有时候会存在特殊情况,比如服务A启动时间很慢,需要60s。这个时候如果还是用上面的探针就会进入死循环,因为上面的探针10s后就开始探测,这时候我们服务并没有起来,发现探测失败就会触发restartPolicy。这时候有的朋友可能会想到把initialDelay调成60s不就可以了?但是我们并不能保证这个服务每次起来都是60s,假如新的版本起来要70s,甚至更多的时间,我们就不好控制了。有的朋友可能还会想到把失败次数增加,比如下面配置:

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

这在启动的时候是可以解决我们目前的问题,但是如果这个服务挂了呢?如果failureThreshold=1则10s后就会报警通知服务挂了,如果设置了failureThreshold=5,那么就需要5*10s=50s的时间,在现在大家追求快速发现、快速定位、快速响应的时代是不被允许的。 在这时候我们把startupProbelivenessProbe结合起来使用就可以很大程度上解决我们的问题。 如下:

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就会发现问题。 有眼尖的朋友可能会说,这种还是不能确定具体时间,只能给出一个大概的范围。我个人认为对服务启动时间的影响因素太多了,有可能是应用本身,有可能是外部因素,比如主机性能等等。我们只有在最大程度上追求高效、稳定,但是我们不能保证100%稳定,像阿里这样的大企业对外宣称的也是5个9,6个9的稳定率,如果出问题了,不好意思你恰恰不在那几个9里面,所以我们自己要做好监控有效性,告警的及时性,响应的快速性,处理的高效性。

本文分享自微信公众号 - 乔边故事(qiaobiangushi),作者:乔克

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-03-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 轻量级日志系统Loki stack

    Loki 是一个可水平伸缩的、高可用的以及多租户的日志集中系统,有这么多功能,唯独没有全文检索。在其简介中,自称是受到 Prometheus 的启发:仅保存和处...

    极客运维圈
  • Alertmanager配置短信告警

    思路:通过自定义webhook的方式进行发送。 我简单写了一个webhook,项目地址:https://github.com/cool-ops/promethe...

    极客运维圈
  • ZABBIX自动发现Redis端口并监控

    由于一台服务器开启许多Redis实例,如果一台一台的监控太耗费时间,也非常容器出错。这种费力不讨好的事情我们是坚决杜绝的,幸好ZABBIX有自动发现功能,今天我...

    极客运维圈
  • 自增自减表达式-c语言学习笔记

    Youngxj
  • Leetcode-Easy 806. Number of Lines To Write String

    给一个字符串S,从左到右将它们排列行,每行最大长度为100,,同时给定一个数组withds,widths[0]对应着 a的宽度, widths[1]对应着b的宽...

    致Great
  • 数据分表小结

    本次拆分主要包括订单和优惠券两大块,这两块都是覆盖全集团所有分子公司所有业务线。随着公司的业务飞速发展,不管是存储的要求,还是写入、读取的性都基本上到了警戒水位...

    王清培
  • leetcode-806-Number of Lines To Write String

    chenjx85
  • Python内置函数sorted()从入门到精通

    Python内置函数sorted()可以对列表、元组、字典、集合、字符串、range对象以及其他可迭代对象进行排序,返回排序后的列表,支持使用key参数指定排序...

    Python小屋屋主
  • 卡特兰数扩展

    对于排队买票问题的一些说法.....   假若有M+ N人去买票,n人手持5元,m人手持10元,而售货阿姨没有零钱,问有多少种方法能使大家都买到票。 其中m<=...

    Gxjun
  • 互联网行业法律动态报告(2014年10月)

    互联网行业法律动态报告(2014年10月) 腾讯互联网与社会研究院法律研究中心 重点摘要: 2014年10月,网络治理、知识产权、竞争规则、电子商...

    腾讯研究院

扫码关注云+社区

领取腾讯云代金券