16.一、startupProbe
由于k8s中采用大量的异步机制、以及多种对象关系设计上的解耦，当应用实例数 增长/删除、或者应用版本发生变化触发滚动升级时，系统并不能保证应用相关的service、ingress配置老是及时能完成刷新。在一些状况下，每每只是新的Pod完成自身初始化，系统还没有完成EndPoint、负载均衡器等外部可达的访问信息刷新，老得Pod就当即被删除，最终形成服务短暂的额不可用，这对于生产来讲是不可接受的，因此k8s就加入了一些存活性探针：livenessProbe、readinessProbe以及咱们今天要介绍的startupProbe。web
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混淆。app
那么在何时会用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的时间，在如今你们追求快速发现、快速定位、快速响应的时代是不被容许的。
在这时候咱们把startupProbe和livenessProbe结合起来使用就能够很大程度上解决咱们的问题。
以下：异步
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里面，因此咱们本身要作好监控有效性，告警的及时性，响应的快速性，处理的高效性。编辑器
完ide
-----------------------性能
公众号：乔边故事（ID：qiaobiangushi）url
知乎: 乔边故事
头条号：乔边故事
只要脸皮够厚，整个世界都将被你踩在脚下。
-----------------------
扫码二维码关注公众号，不按期维护优质内容，技术干货！
舒适提示
若是你喜欢本文，请分享到朋友圈，想要得到更多信息，请关注我。
本文分享自微信公众号 - 极客运维圈（qiaobiangushi）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。