手寫(xiě)實(shí)現(xiàn)掃描探針，面試官當(dāng)場(chǎng)問(wèn)懵？ 面試時(shí)被問(wèn)到 K8s 探針原理，90% 的人只能背出 Liveness 和 Readiness 的定義。面試官追問(wèn)：“如果我要手寫(xiě)實(shí)現(xiàn)一個(gè)掃描探針，核心邏輯是什么？” 瞬間大腦空白。這種場(chǎng)景太常見(jiàn)了。很多應(yīng)屆生背了概念，卻不懂底層如何執(zhí)行檢查，導(dǎo)致在系統(tǒng)設(shè)計(jì)題或故障排查題中徹底卡殼。 今天不聊虛的，直接上干貨。我們將通過(guò)手寫(xiě)實(shí)現(xiàn)的方式，拆解掃描探針的核心機(jī)制。對(duì)比三種主流探針類(lèi)型：HTTP Get、TCP Socket 和 Exec。你會(huì)發(fā)現(xiàn)，所謂探針，本質(zhì)就是一個(gè)定時(shí)任務(wù)加一個(gè)判定邏輯。掌握這個(gè)底層邏輯，面試時(shí)你不再是背書(shū)機(jī)器，而是能講清“為什么這么設(shè)計(jì)”的工程師。 探針的核心定位與面試陷阱 很多新人混淆了“健康檢查”和“探針”。在 Kubernetes 語(yǔ)境下，探針是 kubelet 組件執(zhí)行的周期性操作。根據(jù) Kubernetes 官方文檔，探針?lè)譃槿N：Liveness Probe（存活探針）：判斷容器是否運(yùn)行正常。如果失敗，kubelet 會(huì)殺死容器并重啟策略決定后續(xù)動(dòng)作。 Readiness Probe（就緒探針）：判斷容器是否準(zhǔn)備好接收流量。如果失敗，Service 不會(huì)將流量轉(zhuǎn)發(fā)給該 Pod。 Startup Probe（啟動(dòng)探針）：針對(duì)啟動(dòng)緩慢的應(yīng)用，在成功之前禁用其他探針。面試陷阱在于：面試官往往不問(wèn)“是什么”，而是問(wèn)“區(qū)別是什么”以及“失敗后果是什么”。Liveness 失敗 = 重啟容器。這可能導(dǎo)致數(shù)據(jù)丟失或雪崩效應(yīng)，所以配置要保守，容忍度高。 Readiness 失敗 = 摘除流量。這比重啟好，但可能導(dǎo)致負(fù)載均衡不均。 Startup 失敗 = 一直等待直到超時(shí)。這是保護(hù)慢啟動(dòng)應(yīng)用的關(guān)鍵。關(guān)鍵點(diǎn)：不要死記硬背。你要理解，探針是 K8s 與容器內(nèi)部應(yīng)用之間的“握手協(xié)議”。如果你手寫(xiě)一個(gè)監(jiān)控腳本，你需要決定：檢查什么？多久檢查一次？失敗幾次算死？這就是探針的本質(zhì)。 核心差異對(duì)比：HTTP vs TCP vs Exec 為了讓你一目了然，我們用一張表格對(duì)比三種探針實(shí)現(xiàn)方式的核心差異。這也是面試中展示結(jié)構(gòu)化思維的好機(jī)會(huì)。特性 HTTP Get TCP Socket Exec檢查層級(jí) 應(yīng)用層 (L7) 傳輸層 (L4) 進(jìn)程層 (L0)依賴(lài) 需要應(yīng)用提供 HTTP 接口 需要端口監(jiān)聽(tīng) 需要容器內(nèi)有執(zhí)行權(quán)限開(kāi)銷(xiāo) 高 (建立連接+解析響應(yīng)) 低 (僅三次握手) 中 (fork 子進(jìn)程)準(zhǔn)確性 最高 (能檢查業(yè)務(wù)邏輯) 低 (端口通不代表服務(wù)正常) 取決于腳本質(zhì)量適用場(chǎng)景 Web 服務(wù)、微服務(wù) 數(shù)據(jù)庫(kù)、中間件 無(wú) HTTP 接口的后臺(tái)任務(wù)調(diào)試難度 中等 簡(jiǎn)單 復(fù)雜 (需進(jìn)容器看日志)深度解析：HTTP Get 是最推薦的默認(rèn)選擇。因?yàn)樗軝z查到應(yīng)用是否真的能處理請(qǐng)求。比如，Tomcat 啟動(dòng)了，但數(shù)據(jù)庫(kù)連接池滿(mǎn)了，HTTP 探針?lè)祷?500，K8s 就會(huì)摘除流量。這是 TCP 探針做不到的。 TCP Socket 性能最好，但最“騙人”。MySQL 端口 3306 通了，不代表你能查詢(xún)成功。它只保證網(wǎng)絡(luò)層是通的。 Exec 最靈活，但也最危險(xiǎn)。如果你在 Exec 里跑了個(gè) sleep 10，探針就會(huì)超時(shí)。而且每次檢查都要 fork 進(jìn)程，在資源受限的 Pod 里要謹(jǐn)慎。代碼實(shí)戰(zhàn)：手寫(xiě)三種探針邏輯 光說(shuō)不練假把式。我們用 Python 和 Go 分別手寫(xiě)實(shí)現(xiàn)這三種探針的核心判定邏輯。注意，這不是完整的 K8s 控制器，而是探針執(zhí)行器（Executor）的核心代碼。理解這段代碼，你就懂了 K8s 底層是怎么工作的。 1. HTTP Get 探針實(shí)現(xiàn) (Python) 模擬 kubelet 發(fā)送 HTTP 請(qǐng)求并判斷狀態(tài)碼。 import requests import timedef http_probe(host, port, path, timeout=3):模擬 HTTP Get 探針?lè)祷? True 表示健康, False 表示不健康url = fhttp://{host}:{port}{path}try:# 設(shè)置超時(shí)，防止探針阻塞response = requests.get(url, timeout=timeout)# K8s 默認(rèn)認(rèn)為 200-399 為成功if 200 = response.status_code 400:return Trueelse:# 記錄日志，方便調(diào)試print(fHTTP Probe Failed: {response.status_code})return Falseexcept requests.exceptions.RequestException as e:# 連接超時(shí)、DNS 解析失敗等都算失敗print(fHTTP Probe Exception: {e})return False# 模擬循環(huán)檢查 if __name__ == __main__:while True:is_healthy = http_probe(localhost, 8080, /healthz)print(fStatus: {'Healthy' if is_healthy else 'Unhealthy'})time.sleep(10) # 模擬 periodSeconds逐行講解：timeout=3：對(duì)應(yīng) K8s 配置中的 timeoutSeconds。如果應(yīng)用響應(yīng)慢，這里必須調(diào)大，否則誤判。 200 = response.status_code 400：這是 K8s 的默認(rèn)判定邏輯。注意，4xx 錯(cuò)誤通常也被視為“服務(wù)可達(dá)但業(yè)務(wù)錯(cuò)誤”，具體取決于你的應(yīng)用設(shè)計(jì)。有些團(tuán)隊(duì)會(huì)將 404 視為不健康，這需要在業(yè)務(wù)層做特殊處理。2. TCP Socket 探針實(shí)現(xiàn) (Go) Go 語(yǔ)言在并發(fā)網(wǎng)絡(luò)編程上有天然優(yōu)勢(shì)，適合模擬高頻率的 TCP 檢查。 package mainimport (fmtnettime )func tcpProbe(host string, port int, timeout time.Duration) bool {// 構(gòu)造地址address := fmt.Sprintf(%s:%d, host, port)// 建立 TCP 連接conn, err := net.DialTimeout(tcp, address, timeout)if err != nil {fmt.Printf(TCP Probe Failed: %v\n, err)return false}// 關(guān)鍵點(diǎn)：必須關(guān)閉連接，否則資源泄漏conn.Close()return true }func main() {for {// 模擬 periodSeconds = 10s, timeoutSeconds = 3sisHealthy := tcpProbe(localhost, 3306, 3*time.Second)fmt.Printf(Status: %v\n, isHealthy)time.Sleep(10 * time.Second)} }避坑指南：資源泄漏：很多新手手寫(xiě)探針時(shí)忘記 conn.Close()。在高頻檢查下，這會(huì)導(dǎo)致 too many open files 錯(cuò)誤，進(jìn)而導(dǎo)致節(jié)點(diǎn)故障。 防火墻干擾：TCP 探針只檢查端口連通性。如果安全組或 iptables 規(guī)則變更，TCP 探針會(huì)立刻失敗，但這不代表應(yīng)用掛了。3. Exec 探針實(shí)現(xiàn) (Bash/Shell) Exec 探針在容器內(nèi)執(zhí)行命令。這里我們展示如何判定命令退出碼。 #!/bin/bash # exec_probe.sh# 檢查進(jìn)程是否存在 if ! pgrep -f my-app-server /dev/null; thenecho Process not foundexit 1 # 非 0 退出碼表示失敗 fi# 檢查內(nèi)存使用是否超過(guò)閾值 (示例) MEM_LIMIT=512 # MB CURRENT_MEM=$(ps -o %m -p $(pgrep -f my-app-server) | awk '{print int($1 * 100)}') if [ $CURRENT_MEM -gt $MEM_LIMIT ]; thenecho Memory limit exceeded: ${CURRENT_MEM}%exit 1 fi# 所有檢查通過(guò) exit 0注意：退出碼：K8s 規(guī)定，只有退出碼為 0 才表示成功。任何非 0 值都視為失敗。 腳本性能：Exec 探針會(huì) fork 子進(jìn)程。如果腳本復(fù)雜（如運(yùn)行 Python 腳本），啟動(dòng)開(kāi)銷(xiāo)大。建議保持腳本輕量。進(jìn)階技巧與避坑指南 掌握了基礎(chǔ)代碼，還需要知道生產(chǎn)環(huán)境中的“坑”。初始延遲 (initialDelaySeconds)： 應(yīng)用啟動(dòng)需要時(shí)間。如果你配置 initialDelaySeconds: 0，探針會(huì)在容器剛啟動(dòng)、應(yīng)用還沒(méi)監(jiān)聽(tīng)端口時(shí)就開(kāi)始檢查，導(dǎo)致立刻失敗并重啟，陷入死循環(huán)。建議：根據(jù)應(yīng)用冷啟動(dòng)時(shí)間設(shè)置合理的初始延遲，或者使用 Startup Probe。失敗閾值 (failureThreshold)： 網(wǎng)絡(luò)抖動(dòng)是常態(tài)。如果 failureThreshold: 1，一次網(wǎng)絡(luò)波動(dòng)就會(huì)重啟容器。建議：至少設(shè)置為 3。給應(yīng)用和系統(tǒng)恢復(fù)的時(shí)間。Liveness 與 Readiness 共用端口的陷阱： 很多應(yīng)用只有一個(gè) /health 端點(diǎn)。如果 Liveness 和 Readiness 都指向它，當(dāng)依賴(lài)的下游服務(wù)（如 DB）短暫不可用時(shí)，Liveness 失敗會(huì)導(dǎo)致 Pod 重啟，加劇故障。最佳實(shí)踐：Liveness 只檢查自身進(jìn)程是否存活；Readiness 檢查依賴(lài)服務(wù)是否可用。資源限制： 探針本身也消耗資源。在 CPU 限制很低的 Pod 中，頻繁的 HTTP 檢查可能導(dǎo)致 CPU 爭(zhēng)搶?zhuān)炊绊憫?yīng)用性能。監(jiān)控探針的執(zhí)行耗時(shí)，必要時(shí)降低檢查頻率。選型建議與面試應(yīng)答策略 回到面試場(chǎng)景。當(dāng)面試官問(wèn)“你怎么選擇探針類(lèi)型？”時(shí)，不要只說(shuō)“看應(yīng)用”。你要給出決策樹(shù)：應(yīng)用是否提供 HTTP 接口？是 → 優(yōu)先使用 HTTP Get。檢查 /healthz 端點(diǎn)，確保業(yè)務(wù)邏輯正常。 否 → 進(jìn)入下一步。應(yīng)用是否監(jiān)聽(tīng) TCP 端口？是 → 使用 TCP Socket。適用于數(shù)據(jù)庫(kù)、消息隊(duì)列等。 否 → 進(jìn)入下一步。是否有特定的健康檢查腳本？是 → 使用 Exec。確保腳本輕量且退出碼正確。 否 → 考慮是否真的需要探針。對(duì)于無(wú)網(wǎng)絡(luò)服務(wù)的后臺(tái)批處理任務(wù)，可能只需要 Liveness 檢查進(jìn)程存在即可。面試金句： “探針不是越嚴(yán)格越好，而是要匹配應(yīng)用的啟動(dòng)特性和故障模式。Liveness 要‘寬容’，避免誤殺；Readiness 要‘敏感’，快速摘除壞節(jié)點(diǎn)。手寫(xiě)實(shí)現(xiàn)讓我明白，探針本質(zhì)上是一個(gè)帶重試機(jī)制的 HTTP/TCP 客戶(hù)端，理解這一點(diǎn)就能靈活配置參數(shù)?！?總結(jié)與互動(dòng) 通過(guò)手寫(xiě)實(shí)現(xiàn)掃描探針，我們剝開(kāi)了 K8s 的神秘面紗。它不是魔法，而是簡(jiǎn)單的網(wǎng)絡(luò)請(qǐng)求加邏輯判斷。HTTP 最準(zhǔn)確，適合 Web 服務(wù)。 TCP 最輕量，適合中間件。 Exec 最靈活，適合特殊場(chǎng)景。面試中，能講出“探針執(zhí)行器”的底層邏輯，并對(duì)比三種方式的優(yōu)缺點(diǎn)，足以讓面試官眼前一亮。這比背誦 YAML 配置強(qiáng)大得多。 互動(dòng)話(huà)題： 這個(gè)知識(shí)點(diǎn)你面試被問(wèn)過(guò)嗎？你在實(shí)際項(xiàng)目中遇到過(guò)因?yàn)樘结樑渲貌划?dāng)導(dǎo)致的“雪崩重啟”嗎？留言說(shuō)說(shuō)你的排查過(guò)程，我們一起拆解。