kubernetes Pod 的生命周期（Readiness and liveness and startupProbe）

容器探針

為什么要使用readiness and liveness？

因?yàn)閗8s中采用大量的異步機(jī)制、以及多種對(duì)象關(guān)系設(shè)計(jì)上的解耦，當(dāng)應(yīng)用實(shí)例數(shù) 增加/刪除、或者應(yīng)用版本發(fā)生變化觸發(fā)滾動(dòng)升級(jí)時(shí)，系統(tǒng)并不能保證應(yīng)用相關(guān)的service、ingress配置總是及時(shí)能完成刷新。在一些情況下，往往只是新的Pod完成自身初始化，系統(tǒng)尚未完成EndPoint、負(fù)載均衡器等外部可達(dá)的訪問(wèn)信息刷新，老得Pod就立即被刪除，最終造成服務(wù)短暫的額不可用，這對(duì)于生產(chǎn)來(lái)說(shuō)是不可接受的，所以這個(gè)時(shí)候存活探針（Readiness）就登場(chǎng)了

10年積累的成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有德清免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

啟動(dòng)探針（startup Probe）

有時(shí)候，服務(wù)啟動(dòng)之后并不一定能夠立馬使用，我們以前常做的就是使用就緒探針設(shè)置initialDelay(容器啟動(dòng)后多少s開(kāi)始探測(cè))值，來(lái)判斷服務(wù)是否存活，大概設(shè)置如下

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 1
  initialDelay：10
  periodSeconds: 10

但是這個(gè)時(shí)候會(huì)出現(xiàn)這么一個(gè)情況，如果我們的服務(wù)A啟動(dòng)需要60s ，如果采用上面探針的會(huì)，這個(gè)pod就陷入死循環(huán)了，因?yàn)閱?dòng)之后經(jīng)過(guò)10s探測(cè)發(fā)現(xiàn)不正常就會(huì)更具重啟策略進(jìn)行重啟Pod，一直進(jìn)入死循環(huán)。那聰明的你肯定能猜到我們調(diào)整下initialDelay的值不就好了嗎？ 但是你能保證每個(gè)服務(wù)你都知道啟動(dòng)需要多少s 能好嗎？
聰明的您肯定又想到了 哪我們可以調(diào)整下failureThreshold的值就好了，但是應(yīng)該調(diào)整為多大呢？如果我們?cè)O(shè)置成

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 5
  initialDelay：10
  periodSeconds: 10

如果設(shè)置成這樣，第一次pod 是能正常啟動(dòng)了，但是我們到后面探測(cè)的話需要（5*10s=50s）我們才能發(fā)現(xiàn)我們的服務(wù)不可用。這在生產(chǎn)中是不允許發(fā)生的，所以我們采用startupProbe使用和livenessProbe一樣的探針來(lái)判斷服務(wù)是否啟動(dòng)成功了

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 1
  initialDelay：10
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 10
  initialDelay：10
  periodSeconds: 10

我們這只成這樣的話，只要服務(wù)在1010=100s內(nèi)任何時(shí)候啟動(dòng)來(lái)都行，探針探測(cè)成功后就交給livenessProbe進(jìn)行繼續(xù)探測(cè)了，當(dāng)我們發(fā)現(xiàn)問(wèn)題的時(shí)候110=10 在10s內(nèi)就能發(fā)現(xiàn)問(wèn)題，并及時(shí)作出響應(yīng)。

服務(wù)探針(readiness probe)

檢測(cè)容器中的程序是否啟動(dòng)就緒,只有當(dāng)檢測(cè)容器中的程序啟動(dòng)成功之后,才會(huì)變成running狀態(tài),否則就是容器啟動(dòng)成功,他還是失敗的信號(hào)(因?yàn)樗锩娴姆?wù)沒(méi)有探測(cè)成功)

存活探針(liveness Probe)(是否運(yùn)行)

檢測(cè)容器是否在運(yùn)行,只是單純的檢測(cè)容器是否存活,并不會(huì)檢測(cè)里面的服務(wù)是否正常.如果探針檢測(cè)到失敗,他將啟動(dòng)他的重啟策略.

三種類型的處理程序:

