建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號(hào)「運(yùn)維開發(fā)故事」，作者沒有文案的夏老師。轉(zhuǎn)載本文請(qǐng)聯(lián)系運(yùn)維開發(fā)故事公眾號(hào)。
怎么配置Pod的liveness和readiness與startup探針
當(dāng)你使用kubernetes的時(shí)候，有沒有遇到過Pod在啟動(dòng)后一會(huì)就掛掉然后又重新啟動(dòng)這樣的惡性循環(huán)?你有沒有想過kubernetes是如何檢測(cè)pod是否還存活?雖然容器已經(jīng)啟動(dòng)，但是kubernetes如何知道容器的進(jìn)程是否準(zhǔn)備好對(duì)外提供服務(wù)了呢?讓我們通過kubernetes官網(wǎng)的這篇文章Configure Liveness and Readiness Probes，來一探究竟。
本文將展示如何配置容器的存活和可讀性探針。
Kubelet使用liveness probe(存活探針)來確定何時(shí)重啟容器。例如，當(dāng)應(yīng)用程序處于運(yùn)行狀態(tài)但無法做進(jìn)一步操作，liveness探針將捕獲到deadlock，重啟處于該狀態(tài)下的容器，使應(yīng)用程序在存在bug的情況下依然能夠繼續(xù)運(yùn)行下去(誰的程序還沒幾個(gè)bug呢)。
Kubelet使用readiness probe(就緒探針)來確定容器是否已經(jīng)就緒可以接受流量。只有當(dāng)Pod中的容器都處于就緒狀態(tài)時(shí)kubelet才會(huì)認(rèn)定該P(yáng)od處于就緒狀態(tài)。該信號(hào)的作用是控制哪些Pod應(yīng)該作為service的后端。如果Pod處于非就緒狀態(tài)，那么它們將會(huì)被從service的load balancer中移除。
Kubelet使用startup probe(啟動(dòng)探針)來確定容器是否已經(jīng)啟動(dòng)。有時(shí)候，會(huì)有一些現(xiàn)有的應(yīng)用程序在啟動(dòng)時(shí)需要較多的初始化時(shí)間。要不影響對(duì)引起探測(cè)死鎖的快速響應(yīng)，在這種情況下，設(shè)置存活探測(cè)參數(shù)是要技巧的。技巧就是使用一個(gè)命令來設(shè)置啟動(dòng)探測(cè)，針對(duì)HTTP 或者 TCP 檢測(cè)，可以通過設(shè)置 failureThreshold * periodSeconds 參數(shù)來保證有足夠長(zhǎng)的時(shí)間應(yīng)對(duì)糟糕情況下的啟動(dòng)時(shí)間。
定義 liveness命令
許多長(zhǎng)時(shí)間運(yùn)行的應(yīng)用程序最終會(huì)轉(zhuǎn)換到broken狀態(tài)，除非重新啟動(dòng)，否則無法恢復(fù)。Kubernetes提供了liveness probe來檢測(cè)和補(bǔ)救這種情況。在本次練習(xí)將基于 gcr.io/google_containers/busybox鏡像創(chuàng)建運(yùn)行一個(gè)容器的Pod。以下是Pod的配置文件exec-liveness.yaml：
- apiVersion: v1
- kind: Pod
- metadata:
- labels:
- test: liveness
- name: liveness-exec
- spec:
- containers:
- - name: liveness
- args:
- - /bin/sh
- - -c
- - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
- image: gcr.io/google_containers/busybox
- livenessProbe:
- exec:
- command:
- - cat
- - /tmp/healthy
- initialDelaySeconds: 5
- periodSeconds: 5
該配置文件給Pod配置了一個(gè)容器。periodSeconds 規(guī)定kubelet要每隔5秒執(zhí)行一次liveness probe。initialDelaySeconds 告訴kubelet在第一次執(zhí)行probe之前要的等待5秒鐘。探針檢測(cè)命令是在容器中執(zhí)行 cat /tmp/healthy 命令。如果命令執(zhí)行成功，將返回0，kubelet就會(huì)認(rèn)為該容器是活著的并且很健康。如果返回非0值，kubelet就會(huì)殺掉這個(gè)容器并重啟它。容器啟動(dòng)時(shí)，執(zhí)行該命令：
- /bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
在容器生命的最初30秒內(nèi)有一個(gè) /tmp/healthy 文件，在這30秒內(nèi) cat /tmp/healthy命令會(huì)返回一個(gè)成功的返回碼。30秒后， cat /tmp/healthy 將返回失敗的返回碼。創(chuàng)建Pod：
- kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/exec-liveness.yaml
在30秒內(nèi)，查看Pod的event：
- kubectl describe pod liveness-exec
結(jié)果顯示沒有失敗的liveness probe：
- FirstSeen LastSeen Count From SubobjectPath Type Reason Message
- --------- -------- ----- ---- ------------- -------- ------ -------
- 24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
- 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "gcr.io/google_containers/busybox"
- 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/busybox"
- 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
- 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
啟動(dòng)35秒后，再次查看pod的event：
- kubectl describe pod liveness-exec
在最下面有一條信息顯示liveness probe失敗，容器被刪掉并重新創(chuàng)建。
- FirstSeen LastSeen Count From SubobjectPath Type Reason Message
- --------- -------- ----- ---- ------------- -------- ------ -------
- 37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
- 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "gcr.io/google_containers/busybox"
- 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/busybox"
- 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
- 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
- 2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
再等30秒，確認(rèn)容器已經(jīng)重啟：
- kubectl get pod liveness-exec
從輸出結(jié)果來RESTARTS值加1了
- NAME READY STATUS RESTARTS AGE
- liveness-exec 1/1 Running 1 1m
定義一個(gè)liveness HTTP請(qǐng)求
我們還可以使用HTTP GET請(qǐng)求作為liveness probe。下面是一個(gè)基于gcr.io/google_containers/liveness鏡像運(yùn)行了一個(gè)容器的Pod的例子http-liveness.yaml：該配置文件只定義了一個(gè)容器，livenessProbe 指定kubelet需要每隔3秒執(zhí)行一次liveness probe。initialDelaySeconds 指定kubelet在該執(zhí)行第一次探測(cè)之前需要等待3秒鐘。該探針將向容器中的server的8080端口發(fā)送一個(gè)HTTP GET請(qǐng)求。如果server的/healthz路徑的handler返回一個(gè)成功的返回碼，kubelet就會(huì)認(rèn)定該容器是活著的并且很健康。如果返回失敗的返回碼，kubelet將殺掉該容器并重啟它。任何大于200小于400的返回碼都會(huì)認(rèn)定是成功的返回碼。其他返回碼都會(huì)被認(rèn)為是失敗的返回碼。最開始的10秒該容器是活著的， /healthz handler返回200的狀態(tài)碼。這之后將返回500的返回碼。
- http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
- duration := time.Now().Sub(started)
- if duration.Seconds() > 10 {
- w.WriteHeader(500)
- w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
- } else {
- w.WriteHeader(200)
- w.Write([]byte("ok"))
- }
- })
容器啟動(dòng)3秒后，kubelet開始執(zhí)行健康檢查。第一次健康監(jiān)測(cè)會(huì)成功，但是10秒后，健康檢查將失敗，kubelet將殺掉和重啟容器。創(chuàng)建一個(gè)Pod來測(cè)試一下HTTP liveness檢測(cè)：
- kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/http-liveness.yaml
After 10 seconds, view Pod events to verify that liveness probes have failed and the Container has been restarted: 10秒后，查看Pod的event，確認(rèn)liveness probe失敗并重啟了容器。
- kubectl describe pod liveness-http
定義TCP liveness探針
第三種liveness probe使用TCP Socket。使用此配置，kubelet將嘗試在指定端口上打開容器的套接字。如果可以建立連接，容器被認(rèn)為是健康的，如果不能就認(rèn)為是失敗的。
- apiVersion: v1
- kind: Pod
- metadata:
- name: goproxy
- labels:
- app: goproxy
- spec:
- containers:
- - name: goproxy
- image: gcr.io/google_containers/goproxy:0.1
- ports:
- - containerPort: 8080
- readinessProbe:
- tcpSocket:
- port: 8080
- initialDelaySeconds: 5
- periodSeconds: 10
- livenessProbe:
- tcpSocket:
- port: 8080
- initialDelaySeconds: 15
- periodSeconds: 20
TCP檢查的配置與HTTP檢查非常相似。此示例同時(shí)使用了readiness和liveness probe。容器啟動(dòng)后5秒鐘，kubelet將發(fā)送第一個(gè)readiness probe。這將嘗試連接到端口8080上的goproxy容器。如果探測(cè)成功，則該pod將被標(biāo)記為就緒。Kubelet將每隔10秒鐘執(zhí)行一次該檢查。除了readiness probe之外，該配置還包括liveness probe。容器啟動(dòng)15秒后，kubelet將運(yùn)行第一個(gè)liveness probe。就像readiness probe一樣，這將嘗試連接到goproxy容器上的8080端口。如果liveness probe失敗，容器將重新啟動(dòng)。使用命名的端口，可以使用命名的ContainerPort作為HTTP或TCP liveness檢查：
- ports:
- - name: liveness-port
- containerPort: 8080
- hostPort: 8080
- livenessProbe:
- httpGet:
- path: /healthz
- port: 8080
定義readiness探針
有時(shí)，應(yīng)用程序暫時(shí)無法對(duì)外部流量提供服務(wù)。例如，應(yīng)用程序可能需要在啟動(dòng)期間加載大量數(shù)據(jù)或配置文件。在這種情況下，你不想殺死應(yīng)用程序，但你也不想發(fā)送請(qǐng)求。Kubernetes提供了readiness probe來檢測(cè)和減輕這些情況。Pod中的容器可以報(bào)告自己還沒有準(zhǔn)備，不能處理Kubernetes服務(wù)發(fā)送過來的流量。
Readiness probe的配置跟liveness probe很像。唯一的不同是使用 readinessProbe而不是livenessProbe。
- readinessProbe:
- exec:
- command:
- - cat
- - /tmp/healthy
- initialDelaySeconds: 5
- periodSeconds: 5
Readinessprobe的HTTP和TCP的探測(cè)器配置跟liveness probe一樣。Readiness和livenssprobe可以并行用于同一容器。使用兩者可以確保流量無法到達(dá)未準(zhǔn)備好的容器，并且容器在失敗時(shí)重新啟動(dòng)。
定義startup探針
這是kubernetes1.16帶來的新功能。Probes 允許 Kubernetes 監(jiān)控應(yīng)用程序的狀態(tài)?？梢允褂胠ivenessProbe定期檢查應(yīng)用程序是否還活著。一個(gè)示例容器定義了這個(gè)探測(cè)器：
- livenessProbe : httpGet:
- path: /healthz
- port: 8080
- failureThreshold: 3
- periodSeconds: 10
如果在 30 秒內(nèi)失敗 3 次，容器將重新啟動(dòng)。但是由于這個(gè)容器很慢，需要30多秒才能啟動(dòng)，所以探針會(huì)失敗，容器會(huì)再次重啟。這個(gè)新特性讓你可以定義一個(gè)startupProbe在 pod 完成啟動(dòng)之前阻止所有其他探測(cè)的方法：
- startupProbe:
- httpGet:
- path: /healthz
- port: 8080
- failureThreshold: 30
- periodSeconds: 10
現(xiàn)在我們的慢速容器最多有 5 分鐘(30 個(gè)檢查 * 10 秒 = 300 秒)來完成它的啟動(dòng)。
配置Probe
Probe 中有很多精確和詳細(xì)的配置，通過它們你能準(zhǔn)確的控制liveness和readiness檢查：
- initialDelaySeconds：容器啟動(dòng)后第一次執(zhí)行探測(cè)是需要等待多少秒。
- periodSeconds：執(zhí)行探測(cè)的頻率。默認(rèn)是10秒，最小1秒。
- timeoutSeconds：探測(cè)超時(shí)時(shí)間。默認(rèn)1秒，最小1秒。
- successThreshold：探測(cè)失敗后，最少連續(xù)探測(cè)成功多少次才被認(rèn)定為成功。默認(rèn)是1。對(duì)于liveness必須是1。最小值是1。
- failureThreshold：探測(cè)成功后，最少連續(xù)探測(cè)失敗多少次才被認(rèn)定為失敗。默認(rèn)是3。最小值是1。
HTTP probe 可以給 httpGet設(shè)置其他配置項(xiàng)：
- host：連接的主機(jī)名，默認(rèn)連接到pod的IP。你可能想在http header中設(shè)置"Host"而不是使用IP。
- scheme：連接使用的schema，默認(rèn)HTTP。
- path: 訪問的HTTP server的path。
- httpHeaders：自定義請(qǐng)求的header。HTTP運(yùn)行重復(fù)的header。
- port：訪問的容器的端口名字或者端口號(hào)。端口號(hào)必須介于1和65535之間。
對(duì)于HTTP探測(cè)器，kubelet向指定的路徑和端口發(fā)送HTTP請(qǐng)求以執(zhí)行檢查。Kubelet將probe發(fā)送到容器的IP地址，除非地址被httpGet中的可選host字段覆蓋。在大多數(shù)情況下，你不想設(shè)置主機(jī)字段。有一種情況下你可以設(shè)置它。假設(shè)容器在127.0.0.1上偵聽，并且Pod的hostNetwork字段為true。然后，在httpGet下的host應(yīng)該設(shè)置為127.0.0.1。如果你的pod依賴于虛擬主機(jī)，這可能是更常見的情況，你不應(yīng)該用host，而是應(yīng)該在httpHeaders中設(shè)置Host頭。
我們應(yīng)該怎么做?
- 對(duì)于提供 HTTP 協(xié)議(REST 服務(wù)等)的微服務(wù)， 始終定義一個(gè)ReadinessProbe，用于檢查的應(yīng)用程序(Pod)是否已準(zhǔn)備好接收流量。
- 對(duì)于慢啟動(dòng)的應(yīng)用，我們應(yīng)該使用StartupProbe，來防止容器沒有啟動(dòng)，就被LivenessProbe殺死了。
- 如果服務(wù)是多端口的，請(qǐng)確保ReadinessProbe覆蓋了所以的端口。例如：為readinessProbe使用“admin”或“management”端口(例如 9090)時(shí)，請(qǐng)確保端點(diǎn)僅在主要 HTTP 端口(例如 8080)準(zhǔn)備好接受流量時(shí)才返回 success.
- 使用httpGet對(duì)服務(wù)端口與路徑(例如 /health)進(jìn)行就緒探測(cè)。
我們不應(yīng)該怎么做?
- 不要依賴外部依賴項(xiàng)(如數(shù)據(jù)存儲(chǔ))進(jìn)行就緒/探活檢查，因?yàn)檫@可能會(huì)導(dǎo)致級(jí)聯(lián)故障
1. 假如10 個(gè)pod的服務(wù)，數(shù)據(jù)庫使用Postgres，緩存使用redis：當(dāng)你的探針的路徑依賴于工作的redis連接時(shí)，如果出現(xiàn)redis/網(wǎng)絡(luò)故障，則所有 10 個(gè) Pod 都將“重啟”——這通常會(huì)產(chǎn)生影響比它應(yīng)該的更糟。因?yàn)榉?wù)還能到Postgres拿去數(shù)據(jù)。
2. 服務(wù)最好不要與數(shù)據(jù)庫做強(qiáng)依賴。
3. 只探測(cè)自己內(nèi)部的端口，不要去探測(cè)外部pod的端口。探測(cè)器不應(yīng)依賴于同一集群中其他 Pod 的狀態(tài)，以防止級(jí)聯(lián)故障。
- 需要明確知道使用 Liveness Probe 的原因，否則不要為 Pod 使用 Liveness Probe。
Liveness Probe 可以幫助恢復(fù)“卡住”的容器，但是當(dāng)我們能控制我們的應(yīng)用程序，出現(xiàn)意料之外的“卡住”進(jìn)程和死鎖之類的故障，更好的選擇是從應(yīng)用內(nèi)部故意崩潰以恢復(fù)到已知良好狀態(tài)。
失敗的 Liveness Probe 將導(dǎo)致容器重啟，從而可能使與負(fù)載相關(guān)的錯(cuò)誤的影響變得更糟：容器重啟將導(dǎo)致停機(jī)(至少的應(yīng)用程序的啟動(dòng)時(shí)間，例如 30s+)，從而導(dǎo)致更多錯(cuò)誤并為其他容器提供更多流量負(fù)載，導(dǎo)致更多失敗的容器，等等
Liveness Probes 與外部依賴相結(jié)合是導(dǎo)致級(jí)聯(lián)故障的最壞情況：?jiǎn)蝹€(gè)環(huán)境的小問題將重新啟動(dòng)所有容器。
- 如果使用 LivenessProbe，請(qǐng)不要為L(zhǎng)ivenessProbe和ReadinessProbe設(shè)置相同的規(guī)范
可以使用具有相同運(yùn)行狀況檢查但具有更高failureThreshold的 Liveness Probe (例如，在 3 次嘗試后標(biāo)記為未就緒，在 10 次嘗試后將 Liveness Probe 標(biāo)記為失敗)
不要使用“exec”探測(cè)器，它們存在導(dǎo)致僵尸進(jìn)程的。因?yàn)槲覀儗懙膽?yīng)用進(jìn)程很大一部分不會(huì)解決依附在主進(jìn)程上的進(jìn)程的
總結(jié)
- 為 Web 應(yīng)用程序使用ReadinessProbe來決定 Pod 何時(shí)應(yīng)接收流量
- 不正確使用Readiness/LivenessProbes可能導(dǎo)致可用性降低和級(jí)聯(lián)故障
- 對(duì)于慢啟動(dòng)的應(yīng)用，我們應(yīng)該使用StartupProbe
參考：
https://jimmysong.io/kubernetes-handbook/guide/configure-liveness-readiness-probes.html
https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html#id6
當(dāng)前題目：怎么使用Pod的Liveness和Readiness與StartupProbe
網(wǎng)頁URL：http://m.5511xx.com/article/dhdcscd.html
