雲管理服務專家新鈦雲服祝祥原創
Kubernetes在增加了雲部署的可擴充套件性、可移植性和可觀察性的同時，也增加了故障風險。雖然它帶來了一個具有強大功能和選擇的生態系統，以及簡化了複雜的應用部署，但它也面臨著很多的挑戰。Kubernetes給我們帶來的一個重要特性就是高可用性。
Kubernetes中有許多高可用性選項。在本文中，我們將討論用於應用程式/微服務本身的高可用性選項。
Pods是Kubernetes中最小的可部署單元，一旦應用了宣告式配置，Pods就會被排程。Kube-scheduler負責計算和排程，一旦排程被接受，它就處於一個受控和計算的環境中，根據pod條件，它被視為服務就緒或不就緒。透過使用startup、readiness和liveness探針，我們可以控制pod何時應該被視為已啟動、準備就緒或處於活動狀態。我們將探討這些條件和觸發因素。
Pod與Container狀態
Pod具有階段性和條件性；容器有狀態。這些狀態屬性可以並且將根據探測結果進行更改，因此讓我們對其進行研究。
Pod階段
Pod狀態物件包括一個階段欄位。這個階段欄位告訴Kubernetes和我們pod的執行週期在那個階段。
Pengding：
群集已接受，但尚未配置容器。
Running：
至少一個容器處於執行，啟動或重新啟動狀態。
Succeeded：
所有容器退出，狀態碼為零；pod不會重新啟動。
Failed：
所有容器都已終止，並且至少一個容器的狀態程式碼為非零。
Unknown：
無法確定容器的狀態。
Pod條件
除Pod階段外，還有Pod條件。這些還提供有關Pod所在狀態的資訊。
PodScheduled：
已成功選擇一個節點來排程Pod，並且排程已完成。
ContainersReady：
所有容器均已準備就緒。
Initialized：
啟動了初始化容器。
Ready：
pod能夠為請求提供服務；因此它需要包含在服務和負載均衡中。
我們可以透過kubectl describe pods
kubectl describe pods
示例輸出如下：
。。。
Conditions：
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
。。。
Container States
容器具有三個簡單狀態。
Waiting：
正在執行啟動程序。
Running：
容器正在正常執行。
Terminated：
容器開始執行，並以成功或失敗結束。
探索Pod物件的狀態
透過Kubernetes get pods -o yaml命令，我們可以從pod物件中看到pod條件和容器狀態。
。。。
status：
conditions：
- lastProbeTime： null
lastTransitionTime： “2021-02-08T11：11：53Z”
status： “True”
type： Initialized
- lastProbeTime： null
lastTransitionTime： “2021-02-08T11：14：20Z”
status： “True”
type： Ready
- lastProbeTime： null
lastTransitionTime： “2021-02-08T11：14：20Z”
status： “True”
type： ContainersReady
- lastProbeTime： null
lastTransitionTime： “2021-02-08T11：11：52Z”
status： “True”
type： PodScheduled
containerStatuses：
- containerID： containerd：//7fc67a850ba439f64ecb51a129a2d7dcbc4a3402b253daa3a6827787f7c80e40
image： docker。io/library/nginx：latest
imageID： docker。io/library/nginx@sha256：10b8cc432d56da8b61b070f4c7d2543a9ed17c2b23010b43af434fd40e2ca4aa
lastState：
terminated：
containerID： containerd：//c4416e69b7348a7e7be3f7046dc9745dfb38ba537e5b8c06da5020c67b12b3d8
exitCode： 137
finishedAt： “2021-02-08T11：14：52Z”
reason： Error
startedAt： “2021-02-08T11：14：05Z”
name： nginx
ready： true
restartCount： 1
started： true
state：
running：
startedAt： “2021-02-08T11：16：28Z”
hostIP： x。x。x。x
phase： Running
podIP： 10。1。239。205
podIPs：
- ip： 10。1。239。205
qosClass： BestEffort
startTime： “2021-02-08T11：11：53Z”
如果您更喜歡JSON的輸出，則可以使用 kubectl get pods
{
“conditions”： ［
{
“lastProbeTime”： null，
“lastTransitionTime”： “2021-02-08T11：11：53Z”，
“status”： “True”，
“type”： “Initialized”
}，
{
“lastProbeTime”： null，
“lastTransitionTime”： “2021-02-08T11：14：20Z”，
“status”： “True”，
“type”： “Ready”
}，
{
“lastProbeTime”： null，
“lastTransitionTime”： “2021-02-08T11：14：20Z”，
“status”： “True”，
“type”： “ContainersReady”
}，
{
“lastProbeTime”： null，
“lastTransitionTime”： “2021-02-08T11：11：52Z”，
“status”： “True”，
“type”： “PodScheduled”
}
］，
“containerStatuses”： ［
{
“containerID”： “containerd：//7fc67a850ba439f64ecb51a129a2d7dcbc4a3402b253daa3a6827787f7c80e40”，
“image”： “docker。io/library/nginx：latest”，
“imageID”： “docker。io/library/nginx@sha256：10b8cc432d56da8b61b070f4c7d2543a9ed17c2b23010b43af434fd40e2ca4aa”，
“lastState”： {
“terminated”： {
“containerID”： “containerd：//c4416e69b7348a7e7be3f7046dc9745dfb38ba537e5b8c06da5020c67b12b3d8”，
“exitCode”： 137，
“finishedAt”： “2021-02-08T11：14：52Z”，
“reason”： “Error”，
“startedAt”： “2021-02-08T11：14：05Z”
}
}，
“name”： “nginx”，
“ready”： true，
“restartCount”： 1，
“started”： true，
“state”： {
“running”： {
“startedAt”： “2021-02-08T11：16：28Z”
}
}
}
］，
“hostIP”： “x。x。x。x”，
“phase”： “Running”，
“podIP”： “10。1。239。205”，
“podIPs”： ［
{
“ip”： “10。1。239。205”
}
］，
“qosClass”： “BestEffort”，
“startTime”： “2021-02-08T11：11：53Z”
}
Kubernetes中的探針
Kubernetes提供了探針——health checks——來監控和操作pods的狀態或狀況，以確保只有健康的pods才能提供正常服務。Kubelet是執行health checks的主要元件，同時更新API伺服器。
探針處理器
共有三種可用的處理程式，幾乎可以涵蓋所有情況。
Exec Action
ExecAction在容器內執行命令；這也是一個閘道器功能，可以處理任何事情，因為我們可以執行任意可執行檔案；這可能是一個curl請求以確定狀態的指令碼，也可能是呼叫外部連結的可執行檔案。同時，需要確保可執行檔案不會建立殭屍程序。
TCP Socket Action
TCPSocketAction連線到已定義的埠以檢查該埠是否開啟，主要用於不使用HTTP的端點。HTTPGetAction將HTTP Get請求作為探針傳送到定義的路徑，HTTP響應程式碼確定探針是否成功。
通用探針引數
每種探針都有共同的可配置欄位：
initialDelaySeconds
：容器啟動之後和探測開始之前的秒數。（預設值：0）
periodSeconds
：Pod的頻率。（預設值：10）
timeoutSeconds
：預期響應的超時。（預設值：1）
successThreshold
：從失敗狀態過渡到健康狀態所獲得的成功結果數。（預設值：1）
failureThreshold
：從正常狀態轉換為故障狀態時收到了多少個失敗結果。（預設值：3）
如您所見，我們可以詳細配置探針。為了成功進行探針配置，我們需要分析應用程式/微服務的需求和依賴性。
Startup Probes
如果您的程序需要時間來準備、讀取檔案、解析大型配置、準備一些資料等等，那麼應該使用Startup Probes。如果探測失敗，超過閾值，它將重新啟動，以便重新開始操作。您需要相應地調整initialDelaySeconds和periodSeconds，以確保程序有足夠的時間完成。否則，你會發現pod的會不停的迴圈啟動。
Readiness Probes
如果你想控制傳送到pod的流量，你應該使用Readiness Probes。Readiness Probes可以修改Pod條件：確認Pod是否應包含在服務和負載均衡中。當探測成功足夠的次數（閾值）時，這意味著pod可以接收流量，那麼它應該包含在服務和負載平均衡中，從而正常提供業務訪問。如果您的流程能夠使自己脫離服務進行維護、讀取大量用於服務的資料等，那麼您應該再次使用Readiness Probes。這樣pod就可以透過Readiness Probes向Kubelet發出訊號，表示它希望暫時退出服務。
Liveness Probes
如果發生意外錯誤時容器本身無法崩潰，則使用liveness probes。使用liveness probes可以解決流程可能存在的一些缺陷。一旦liveness probes失敗，Kubelet就會重啟pod。如果您的程序可以透過退出來處理這些錯誤，則不需要使用liveness probes；但是，在修復未知錯誤之前，使用它們是有利的。
示例：Kubernetes API
Kubernetes API還包括執行endpoints的health check：healthz（不建議使用），readyz，livez。讓我們看一下readyz旨在與現成探針一起使用的endpoint。kubectl get ——raw=‘/readyz？verbose’
將各個服務的執行狀況合併以顯示執行狀況。
［+］ping ok
［+］log ok
［+］etcd ok
［+］informer-sync ok
［+］poststarthook/start-kube-apiserver-admission-initializer ok
［+］poststarthook/generic-apiserver-start-informers ok
［+］poststarthook/start-apiextensions-informers ok
［+］poststarthook/start-apiextensions-controllers ok
［+］poststarthook/crd-informer-synced ok
［+］poststarthook/bootstrap-controller ok
［+］poststarthook/scheduling/bootstrap-system-priority-classes ok
［+］poststarthook/start-cluster-authentication-info-controller ok
［+］poststarthook/aggregator-reload-proxy-client-cert ok
［+］poststarthook/start-kube-aggregator-informers ok
［+］poststarthook/apiservice-registration-controller ok
［+］poststarthook/apiservice-status-available-controller ok
［+］poststarthook/kube-apiserver-autoregistration ok
［+］autoregister-completion ok
［+］poststarthook/apiservice-openapi-controller ok
［+］shutdown ok
healthz check passed
讓我們看一下livez endpoint。kubectl get ——raw=‘/livez？verbose’
將各個服務的執行狀況合併以顯示執行狀況。
［+］ping ok
［+］log ok
［+］etcd ok
［+］poststarthook/start-kube-apiserver-admission-initializer ok
［+］poststarthook/generic-apiserver-start-informers ok
［+］poststarthook/start-apiextensions-informers ok
［+］poststarthook/start-apiextensions-controllers ok
［+］poststarthook/crd-informer-synced ok
［+］poststarthook/bootstrap-controller ok
［+］poststarthook/scheduling/bootstrap-system-priority-classes ok
［+］poststarthook/start-cluster-authentication-info-controller ok
［+］poststarthook/aggregator-reload-proxy-client-cert ok
［+］poststarthook/start-kube-aggregator-informers ok
［+］poststarthook/apiservice-registration-controller ok
［+］poststarthook/apiservice-status-available-controller ok
［+］poststarthook/kube-apiserver-autoregistration ok
［+］autoregister-completion ok
［+］poststarthook/apiservice-openapi-controller ok
healthz check passed
結論：
我們已經研究了Kubernetes探針技術；它們是應用高可用方案的重要組成部分。另一方面，很明顯，錯誤的配置會對應用程式/微服務的可用性產生不利影響。最重要的是要適當地配置和測試不同的場景以找到最佳值；我們需要考慮外部源的穩定性，以及我們是否會在探測響應端點上包含此檢查。我們已經看到Readiness Probe是用於在服務和負載均衡中刪除異常pod，而liveness Probe則是在故障時重新啟動pod。您可以在“進一步閱讀”部分找到以前文章的連結，其中詳細介紹了 Readiness， Liveness與Startup Probes。
進一步閱讀：
Kubernetes啟動探針-示例和常見陷阱（https：//loft。sh/blog/kubernetes-startup-probes-examples-common-pitfalls/）
Kubernetes活力探針-示例和常見陷阱（https：//loft。sh/blog/kubernetes-liveness-probes-examples-common-pitfalls/index-1/）
Kubernetes準備就緒探針-示例和常見陷阱（https：//loft。sh/blog/kubernetes-readiness-probes-examples-common-pitfalls/）
Kubernetes核心探針文件（https：//kubernetes。io/docs/reference/generated/kubernetes-api/v1。19/#probe-v1-core）
配置Liveness， Readiness 與Startup Probes（https：//kubernetes。io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/）
Kubernetes容器探針說明檔案（https：//kubernetes。io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes）
容器Lifecycle Hooks文件（https：//kubernetes。io/docs/concepts/containers/container-lifecycle-hooks/）
原文：
https：//loft。sh/blog/kubernetes-probes-startup-liveness-readiness/
