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源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。