本篇文章1653字，讀完約4分鐘
阿里云國際站經(jīng)銷商，主營阿里云，騰訊云，華為云，亞馬遜aws，谷歌云gcp,微軟云az，免費開戶，代充值優(yōu)惠大，聯(lián)系客服飛機@jkkddd
背景信息
K8s中的健康檢查主要分為兩種：
Liveness：存活檢測，負責判斷容器是否需要重啟。
Readiness：就緒檢測，負責判斷容器是否需要承接流量。
核心參數(shù)：
檢查方式：TCP/HTTP/CMD。
延遲時間：容器啟動后，多久開始檢測。
檢查周期：決定檢查的頻率，靈敏度相關。
超時時間：檢查的超時等待時間。
成功閾值：探針在失敗后，被視為成功的最小連續(xù)成功數(shù)。Liveness必須設置為1。
失敗閾值：判定總體失敗的連續(xù)失敗數(shù)。
參數(shù)詳解（進階版）
延遲時間
對于Livness的配置，需要重點理解參數(shù)“延遲時間”，其作用是幫助健康檢查探針在合適的時候去探測業(yè)務容器的狀態(tài)。如果Livness健康檢查在不合適的時候去探測（延遲時間過短），會導致不斷重啟這一嚴重后果。
例如，一個Java應用啟動可能需要耗時2分鐘，如果全部按照默認配置，即延遲時間為10秒，檢查周期為30秒，失敗閾值為3，該應用將永遠不可能啟動成功。因為在上述設置中，Livness探針的三次健康檢查全部是在應用啟動完畢之前完成的，而應用啟動完畢之前進行健康探測，持續(xù)失敗就是預期中的結果。所以，該應用必然會不斷重啟。
因此，當初次部署應用時，如果無法確定應用的啟動時間，可以盡量將延遲時間調(diào)長一點（例如5分鐘），等應用成功啟動后，再根據(jù)業(yè)務日志確定大致的啟動耗時來修正延遲時間。需要注意的是，延遲時間過長也存在弊端，因為可能會讓整個發(fā)布時間過長。
TCP與HTTP方式的選擇
Liveness另一個容易踩坑的點是檢查方式，用戶需要為Readiness與Liveness配置不同的檢查方式。但是，許多用戶為了省事，將Readiness與Liveness設置成相同的檢查，其實這是非常危險的行為。因為Liveness與Readiness是兩種完全不同的探針，有著完全不同的作用。有時候業(yè)務由于流量擁塞導致不可用，只需摘除當前實例的流量，無需重啟容器。當前請求被正常處理完成后，就可以重新負載流量并接收請求。但是，如果此時重啟容器，可能會產(chǎn)生以下影響：
當前已有請求無法被順利處理。
由于當前實例重啟，可能會導致更長的時間無法負載流量，甚至出現(xiàn)雪崩。
例如，對于Java應用，Spring Boot框架提供了內(nèi)置的健康檢查。該健康檢查會檢測多個組件的情況，例如與Redis、Nacos等組件連接與心跳是否正常，并判斷是否需要重啟應用。由于網(wǎng)絡抖動以及相關組件服務的可用性無法完全確定，這類異常無法成為當前應用是否需要重啟的判斷依據(jù)。
因此，為了減少因下游鏈路的抖動造成預期外的實例重啟，必須區(qū)分Liveness與Readiness。如果不方便單獨實現(xiàn)一個接口來檢查應用自身的情況，可以通過Liveness采用TCP、Readiness采用HTTP的方式探測。重啟這一操作需要謹慎對待，因此檢測容錯率更高的TCP方式更適合Liveness。HTTP方式的檢測更容易反映業(yè)務的真實處理情況，更適合Readiness這一處理流量的檢測。
失敗閾值與成功閾值
對于Livenss而言，其實只有一個動作，即失敗重啟。因此，成功閾值固定為1，且不可修改（由于成功沒有顯式動作，所以成功閾值大于1也沒有意義）。而失敗閾值默認為3，即連續(xù)失敗三次，會認為真正失敗，并開始重啟容器。
對于Readiness而言，其實有兩種動作，成功則接入流量，失敗則切出流量。因此，為保證可用性，成功閾值與失敗閾值都推薦設置為1，即當出現(xiàn)檢測失敗時立即切出流量，從而盡可能短時間內(nèi)避免流量有損，而當檢測成功（即應用已經(jīng)做好接收流量的準備）后立即切入流量。但是，快速切流可能導致剩余實例平均網(wǎng)絡負載進一步增加，因此建議配合指標彈性一起使用。
標題：阿里云賬號實名注冊，阿里云服務器購買
地址：http://www.pengfei-china.com/kfxw/64424.html
