在 Kubernetes中Pod是容器管理的最小單位, 有著各種各樣的Pod管理器. 那么一個Pod從啟動到釋放, 在這期間經歷了哪些過程呢?

Pod自開始創建, 到正常運行, 再到釋放, 其時間跨度及經歷的階段大致如下:

說一下各個階段的作用以及是為了解決什么問題. 容器調度和下載鏡像的過程就忽略了, 也沒什么好說的.

init

在Pod啟動一個容器時, 可以有一組init容器先行啟動(當然也可以沒有), 這些init容器會依次執行, 且前一個成功之后, 后一個才會執行. 同時還會監控init容器的退出狀態, 若init容器異常退出, 則會根據配置restartPolicy的重啟策略選擇重新啟動或退出(這里的退出, 說明Pod啟動失敗了). 通過配置文件的pod.spec.initContainers進行配置, 其配置項與containers相同

init容器可應用與如下場景:

• 可以將服務的創建和部署進行解耦. 以防止主容器過于臃腫
• 檢測依賴. 比如服務 A 必須要等服務 B 啟動成功之后才能運行, 那么就可以在服務 A 的 init 階段進行循環檢測等待, 直到服務 B 啟動成功了, 才開始啟動服務 A
• 具有訪問Secret的權限. Secret是用來存儲一些敏感數據的, 會進行加密處理. 主容器是沒有權限訪問的, 這也很好理解, 如果一個容器被攻破了, 如果能夠拿到Secret的數據, 很可能會導致一串服務都被攻破. 而init容器在Pod提供服務之前就退出了, 可以提高數據的安全.
• 等等

Pod在init容器啟動完成之前, 是不會對外提供服務的, 其狀態一直為Pending

start/stop

容器啟動和釋放時運行的鉤子. 通過配置文件的pod.spec.containers.lifecycle.postStart和pod.spec.containers.lifecycle.preStop進行配置. 配置相同, 這里用postStart舉例了. 具體配置可通過kubectl explain pod.spec.containers.lifecycle.postStart查看, 官方文檔很詳細.

# 執行一組命令 postStart: command: ["/bin/sh", "-c", "sleep 1"] --- # 調用 http 接口通知 postStart: host: baidu.compath: /startport: 80

readiness

既就緒探針. 檢測容器中的服務是否已經啟動成功并可以對外提供訪問了. 只有檢測成功后, 才會將狀態改為就緒狀態(Running). 定義在配置文件的pod.spec.containers.readinessProbe位置. 默認success

readiness是為了解決服務的啟動時間問題, 比如容器已經啟動成功了, 但是提供服務的進程還沒有啟動完畢, 此時對外提供服務的話就會有問題. Kubernetes提供了如下三種探針:

• ExecAction: 在容器中執行指定命令. 若命令返回0, 則成功
• TCPSocketAction: 對指定端口進行 TCP 檢查, 若端口開放, 則認為成功
• HTTPGetAction: 對指定端口進行 HTTP Get 請求, 若響應碼區間為[200, 400), 則認為成功

其配置文件大致如下:

# 命令探針 readinessProbe: exec: command: ["cat", "/tmp/file"]# 以下這些字段為通用字段, 下面不再重復# 探針失敗的最大重試次數, 超過這個次數則認為本次探測失敗, 容器啟動失敗. 默認3failureThreshold: 3# 探測的循環周期, n秒后進行下一次探測. 與 failureThreshold 配合確定啟動時間. 默認10speriodSeconds: 1# 執行第一次探測前需要等待5s. 默認0sinitialDelaySeconds: 5# 探測超時時間. 默認1stimeoutSeconds: 1# 當探測失敗后, 需要連續探測成功3次才認為成功. 默認1successThreshold: 3# 當探測失敗后, 優雅釋放可等待的時間. 超過則會被強制釋放terminationGracePeriodSeconds: 5 --- # tcp 探針 readinessProbe: tcpSocket: host: baidu.comport: 80 --- # http 探針 readinessProbe: httpGet: host: baidu.compath: /port: 80# 設置請求的 header, 是個對象數組httpHeaders: - name: headerNamevalue: headerValue# 請求方式. HTTP 或 HTTPS. 默認 HTTPscheme: HTTP

liveness

既存活探測, 在容器執行的這段時間, 探測容器是否存活, 若已經無法提供服務, 則需要重啟容器. 定義在配置文件的pod.spec.containers.livenessProbe位置. 其配置項與readiness相同, 不再贅述. 默認success

在容器運行過程中, 可能容器還活著, 但里面提供服務的進程已經死了(例如死鎖). 這時容器其實已經無法對外提供服務了. 需要這樣一種機制來檢測是否還能正常提供服務.

注意, liveness并不是在readiness探測完畢后才會啟動.而是幾乎同時啟動, 而liveness探測失敗后, 會導致容器重啟, 因此liveness的initialDelaySeconds配置就需要稍微花點心思了, 要延時一些時間, 等待服務啟動成功后再開始. 否則可能導致readiness還沒有完成探測任務, 就被liveness探測失敗而重啟了.

startup

上面說liveness與readiness是同時運行的, 通過配置liveness的initialDelaySeconds參數來等待. 但對于一些服務, 我們并不能確定其啟動需要多久呀, 如果一味延長等待時間就太不劃算了.

而startup就是為了解決liveness與readiness執行順序的問題, 將服務就緒探測和服務的存活探測徹底分開. 定義在配置文件的pod.spec.containers.startupProbe位置, 探針項與readiness相同.

startup探針會在探測成功后, 再將探測任務交由后續的探測任務. 默認success

所以一般使用liveness和startup配合探測即可, readiness貌似沒有什么用武之地了.

原文鏈接: https://hujingnb.com/archives/707

總結

以上是生活随笔為你收集整理的Kubernetes中Pod生命周期的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。