簡(jiǎn)介

此文講述如何配置容器的Liveness、Readiness、Startup探針。

kubelet使用Liveness探測(cè)器來(lái)知道什么時(shí)候要重啟容器。例如，Liveness探測(cè)器可以捕捉到死鎖(應(yīng)用程序在運(yùn)行，但是無(wú)法繼續(xù)執(zhí)行后面的步驟)。這樣的情況下重啟容器有助于讓應(yīng)用程序在有問(wèn)題的情況下更可用。

kubelet使用Readiness探測(cè)器可以知道容器什么時(shí)候準(zhǔn)備好了并可以開(kāi)始接受請(qǐng)求流量， 當(dāng)一個(gè)Pod內(nèi)的所有容器都準(zhǔn)備好了，才能把這個(gè)Pod看作就緒了。這種信號(hào)的一個(gè)用途就是控制哪個(gè)Pod作為Service的后端。在Pod還沒(méi)有準(zhǔn)備好的時(shí)候，會(huì)從Service的負(fù)載均衡器中被剔除的。

kubelet使用Startup探測(cè)器可以知道應(yīng)用程序容器什么時(shí)候啟動(dòng)了。如果配置了這類探測(cè)器，就可以控制容器在啟動(dòng)成功后再進(jìn)行Liveness和Readiness檢查，確保這些存活、就緒探測(cè)器不會(huì)影響應(yīng)用程序的啟動(dòng)。這可以用于對(duì)慢啟動(dòng)容器進(jìn)行存活性檢測(cè)，避免它們?cè)趩?dòng)運(yùn)行之前就被殺掉。

定義一個(gè)Liveness探針

許多長(zhǎng)時(shí)間運(yùn)行的應(yīng)用程序最終會(huì)過(guò)渡到斷開(kāi)的狀態(tài)，除非重新啟動(dòng)，否則無(wú)法恢復(fù)。Kubernetes提供了Liveness探測(cè)器來(lái)發(fā)現(xiàn)并補(bǔ)救這種情況。

創(chuàng)建一個(gè)Pod，其中運(yùn)行一個(gè)基于k8s.gcr.io/busybox鏡像的容器。配置文件如下。文件名：exec-liveness.yaml

1. apiVersion: v1 
2. kind: Pod 
3. metadata: 
4. labels: 
5. test: liveness 
6. name: liveness-exec 
7. spec: 
8. containers: 
9. - name: liveness 
10. image: k8s.gcr.io/busybox 
11. args: 
12. - /bin/sh 
13. - -c 
14. - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 
15. livenessProbe: 
16.   exec: 
17.     command: 
18.     - cat 
19.     - /tmp/healthy 
20.   initialDelaySeconds: 5 
21.   periodSeconds: 5 

在配置文件中，可以看到Pod中只有一個(gè)容器。periodSeconds字段指定了kubelet應(yīng)該每5秒執(zhí)行一次存活檢測(cè)。initialDelaySeconds字段告訴kubelet在執(zhí)行第一次探針前應(yīng)該等待5秒。kubelet在容器中執(zhí)行命令cat /tmp/healthy來(lái)進(jìn)行檢測(cè)。如果命令執(zhí)行成功并且返回值為0，kubelet會(huì)認(rèn)為這個(gè)容器是健康存活的。如果這個(gè)命令返回非0值，kubelet會(huì)殺死這個(gè)容器并重新啟動(dòng)它。執(zhí)行命令如下：

1. /bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" 

這個(gè)容器生命的前30秒，/tmp/healthy文件是存在的。執(zhí)行命令cat /tmp/healthy會(huì)返回成功碼。30秒后，執(zhí)行命令cat /tmp/healthy就回返回失敗碼。

創(chuàng)建Pod：

1. # kubectl apply -f /root/k8s-example/probe/exec-liveness.yaml 

在 30 秒內(nèi)，查看Pod的事件：

1. kubectl describe pod liveness-exec 

輸出結(jié)果顯示還沒(méi)有存活探測(cè)器失敗：

1. Events:  
2. Type Reason Age From Message  
3. ---- ------ ---- ---- -------  
4. Normal Scheduled default-scheduler Successfully assigned default/liveness-exec to k8s-node04  
5. Normal Pulled 22s kubelet, k8s-node04 Container image "k8s.gcr.io/busybox" already present on machine  
6. Normal Created 22s kubelet, k8s-node04 Created container liveness  
7. Normal Started 22s kubelet, k8s-node04 Started container liveness 

30秒之后，再來(lái)看Pod的事件：

1. kubectl describe pod liveness-exec 

在輸出結(jié)果的最下面，有信息顯示存活探測(cè)器失敗了，這個(gè)容器被殺死并且被重建了。

