2020 kubernetes講座（上）-CKA考試指南（九）容器探針Probe

時間：2023-06-28 01:00:01 | 來源：網(wǎng)站運營

時間：2023-06-28 01:00:01 來源：網(wǎng)站運營

2020 kubernetes講座（上）-CKA考試指南（九）容器探針Probe：

什么是探針

探針Probe是由 kubelet對容器執(zhí)行的定期診斷。要執(zhí)行診斷，kubelet 調(diào)用由容器實現(xiàn)的 Handler。有三種類型的處理程序：

• ExecAction：在容器內(nèi)執(zhí)行指定命令。如果命令退出時返回碼為 0 則認為診斷成功。
• TCPSocketAction：對指定端口上的容器的 IP 地址進行 TCP 檢查。如果端口打開，則診斷被認為是成功的。
• HTTPGetAction：對指定的端口和路徑上的容器的 IP 地址執(zhí)行 HTTP Get 請求。如果響應(yīng)的狀態(tài)碼大于等于200 且小于 400，則診斷被認為是成功的。

每次探測都將獲得以下三種結(jié)果之一：

• 成功：容器通過了診斷。
• 失敗：容器未通過診斷。
• 未知：診斷失敗，因此不會采取任何行動。

Kubelet 可以選擇是否執(zhí)行在容器上運行的三種探針執(zhí)行和做出反應(yīng)：

• livenessProbe：指示容器是否正在運行。如果存活探測失敗，則 kubelet 會殺死容器，并且容器將受到重啟策略的影響。如果容器不提供存活探針，則默認狀態(tài)為 Success。
• readinessProbe：指示容器是否準(zhǔn)備好服務(wù)請求。如果就緒探測失敗，端點控制器將從與 Pod 匹配的所有 Service 的端點中刪除該 Pod 的 IP 地址。初始延遲之前的就緒狀態(tài)默認為 Failure。如果容器不提供就緒探針，則默認狀態(tài)為 Success。
• startupProbe: 指示容器中的應(yīng)用是否已經(jīng)啟動。如果提供了啟動探測(startup probe)，則禁用所有其他探測，直到它成功為止。如果啟動探測失敗，kubelet 將殺死容器，容器服從其重啟策略進行重啟。如果容器沒有提供啟動探測，則默認狀態(tài)為成功Success。

PodSpec 中有一個 restartPolicy 字段，可能的值為 Always、OnFailure 和 Never。默認為 Always。 restartPolicy 適用于 Pod 中的所有容器。restartPolicy 僅指通過同一節(jié)點上的 kubelet 重新啟動容器。失敗的容器由 kubelet 以五分鐘為上限的指數(shù)退避延遲（10秒，20秒，40秒…）重新啟動，并在成功執(zhí)行十分鐘后重置。Pod一旦綁定到一個節(jié)點，他將永遠不會重新綁定到另一個節(jié)點。

該什么時候使用探針?

• liveness probe
  
  如果容器中的進程能夠在遇到問題或不健康的情況下自行崩潰，則不一定需要存活探針; kubelet 將根據(jù) Pod 的restartPolicy 自動執(zhí)行正確的操作。如果您希望容器在探測失敗時被殺死并重新啟動，那么請指定一個存活探針，并指定restartPolicy 為 Always 或 OnFailure。
  
  
• readiness probe
  
  如果要僅在探測成功時才開始向 Pod 發(fā)送流量，請指定就緒探針。在這種情況下，就緒探針可能與存活探針相同，但是 spec 中的就緒探針的存在意味著 Pod 將在沒有接收到任何流量的情況下啟動，并且只有在探針探測成功后才開始接收流量。 如果希望容器能夠自行維護，您可以指定一個就緒探針，該探針檢查與存活探針不同的端點。 需要注意的是，如果只想在 Pod 被刪除時能夠拒絕連接（drain request），則不一定需要使用就緒探針；在刪除 Pod 時，Pod 會自動將自身置于未完成狀態(tài)，無論就緒探針是否存在。當(dāng)?shù)却?Pod 中的容器停止時，Pod 仍處于未完成狀態(tài)。
  
  

定義探針

