kubernetesReadinessandlivenessandstartupProbe

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

容器探針

為什么要使用readiness and liveness？

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

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

啟動探針（startup Probe）

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

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

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

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

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

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)任何時候啟動來都行，探針探測成功后就交給livenessProbe進行繼續(xù)探測了，當(dāng)我們發(fā)現(xiàn)問題的時候110=10 在10s內(nèi)就能發(fā)現(xiàn)問題，并及時作出響應(yīng)。

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

檢測容器中的程序是否啟動就緒,只有當(dāng)檢測容器中的程序啟動成功之后,才會變成running狀態(tài),否則就是容器啟動成功,他還是失敗的信號(因為他里面的服務(wù)沒有探測成功)

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

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

三種類型的處理程序:

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

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

  • 1, 成功: 容器通過了測試
  • 2, 失敗: 容器未通過測試
  • 3, 未知: 測試失敗,因此不會采取任何動作

探針示例:

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

我們啟動這個容器,測試一下服務(wù)探針.

kubectl create -f nginx.yaml

我們進入到nginx容器里面把index這個文件刪除了,看看詳細信息

#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ù)探測有一次是報錯404的,然后立馬就執(zhí)行了重啟容器的過程

探針參數(shù)介紹:

exec: 使用自定義命令編寫探針
httpGet: 使用http訪問的方式探測
tcpSocket: 使用tcp套接字來探測
failureThreshold: 連續(xù)失敗幾次算真正的失敗
initialDelaySeconds: 容器啟動多少秒之后開始探測(因為容器里面的服務(wù)啟動需要時間)
periodSeconds: 探測時間間隔多少秒
timeoutSeconds: 命令執(zhí)行的超時時間

HTTPGet的探針參數(shù):

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

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

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

廣告

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

網(wǎng)站建設(shè)網(wǎng)站維護公司