1. Events:  
2. Type Reason Age From Message  
3. ---- ------ ---- ---- -------  
4. Normal Scheduled default-scheduler Successfully assigned default/liveness-exec to k8s-node04  
5. Normal Pulled 47s kubelet, k8s-node04 Container image "k8s.gcr.io/busybox" already present on machine  
6. Normal Created 47s kubelet, k8s-node04 Created container liveness  
7. Normal Started 47s kubelet, k8s-node04 Started container liveness  
8. Warning Unhealthy 5s (x3 over 15s) kubelet, k8s-node04 Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory 
9.  Normal Killing 5s kubelet, k8s-node04 Container liveness failed liveness probe, will be restarted 

再等另外30秒，檢查看這個(gè)容器被重啟了：

1. kubectl get pod liveness-exec 
2. NAME            READY   STATUS    RESTARTS   AGE 
3. liveness-exec   1/1     Running   2          3m10s 

再查看Pod資源詳情：

1. kubectl describe pod liveness-exec 

輸出結(jié)果如下，容器重啟成功。

1. Events:  
2. Type Reason Age From Message  
3. ---- ------ ---- ---- -------  
4. Normal Scheduled default-scheduler Successfully assigned default/liveness-exec to k8s-node04  
5. Warning Unhealthy 35s (x6 over 2m) kubelet, k8s-node04 Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory  
6. Normal Killing 35s (x2 over 110s) kubelet, k8s-node04 Container liveness failed liveness probe, will be restarted  
7. Normal Pulled 5s (x3 over 2m32s) kubelet, k8s-node04 Container image "k8s.gcr.io/busybox" already present on machine  
8. Normal Created 5s (x3 over 2m32s) kubelet, k8s-node04 Created container liveness  
9. Normal Started 5s (x3 over 2m32s) kubelet, k8s-node04 Started container liveness 

定義一個(gè)存活態(tài)HTTP請(qǐng)求接口

另外一種類型的Liveness探測(cè)方式是使用HTTP GET請(qǐng)求。下面是一個(gè)Pod的配置文件，其中運(yùn)行一個(gè)基于k8s.gcr.io/liveness鏡像的容器。

創(chuàng)建Pod：

1. apiVersion: v1 
2. kind: Pod 
3. metadata: 
4. labels: 
5. test: liveness 
6. name: liveness-http 
7. spec: 
8. containers: 
9. - name: liveness 
10. image: k8s.gcr.io/liveness 
11. args: 
12. - /server 
13. livenessProbe: 
14.   httpGet: 
15.     path: /healthz 
16.     port: 8080 
17.     httpHeaders: 
18.     - name: X-Custom-Header 
19.       value: Awesome 
20.   initialDelaySeconds: 3 
21.   periodSeconds: 3 

配置文件中，Pod中只有一個(gè)容器。periodSeconds字段指定了kubelet每隔3秒執(zhí)行一次檢測(cè)。initialDelaySeconds字段告訴kubelet在執(zhí)行第一次探測(cè)前應(yīng)該等待3秒。kubelet 會(huì)向容器內(nèi)運(yùn)行的服務(wù)(服務(wù)會(huì)監(jiān)聽(tīng) 8080 端口)發(fā)送一個(gè) HTTP GET 請(qǐng)求來(lái)執(zhí)行探測(cè)。如果服務(wù)上/healthz路徑下的處理程序返回成功碼。則kubelet認(rèn)為容器是健康存活的。如果處理程序返回失敗碼，則kubelet會(huì)殺死這個(gè)容器并且重新啟動(dòng)它。

任何大于或等于200并且小于400的返回碼標(biāo)示成功，其它返回碼都標(biāo)示失敗。

可以在這里看到服務(wù)的源碼：https://github.com/kubernetes/ ... er.go

容器存活的最開(kāi)始10秒中，/healthz處理程序返回一個(gè)200的狀態(tài)碼。之后處理程序返回500的狀態(tài)碼。

1. http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { 
2. duration := time.Now().Sub(started) 
3. if duration.Seconds() > 10 { 
4.     w.WriteHeader(500) 
5.     w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds()))) 
6. } else { 
7.     w.WriteHeader(200) 
8.     w.Write([]byte("ok")) 
9. } 
10. }) 

kubelet在容器啟動(dòng)之后3秒開(kāi)始執(zhí)行健康檢測(cè)。所以前幾次健康檢查都是成功的。但是10秒之后，健康檢查會(huì)失敗，并且kubelet會(huì)殺死容器再重新啟動(dòng)容器。

1. # kubectl apply -f /root/k8s-example/probe/http-liveness.yaml 

10秒之后，通過(guò)看Pod事件來(lái)檢測(cè)存活探測(cè)器已經(jīng)失敗了并且容器被重新啟動(dòng)了。