• 1, ExecAction: 通過(guò)自定義命令來(lái)進(jìn)行探測(cè),當(dāng)返回值是0的時(shí)候說(shuō)明存活,當(dāng)返回值非0的時(shí)候表示不存活.
• 2, TCPSocketAction: 對(duì)容器上的端口進(jìn)行tcp檢查,如果端口是打開(kāi)的,則說(shuō)明存活
• 3, HTTPGetAction: 對(duì)指定端口和url地址執(zhí)行HTTP Get請(qǐng)求,如果響應(yīng)的狀態(tài)碼大于等于200且小于400,則認(rèn)為存活

每次探測(cè)都只能只能是下面三種結(jié)果:

• 1, 成功: 容器通過(guò)了測(cè)試
• 2, 失敗: 容器未通過(guò)測(cè)試
• 3, 未知: 測(cè)試失敗,因此不會(huì)采取任何動(dòng)作

探針示例:

ExecAction

# cat nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  restartPolicy: OnFailure
  containers:
  - name: nginx
    image: nginx:1.14.1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
      protocol: TCP
    - name: https
      containerPort: 443
      protocol: TCP
    livenessProbe:
      exec:
        command: ["test","-f","/usr/share/nginx/html/index.html"]
      failureThreshold: 3
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 5
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 15
      timeoutSeconds: 1

我們啟動(dòng)這個(gè)容器,測(cè)試一下服務(wù)探針.

kubectl create -f nginx.yaml

我們進(jìn)入到nginx容器里面把index這個(gè)文件刪除了,看看詳細(xì)信息

#kubectl describe pod nginx
.....
Events:
  Type     Reason     Age                From                    Message
  ----     ------     ----               ----                    -------
  Normal   Scheduled  4m24s              default-scheduler       Successfully assigned default/nginx to 192.168.1.124
  Normal   Pulling    4m23s              kubelet, 192.168.1.124  pulling image "nginx:1.14.1"
  Normal   Pulled     4m1s               kubelet, 192.168.1.124  Successfully pulled image "nginx:1.14.1"
  Warning  Unhealthy  57s                kubelet, 192.168.1.124  Readiness probe failed: HTTP probe failed with statuscode: 404
  Warning  Unhealthy  50s (x3 over 60s)  kubelet, 192.168.1.124  Liveness probe failed:
  Normal   Killing    50s                kubelet, 192.168.1.124  Killing container with id docker://nginx:Container failed liveness probe.. Container will be killed and recreated.
  Normal   Pulled     50s                kubelet, 192.168.1.124  Container image "nginx:1.14.1" already present on machine
  Normal   Created    49s (x2 over 4m)   kubelet, 192.168.1.124  Created container
  Normal   Started    49s (x2 over 4m)   kubelet, 192.168.1.124  Started container

很明顯的從事件信息里面可以看到他服務(wù)探測(cè)有一次是報(bào)錯(cuò)404的,然后立馬就執(zhí)行了重啟容器的過(guò)程

探針參數(shù)介紹:

exec: 使用自定義命令編寫探針
httpGet: 使用http訪問(wèn)的方式探測(cè)
tcpSocket: 使用tcp套接字來(lái)探測(cè)
failureThreshold: 連續(xù)失敗幾次算真正的失敗
initialDelaySeconds: 容器啟動(dòng)多少秒之后開(kāi)始探測(cè)(因?yàn)槿萜骼锩娴姆?wù)啟動(dòng)需要時(shí)間)
periodSeconds: 探測(cè)時(shí)間間隔多少秒
timeoutSeconds: 命令執(zhí)行的超時(shí)時(shí)間

HTTPGet的探針參數(shù):

1. host: 探測(cè)那個(gè)主機(jī)(URL)
2. path: 訪問(wèn)的路徑(URI)
3. port: 訪問(wèn)的端口(必須字段)
4. scheme：用于連接主機(jī)的方案（HTTP或HTTPS）。默認(rèn)為HTTP
5. httpHeaders：要在請(qǐng)求中設(shè)置的自定義標(biāo)頭。HTTP允許重復(fù)標(biāo)頭。

本文題目：kubernetesReadinessandlivenessandstartupProbe
網(wǎng)頁(yè)鏈接：http://www.ekvhdxd.cn/article20/pdjhjo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、軟件開(kāi)發(fā)、虛擬主機(jī)、品牌網(wǎng)站制作、微信小程序、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)