• 定義存活的命令（liveness）
  
  許多長時間運行的應(yīng)用程序最終會過渡到斷開的狀態(tài)，除非重新啟動，否則無法恢復(fù)。Kubernetes 提供了存活探測器來發(fā)現(xiàn)并補救這種情況。
  
  在這篇練習(xí)中，會創(chuàng)建一個 Pod，其中運行一個基于 k8s.gcr.io/busybox 鏡像的容器。下面是這個 Pod 的配置文件。
  
  apiVersion: v1kind: Podmetadata: labels: test: liveness name: liveness-execspec: containers: - name: liveness image: k8s.gcr.io/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5在這個配置文件中，可以看到 Pod 中只有一個容器。periodSeconds 字段指定了 kubelet 應(yīng)該每 5 秒執(zhí)行一次存活探測。initialDelaySeconds 字段告訴 kubelet 在執(zhí)行第一次探測前應(yīng)該等待 5 秒。kubelet 在容器內(nèi)執(zhí)行命令 cat /tmp/healthy 來進行探測。如果命令執(zhí)行成功并且返回值為 0，kubelet 就會認為這個容器是健康存活的。如果這個命令返回非 0 值，kubelet 會殺死這個容器并重新啟動它。
  
  當(dāng)容器啟動時，執(zhí)行如下的命令：
  
  /bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"這個容器生命的前 30 秒， /tmp/healthy 文件是存在的。所以在這最開始的 30 秒內(nèi)，執(zhí)行命令 cat /tmp/healthy 會返回成功碼。30 秒之后，執(zhí)行命令 cat /tmp/healthy 就會返回失敗碼。
  
  創(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é)果顯示還沒有存活探測器失?。?br>
  FirstSeen LastSeen Count From SubobjectPath Type Reason Message--------- -------- ----- ---- ------------- -------- ------ -------24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker023s 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 秒之后，再來看 Pod 的事件：
  
  $ kubectl describe pod liveness-exec在輸出結(jié)果的最下面，有信息顯示存活探測器失敗了，這個容器被殺死并且被重建了。
  
  FirstSeen LastSeen Count From SubobjectPath Type Reason Message--------- -------- ----- ---- ------------- -------- ------ -------37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker036s 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 86849c15382e2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory再等另外 30 秒，檢查看這個容器被重啟了：
  
  $ kubectl get pod liveness-exec輸出結(jié)果顯示 RESTARTS 的值增加了 1。
  
  NAME READY STATUS RESTARTS AGEliveness-exec 1/1 Running 1 1m
• 定義就緒探針readiness
  
  有時候，應(yīng)用程序會暫時性的不能提供通信服務(wù)。例如，應(yīng)用程序在啟動時可能需要加載很大的數(shù)據(jù)或配置文件，或是啟動后要依賴等待外部服務(wù)。在這種情況下，既不想殺死應(yīng)用程序，也不想給它發(fā)送請求。Kubernetes 提供了就緒探測器來發(fā)現(xiàn)并緩解這些情況。容器所在 Pod 上報還未就緒的信息，并且不接受通過 Kubernetes Service 的流量。
  
  就緒探測器的配置和存活探測器的配置相似。唯一區(qū)別就是要使用 readinessProbe 字段，而不是 livenessProbe 字段。
  
  readinessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5HTTP 和 TCP 的就緒探測器配置也和存活探測器的配置一樣的。
  
  就緒和存活探測可以在同一個容器上并行使用。兩者都用可以確保流量不會發(fā)給還沒有準(zhǔn)備好的容器，并且容器會在它們失敗的時候被重新啟動。
  
  

Probe的配置選項

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

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

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

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

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



對于一次 TCP 探測，kubelet 在節(jié)點上（不是在 Pod 里面）建立探測連接，這意味著你不能在 host 參數(shù)上配置 service name，因為 kubelet 不能解析 service name。

Pod readiness（1.14 stable）

可以把外部的回復(fù)信息或者信號注入到我們的應(yīng)用當(dāng)中，使用Pod readiness。我們需要在Pod的spec文件中定義readinessGates，并且在其中定義一些條件，供kubelet來判定pod是否就緒。



readinessGates會根據(jù)status.condition的狀態(tài)來判定，如果kubernetes不能夠在pod中找到status.conditons中的字段，而condition的默認狀態(tài)是False



例如：



kind: Pod...spec: readinessGates: - conditionType: "www.example.com/feature-1"status: conditions: - type: Ready # a built in PodCondition status: "False" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:00Z - type: "www.example.com/feature-1" # an extra PodCondition status: "False" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:00Z containerStatuses: - containerID: docker://abcd... ready: true...

為了方便大家學(xué)習(xí)，請大家加我的微信，我會把大家加到微信群（微信群的二維碼會經(jīng)常變）和qq群821119334，問題答案云原生技術(shù)課堂，有問題可以一起討論

• 個人微信

640.jpeg

• 騰訊課堂640-20200506145837072.jpeg
  
  
• 微信公眾號640-20200506145842007.jpeg
  
  
• 專題講座
  
  

2020 CKA考試視頻 真題講解 https://www.bilibili.com/video/BV167411K7hp



2020 CKA考試指南 https://www.bilibili.com/video/BV1sa4y1479B/



2020年 5月CKA考試真題 https://mp.weixin.qq.com/s/W9V4cpYeBhodol6AYtbxIA