1. Events:  
2. Type Reason Age From Message  
3. ---- ------ ---- ---- -------  
4. Normal Scheduled default-scheduler Successfully assigned default/liveness-http to k8s-node01  
5. Normal Pulled 17s kubelet, k8s-node01 Container image "k8s.gcr.io/liveness" already present on machine  
6. Normal Created 17s kubelet, k8s-node01 Created container liveness  
7. Normal Started 16s kubelet, k8s-node01 Started container liveness  
8. Warning Unhealthy 1s (x2 over 4s) kubelet, k8s-node01 Liveness probe failed: HTTP probe failed with statuscode: 500 

定義TCP的存活探測(cè)

第三種類型的liveness探測(cè)是使用TCP套接字。通過(guò)配置，kubelet會(huì)嘗試在指定端口和容器建立套接字鏈接。如果能建立鏈接，這個(gè)容器就被看作是健康的，如果不能則這個(gè)容器就被看作是有問(wèn)題的。

創(chuàng)建一個(gè)Pod。文件名：tcp-liveness-readiness.yaml

1. apiVersion: v1 
2. kind: Pod 
3. metadata: 
4. name: goproxy 
5. labels: 
6. app: goproxy 
7. spec: 
8. containers: 
9. - name: goproxy 
10. image: k8s.gcr.io/goproxy:0.1 
11. ports: 
12. - containerPort: 8080 
13. readinessProbe: 
14.   tcpSocket: 
15.     port: 8080 
16.   initialDelaySeconds: 5 
17.   periodSeconds: 10 
18. livenessProbe: 
19.   tcpSocket: 
20.     port: 8080 
21.   initialDelaySeconds: 15 
22.   periodSeconds: 20 

TCP檢測(cè)的配置和HTTP檢測(cè)非常相似。下面這個(gè)例子同時(shí)使用就緒和存活探測(cè)器。kubelet會(huì)在容器啟動(dòng)5秒后發(fā)送第一個(gè)就緒探測(cè)。這會(huì)嘗試連接goproxy容器的8080端口。如果探測(cè)成功，這個(gè)Pod會(huì)被標(biāo)記為就緒狀態(tài)，kubelet將繼續(xù)每隔10秒運(yùn)行一次檢測(cè)。

除了readiness探測(cè)，這個(gè)配置包括了一個(gè)Liveness探測(cè)。kubelet會(huì)在容器啟動(dòng)15秒后進(jìn)行第一次Liveness探測(cè)。就像Readiness探測(cè)一樣，會(huì)嘗試連接goproxy容器的8080端口。如果存活探測(cè)失敗，這個(gè)容器會(huì)被重新啟動(dòng)。

1. # kubectl apply -f /root/k8s-example/probe/tcp-liveness-readiness.yaml 

15秒之后，通過(guò)看Pod事件來(lái)檢測(cè)存活探測(cè)器：

1. # kubectl describe pod goproxy 

使用命名端口：

對(duì)于HTTP或者TCP存活檢測(cè)可以使用命名的容器端口。

1. ports: 
2. - name: liveness-port 
3. containerPort: 8080 
4. hostPort: 8080 
5. ? 
6. livenessProbe: 
7. httpGet: 
8. path: /healthz 
9. port: liveness-port 

使用Startup探測(cè)器保護(hù)慢啟動(dòng)容器

有時(shí)候，會(huì)有一些現(xiàn)有的應(yīng)用程序在啟動(dòng)時(shí)需要較多的初始化時(shí)間。要不影響對(duì)引起探測(cè)死鎖的快速響應(yīng)，這種情況下，設(shè)置Liveness探測(cè)參數(shù)是要技巧的。技巧就是使用一個(gè)命令來(lái)設(shè)置Startup探測(cè)，針對(duì)HTTP或者TCP檢測(cè)，可以通過(guò)設(shè)置failureThreshold * periodSeconds參數(shù)來(lái)保證有足夠長(zhǎng)的時(shí)間應(yīng)對(duì)糟糕情況下的啟動(dòng)時(shí)間。

所以，前面的例子就變成了：

1. ports: 
2. - name: liveness-port 
3. containerPort: 8080 
4. hostPort: 8080 
5. ? 
6. livenessProbe: 
7. httpGet: 
8. path: /healthz 
9. port: liveness-port 
10. failureThreshold: 1 
11. periodSeconds: 10 
12. ? 
13. startupProbe: 
14. httpGet: 
15. path: /healthz 
16. port: liveness-port 
17. failureThreshold: 30 
18. periodSeconds: 10 

幸虧有Startup探測(cè)，應(yīng)用程序?qū)?huì)有最多5分鐘(30*10=300s)的時(shí)間來(lái)完成它的啟動(dòng)。 一旦Startup探測(cè)成功一次，存活探測(cè)任務(wù)就會(huì)接管對(duì)容器的探測(cè)，對(duì)容器死鎖可以快速響應(yīng)。 如果Startup探測(cè)一直沒(méi)有成功，容器會(huì)在300秒后被殺死，并且根據(jù)restartPolicy來(lái)設(shè)置Pod狀態(tài)。

