建站
咨詢
售后
建站咨詢
新聞中心
配置存活、就緒和啟動(dòng)探測(cè)器
這篇文章介紹如何給容器配置活躍（Liveness）、就緒（Readiness）和啟動(dòng)（Startup）探測(cè)器。
kubelet 使用存活探測(cè)器來(lái)確定什么時(shí)候要重啟容器。 例如，存活探測(cè)器可以探測(cè)到應(yīng)用死鎖（應(yīng)用程序在運(yùn)行，但是無(wú)法繼續(xù)執(zhí)行后面的步驟）情況。 重啟這種狀態(tài)下的容器有助于提高應(yīng)用的可用性，即使其中存在缺陷。
kubelet 使用就緒探測(cè)器可以知道容器何時(shí)準(zhǔn)備好接受請(qǐng)求流量，當(dāng)一個(gè) Pod 內(nèi)的所有容器都就緒時(shí)，才能認(rèn)為該 Pod 就緒。 這種信號(hào)的一個(gè)用途就是控制哪個(gè) Pod 作為 Service 的后端。 若 Pod 尚未就緒，會(huì)被從 Service 的負(fù)載均衡器中剔除。
kubelet 使用啟動(dòng)探測(cè)器來(lái)了解應(yīng)用容器何時(shí)啟動(dòng)。 如果配置了這類探測(cè)器，你就可以控制容器在啟動(dòng)成功后再進(jìn)行存活性和就緒態(tài)檢查， 確保這些存活、就緒探測(cè)器不會(huì)影響應(yīng)用的啟動(dòng)。 啟動(dòng)探測(cè)器可以用于對(duì)慢啟動(dòng)容器進(jìn)行存活性檢測(cè)，避免它們?cè)趩?dòng)運(yùn)行之前就被殺掉。
在開(kāi)始之前
你必須擁有一個(gè) Kubernetes 的集群，同時(shí)你的 Kubernetes 集群必須帶有 kubectl 命令行工具。 建議在至少有兩個(gè)節(jié)點(diǎn)的集群上運(yùn)行本教程，且這些節(jié)點(diǎn)不作為控制平面主機(jī)。 如果你還沒(méi)有集群，你可以通過(guò) Minikube 構(gòu)建一個(gè)你自己的集群，或者你可以使用下面任意一個(gè) Kubernetes 工具構(gòu)建：
- Katacoda
- 玩轉(zhuǎn) Kubernetes
定義存活命令
許多長(zhǎng)時(shí)間運(yùn)行的應(yīng)用最終會(huì)進(jìn)入損壞狀態(tài)，除非重新啟動(dòng)，否則無(wú)法被恢復(fù)。 Kubernetes 提供了存活探測(cè)器來(lái)發(fā)現(xiàn)并處理這種情況。
在本練習(xí)中，你會(huì)創(chuàng)建一個(gè) Pod，其中運(yùn)行一個(gè)基于 ?K8S.gcr.io/busybox? 鏡像的容器。 下面是這個(gè) Pod 的配置文件。
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: k8s.gcr.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
在這個(gè)配置文件中，可以看到 Pod 中只有一個(gè) ?Container?。 ?periodSeconds ?字段指定了 kubelet 應(yīng)該每 5 秒執(zhí)行一次存活探測(cè)。 ?initialDelaySeconds ?字段告訴 kubelet 在執(zhí)行第一次探測(cè)前應(yīng)該等待 5 秒。 kubelet 在容器內(nèi)執(zhí)行命令 ?cat /tmp/healthy? 來(lái)進(jìn)行探測(cè)。 如果命令執(zhí)行成功并且返回值為 0，kubelet 就會(huì)認(rèn)為這個(gè)容器是健康存活的。 如果這個(gè)命令返回非 0 值，kubelet 會(huì)殺死這個(gè)容器并重新啟動(dòng)它。
當(dāng)容器啟動(dòng)時(shí)，執(zhí)行如下的命令：
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"
這個(gè)容器生命的前 30 秒，?/tmp/healthy? 文件是存在的。 所以在這最開(kāi)始的 30 秒內(nèi)，執(zhí)行命令 ?cat /tmp/healthy? 會(huì)返回成功代碼。 30 秒之后，執(zhí)行命令 ?cat /tmp/healthy? 就會(huì)返回失敗代碼。
創(chuàng)建 Pod：
kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
在 30 秒內(nèi)，查看 Pod 的事件：
kubectl describe pod liveness-exec
輸出結(jié)果表明還沒(méi)有存活探測(cè)器失?。?/p>
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 "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/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 86849c15382e35 秒之后，再來(lái)看 Pod 的事件：
kubectl describe pod liveness-exec
在輸出結(jié)果的最下面，有信息顯示存活探測(cè)器失敗了，這個(gè)容器被殺死并且被重建了。
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 "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/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)這個(gè)容器被重啟了：
kubectl get pod liveness-exec
輸出結(jié)果顯示 ?RESTARTS ?的值增加了 1。
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 1m定義一個(gè)存活態(tài) HTTP 請(qǐng)求接口
另外一種類型的存活探測(cè)方式是使用 HTTP GET 請(qǐng)求。 下面是一個(gè) Pod 的配置文件，其中運(yùn)行一個(gè)基于 ?k8s.gcr.io/liveness? 鏡像的容器。
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: k8s.gcr.io/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
在這個(gè)配置文件中，你可以看到 Pod 也只有一個(gè)容器。 ?periodSeconds ?字段指定了 kubelet 每隔 3 秒執(zhí)行一次存活探測(cè)。 ?initialDelaySeconds ?字段告訴 kubelet 在執(zhí)行第一次探測(cè)前應(yīng)該等待 3 秒。 kubelet 會(huì)向容器內(nèi)運(yùn)行的服務(wù)（服務(wù)在監(jiān)聽(tīng) 8080 端口）發(fā)送一個(gè) HTTP GET 請(qǐng)求來(lái)執(zhí)行探測(cè)。 如果服務(wù)器上 ?/healthz? 路徑下的處理程序返回成功代碼，則 kubelet 認(rèn)為容器是健康存活的。 如果處理程序返回失敗代碼，則 kubelet 會(huì)殺死這個(gè)容器并將其重啟。
返回大于或等于 200 并且小于 400 的任何代碼都標(biāo)示成功，其它返回代碼都標(biāo)示失敗。
你可以訪問(wèn) server.go。 閱讀服務(wù)的源碼。 容器存活期間的最開(kāi)始 10 秒中，?/healthz? 處理程序返回 200 的狀態(tài)碼。 之后處理程序返回 500 的狀態(tài)碼。
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"))
}
})kubelet 在容器啟動(dòng)之后 3 秒開(kāi)始執(zhí)行健康檢測(cè)。所以前幾次健康檢查都是成功的。 但是 10 秒之后，健康檢查會(huì)失敗，并且 kubelet 會(huì)殺死容器再重新啟動(dòng)容器。
創(chuàng)建一個(gè) Pod 來(lái)測(cè)試 HTTP 的存活檢測(cè)：
kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
10 秒之后，通過(guò)查看 Pod 事件來(lái)確認(rèn)活躍探測(cè)器已經(jīng)失敗，并且容器被重新啟動(dòng)了。
kubectl describe pod liveness-http
在 1.13 之前（包括 1.13）的版本中，如果在 Pod 運(yùn)行的節(jié)點(diǎn)上設(shè)置了環(huán)境變量 ?http_proxy?（或者 ?HTTP_PROXY?），HTTP 的存活探測(cè)會(huì)使用這個(gè)代理。 在 1.13 之后的版本中，設(shè)置本地的 HTTP 代理環(huán)境變量不會(huì)影響 HTTP 的存活探測(cè)。
定義 TCP 的存活探測(cè)
第三種類型的存活探測(cè)是使用 TCP 套接字。 使用這種配置時(shí)，kubelet 會(huì)嘗試在指定端口和容器建立套接字鏈接。 如果能建立連接，這個(gè)容器就被看作是健康的，如果不能則這個(gè)容器就被看作是有問(wèn)題的。
apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
如你所見(jiàn)，TCP 檢測(cè)的配置和 HTTP 檢測(cè)非常相似。 下面這個(gè)例子同時(shí)使用就緒和存活探測(cè)器。kubelet 會(huì)在容器啟動(dòng) 5 秒后發(fā)送第一個(gè)就緒探測(cè)。 探測(cè)器會(huì)嘗試連接 ?goproxy ?容器的 8080 端口。 如果探測(cè)成功，這個(gè) Pod 會(huì)被標(biāo)記為就緒狀態(tài)，kubelet 將繼續(xù)每隔 10 秒運(yùn)行一次檢測(cè)。
除了就緒探測(cè)，這個(gè)配置包括了一個(gè)存活探測(cè)。 kubelet 會(huì)在容器啟動(dòng) 15 秒后進(jìn)行第一次存活探測(cè)。 與就緒探測(cè)類似，活躍探測(cè)器會(huì)嘗試連接 ?goproxy ?容器的 8080 端口。 如果存活探測(cè)失敗，容器會(huì)被重新啟動(dòng)。
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
15 秒之后，通過(guò)看 Pod 事件來(lái)檢測(cè)存活探測(cè)器：
kubectl describe pod goproxy
定義 gRPC 活躍探測(cè)器
FEATURE STATE: Kubernetes v1.24 [beta]
如果你的應(yīng)用實(shí)現(xiàn)了 gRPC 健康檢查協(xié)議， kubelet 可以配置為使用該協(xié)議來(lái)執(zhí)行應(yīng)用活躍性檢查。 你必須啟用 ?GRPCContainerProbe ?特性門控 才能配置依賴于 gRPC 的檢查機(jī)制。
下面是一個(gè)示例清單：
apiVersion: v1
kind: Pod
metadata:
name: etcd-with-grpc
spec:
containers:
- name: etcd
image: k8s.gcr.io/etcd:3.5.1-0
command: [ "/usr/local/bin/etcd", "--data-dir", "/var/lib/etcd", "--listen-client-urls", "http://0.0.0.0:2379", "--advertise-client-urls", "http://127.0.0.1:2379", "--log-level", "debug"]
ports:
- containerPort: 2379
livenessProbe:
grpc:
port: 2379
initialDelaySeconds: 10
要使用 gRPC 探測(cè)器，必須配置 ?port ?屬性。如果健康狀態(tài)端點(diǎn)配置在非默認(rèn)服務(wù)之上， 你還必須設(shè)置 ?service ?屬性。
Note:
與 HTTP 和 TCP 探測(cè)器不同，gRPC 探測(cè)不能使用命名端口或定制主機(jī)。
配置問(wèn)題（例如：錯(cuò)誤的 ?port ?和 ?service?、未實(shí)現(xiàn)健康檢查協(xié)議） 都被認(rèn)作是探測(cè)失敗，這一點(diǎn)與 HTTP 和 TCP 探測(cè)器類似。
kubectl apply -f https://k8s.io/examples/pods/probe/grpc-liveness.yaml
15 秒鐘之后，查看 Pod 事件確認(rèn)活躍性檢查并未失?。?/p>
kubectl describe pod etcd-with-grpc
在 Kubernetes 1.23 之前，gRPC 健康探測(cè)通常使用 grpc-health-probe 來(lái)實(shí)現(xiàn)。 內(nèi)置的 gRPC 探測(cè)器行為與 ?grpc-health-probe? 所實(shí)現(xiàn)的行為類似。 從 ?grpc-health-probe? 遷移到內(nèi)置探測(cè)器時(shí)，請(qǐng)注意以下差異：
- 內(nèi)置探測(cè)器運(yùn)行時(shí)針對(duì)的是 Pod 的 IP 地址，不像 ?
grpc-health-probe? 那樣通常針對(duì) ?127.0.0.1? 執(zhí)行探測(cè)； 請(qǐng)一定配置你的 gRPC 端點(diǎn)使之監(jiān)聽(tīng)于 Pod 的 IP 地址之上。 - 內(nèi)置探測(cè)器不支持任何身份認(rèn)證參數(shù)（例如 ?
tls?）。 - 對(duì)于內(nèi)置的探測(cè)器而言，不存在錯(cuò)誤代碼。所有錯(cuò)誤都被視作探測(cè)失敗。
- 如果 ?
ExecProbeTimeout?特性門控被設(shè)置為 ?false?，則 ?grpc-health-probe? 不會(huì)考慮 ?timeoutSeconds?設(shè)置狀態(tài)（默認(rèn)值為 1s）， 而內(nèi)置探測(cè)器則會(huì)在超時(shí)時(shí)返回失敗。
使用命名端口
對(duì)于 HTTP 或者 TCP 存活檢測(cè)可以使用命名的 ContainerPort。
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port使用啟動(dòng)探測(cè)器保護(hù)慢啟動(dòng)容器
有時(shí)候，會(huì)有一些現(xiàn)有的應(yīng)用在啟動(dòng)時(shí)需要較長(zhǎng)的初始化時(shí)間。 要這種情況下，若要不影響對(duì)死鎖作出快速響應(yīng)的探測(cè)，設(shè)置存活探測(cè)參數(shù)是要技巧的。 技巧就是使用相同的命令來(lái)設(shè)置啟動(dòng)探測(cè)，針對(duì) HTTP 或 TCP 檢測(cè)，可以通過(guò)將 ?failureThreshold * periodSeconds? 參數(shù)設(shè)置為足夠長(zhǎng)的時(shí)間來(lái)應(yīng)對(duì)糟糕情況下的啟動(dòng)時(shí)間。
這樣，前面的例子就變成了：
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 10
startupProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 30
periodSeconds: 10幸虧有啟動(dòng)探測(cè)，應(yīng)用程序?qū)?huì)有最多 5 分鐘（30 * 10 = 300s）的時(shí)間來(lái)完成其啟動(dòng)過(guò)程。 一旦啟動(dòng)探測(cè)成功一次，存活探測(cè)任務(wù)就會(huì)接管對(duì)容器的探測(cè)，對(duì)容器死鎖作出快速響應(yīng)。 如果啟動(dòng)探測(cè)一直沒(méi)有成功，容器會(huì)在 300 秒后被殺死，并且根據(jù) ?restartPolicy ?來(lái) 執(zhí)行進(jìn)一步處置。
定義就緒探測(cè)器
有時(shí)候，應(yīng)用會(huì)暫時(shí)性地?zé)o法為請(qǐng)求提供服務(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 的流量。
Note: 就緒探測(cè)器在容器的整個(gè)生命周期中保持運(yùn)行狀態(tài)。
Caution: 活躍探測(cè)器 不等待 就緒性探測(cè)器成功。 如果要在執(zhí)行活躍探測(cè)器之前等待，應(yīng)該使用 ?
initialDelaySeconds?或 ?startupProbe?。
就緒探測(cè)器的配置和存活探測(cè)器的配置相似。 唯一區(qū)別就是要使用 ?readinessProbe ?字段，而不是 ?livenessProbe ?字段。
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5HTTP 和 TCP 的就緒探測(cè)器配置也和存活探測(cè)器的配置完全相同。
就緒和存活探測(cè)可以在同一個(gè)容器上并行使用。 兩者都可以確保流量不會(huì)發(fā)給還未就緒的容器，當(dāng)這些探測(cè)失敗時(shí)容器會(huì)被重新啟動(dòng)。
配置探測(cè)器
Probe 有很多配置字段，可以使用這些字段精確地控制活躍和就緒檢測(cè)的行為：
- ?
initialDelaySeconds?：容器啟動(dòng)后要等待多少秒后才啟動(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。 存活和啟動(dòng)探測(cè)的這個(gè)值必須是 1。最小值是 1。 - ?
failureThreshold?：當(dāng)探測(cè)失敗時(shí)，Kubernetes 的重試次數(shù)。 對(duì)存活探測(cè)而言，放棄就意味著重新啟動(dòng)容器。 對(duì)就緒探測(cè)而言，放棄意味著 Pod 會(huì)被打上未就緒的標(biāo)簽。默認(rèn)值是 3。最小值是 1。
Note:
在 Kubernetes 1.20 版本之前，?
exec?探針會(huì)忽略 ?
timeoutSeconds?： 探針會(huì)無(wú)限期地持續(xù)運(yùn)行，甚至可能超過(guò)所配置的限期，直到返回結(jié)果為止。
這一缺陷在 Kubernetes v1.20 版本中得到修復(fù)。你可能一直依賴于之前錯(cuò)誤的探測(cè)行為， 甚至都沒(méi)有覺(jué)察到這一問(wèn)題的存在，因?yàn)槟J(rèn)的超時(shí)值是 1 秒鐘。 作為集群管理員，你可以在所有的 kubelet 上禁用 ?
ExecProbeTimeout?特性門控 （將其設(shè)置為 ?
false?），從而恢復(fù)之前版本中的運(yùn)行行為。之后當(dāng)集群中所有的 exec 探針都設(shè)置了 ?
timeoutSeconds?參數(shù)后，移除此標(biāo)志重載。 如果你有 Pod 受到此默認(rèn) 1 秒鐘超時(shí)值的影響，你應(yīng)該更新這些 Pod 對(duì)應(yīng)的探針的超時(shí)值， 這樣才能為最終去除該特性門控做好準(zhǔn)備。
當(dāng)此缺陷被修復(fù)之后，在使用 ?
dockershim?容器運(yùn)行時(shí)的 Kubernetes 1.20+ 版本中，對(duì)于 exec 探針而言，容器中的進(jìn)程可能會(huì)因?yàn)槌瑫r(shí)值的設(shè)置保持持續(xù)運(yùn)行， 即使探針?lè)祷亓耸顟B(tài)。
Caution:
如果就緒態(tài)探針的實(shí)現(xiàn)不正確，可能會(huì)導(dǎo)致容器中進(jìn)程的數(shù)量不斷上升。 如果不對(duì)其采取措施，很可能導(dǎo)致資源枯竭的狀況。
HTTP 探測(cè)
HTTP Probes 允許針對(duì) ?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ù)的路徑。默認(rèn)值為 "/"。 - ?
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ì) HTTP 探針，kubelet 除了必需的 ?Host ?頭部之外還發(fā)送兩個(gè)請(qǐng)求頭部字段： ?User-Agent? 和 ?Accept?。這些頭部的默認(rèn)值分別是 ?kube-probe/{{ skew latestVersion >}}? （其中 1.24 是 kubelet 的版本號(hào)）和 ?*/*?。
你可以通過(guò)為探測(cè)設(shè)置 ?.httpHeaders? 來(lái)重載默認(rèn)的頭部字段值；例如：
livenessProbe:
httpGet:
httpHeaders:
- name: Accept
value: application/json
startupProbe:
httpGet:
httpHeaders:
- name: User-Agent
value: MyUserAgent你也可以通過(guò)將這些頭部字段定義為空值，從請(qǐng)求中去掉這些頭部字段。
livenessProbe:
httpGet:
httpHeaders:
- name: Accept
value: ""
startupProbe:
httpGet:
httpHeaders:
- name: User-Agent
value: ""TCP 探測(cè)
對(duì)于 TCP 探測(cè)而言，kubelet 在節(jié)點(diǎn)上（不是在 Pod 里面）發(fā)起探測(cè)連接， 這意味著你不能在 ?host ?參數(shù)上配置服務(wù)名稱，因?yàn)?nbsp;kubelet 不能解析服務(wù)名稱。
探測(cè)器層面的 terminationGracePeriodSeconds
FEATURE STATE: Kubernetes v1.22 [beta]
在 1.21 發(fā)行版之前，Pod 層面的 ?terminationGracePeriodSeconds ?被用來(lái)終止活躍探測(cè)或啟動(dòng)探測(cè)失敗的容器。 這一行為上的關(guān)聯(lián)不是我們想要的，可能導(dǎo)致 Pod 層面設(shè)置了 ?terminationGracePeriodSeconds ?時(shí)容器要花非常長(zhǎng)的時(shí)間才能重新啟動(dòng)。
在 1.21 及更高版本中，當(dāng)特性門控 ?ProbeTerminationGracePeriod ?被啟用時(shí)， 用戶可以指定一個(gè)探測(cè)器層面的 ?terminationGracePeriodSeconds ?作為探測(cè)器規(guī)約的一部分。 當(dāng)該特性門控被啟用，并且 Pod 層面和探測(cè)器層面的 ?terminationGracePeriodSeconds ?都已設(shè)置，kubelet 將使用探測(cè)器層面設(shè)置的值。
在 Kubernetes 1.22 中，?ProbeTerminationGracePeriod ?特性門控只能用在 API 服務(wù)器上。 kubelet 始終遵守探針級(jí)別 ?terminationGracePeriodSeconds ?字段 （如果它存在于 Pod 上）。
如果你已經(jīng)為現(xiàn)有 Pod 設(shè)置了 ?terminationGracePeriodSeconds ?字段并且不再希望使用針對(duì)每個(gè)探針的終止寬限期，則必須刪除現(xiàn)有的這類 Pod。
當(dāng)你（或控制平面或某些其他組件）創(chuàng)建替換 Pod，并且特性門控 ?ProbeTerminationGracePeriod ?被禁用時(shí)，API 服務(wù)器會(huì)忽略 Pod 級(jí)別的 ?terminationGracePeriodSeconds ?字段設(shè)置， 即使 Pod 或 Pod 模板指定了它。
例如:
spec:
terminationGracePeriodSeconds: 3600 # pod-level
containers:
- name: test
image: ...
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 60
# Override pod-level terminationGracePeriodSeconds #
terminationGracePeriodSeconds: 60探測(cè)器層面的 ?terminationGracePeriodSeconds ?不能用于就緒態(tài)探針。 這一設(shè)置將被 API 服務(wù)器拒絕。
新聞標(biāo)題：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes 配置存活、就緒和啟動(dòng)探測(cè)器
網(wǎng)頁(yè)地址：http://www.5511xx.com/article/dposdsj.html