定義Readliness探測(cè)器

有時(shí)候，應(yīng)用程序會(huì)暫時(shí)性的不能提供通信服務(wù)。例如，應(yīng)用程序在啟動(dòng)時(shí)可能需要加載很大的數(shù)據(jù)或配置文件，或是啟動(dòng)后要依賴等待外部服務(wù)。在這種情況下，既不想殺死應(yīng)用程序，也不想給它發(fā)送請(qǐng)求。Kubernetes提供了就緒探測(cè)器來(lái)發(fā)現(xiàn)并緩解這些情況。容器所在Pod上報(bào)還未就緒的信息，并且不接受通過(guò)Kubernetes Service的流量。

注意：就緒探測(cè)器在容器的整個(gè)生命周期中保持運(yùn)行狀態(tài)。

就緒探測(cè)器的配置和存活探測(cè)器的配置相似。唯一區(qū)別就是要使用readinessProbe字段，而不是LivenessProbe字段。

1. readinessProbe: 
2. exec: 
3. command: 
4. - cat 
5. - /tmp/healthy 
6. initialDelaySeconds: 5 
7. periodSeconds: 5 

HTTP和TCP的Readliness探測(cè)器配置也和Liveness探測(cè)器的配置一樣的。

Readliness和Liveness探測(cè)可以在同一個(gè)容器上并行使用。兩者都用可以確保流量不會(huì)發(fā)給還沒(méi)有準(zhǔn)備好的容器，并且容器會(huì)在它們失敗的時(shí)候被重新啟動(dòng)。

配置探測(cè)器

探測(cè)器有很多配置字段，可以使用這些字段精確的控制存活和就緒檢測(cè)的行為：

• initialDelaySeconds：容器啟動(dòng)后要等待多少秒后存活和就緒探測(cè)器才被初始化，默認(rèn)是0秒，最小值是0。
• periodSeconds：執(zhí)行探測(cè)的時(shí)間間隔(單位是秒)。默認(rèn)是10秒。最小值是1。
• timeoutSeconds：探測(cè)的超時(shí)后等待多少秒。默認(rèn)值是1秒。最小值是1。
• successThreshold：探測(cè)器在失敗后，被視為成功的最小連續(xù)成功數(shù)。默認(rèn)值是1。存活探測(cè)的這個(gè)值必須是1。最小值是1。
• failureThreshold：當(dāng)Pod啟動(dòng)了并且探測(cè)到失敗，Kubernetes的重試次數(shù)。存活探測(cè)情況下的放棄就意味著重新啟動(dòng)容器。就緒探測(cè)情況下的放棄Pod會(huì)被打上未就緒的標(biāo)簽。默認(rèn)值是3。最小值是1。

HTTP探測(cè)器可以在httpGet上配置額外的字段：

• host：連接使用的主機(jī)名，默認(rèn)是Pod的IP。也可以在HTTP頭中設(shè)置“Host”來(lái)代替。
• scheme：用于設(shè)置連接主機(jī)的方式(HTTP還是HTTPS)。默認(rèn)是HTTP。
• path：訪問(wèn)HTTP服務(wù)的路徑。
• httpHeaders：請(qǐng)求中自定義的HTTP頭。HTTP頭字段允許重復(fù)。
• port：訪問(wèn)容器的端口號(hào)或者端口名。如果數(shù)字必須在1 ～ 65535之間。

對(duì)于HTTP探測(cè)，kubelet發(fā)送一個(gè)HTTP請(qǐng)求到指定的路徑和端口來(lái)執(zhí)行檢測(cè)。除非httpGet中的host字段設(shè)置了，否則kubelet默認(rèn)是給Pod的IP地址發(fā)送探測(cè)。如果scheme字段設(shè)置為了HTTPS，kubelet會(huì)跳過(guò)證書(shū)驗(yàn)證發(fā)送HTTPS請(qǐng)求。大多數(shù)情況下，不需要設(shè)置host字段。這里有個(gè)需要設(shè)置host字段的場(chǎng)景，假設(shè)容器監(jiān)聽(tīng)127.0.0.1，并且Pod的hostNetwork字段設(shè)置為了true。那么httpGet中的host字段應(yīng)該設(shè)置為127.0.0.1。可能更常見(jiàn)的情況是如果Pod依賴虛擬主機(jī)，你不應(yīng)該設(shè)置host字段，而是應(yīng)該在httpHeaders中設(shè)置Host。

對(duì)于一次探測(cè)，kubelet在節(jié)點(diǎn)上(不是在Pod里面)建立探測(cè)連接，這意味著你不能在host參數(shù)上配置service name，因?yàn)閗ubelet不能解析service name。

原文地址：https://juejin.cn/post/6993457394827132964