Day 24 - 常見問題與建議 (5)
本日共賞
- 探測失敗 (Probe Failure)
- 容器映像檔未更新
- 小結
希望你知道
探測失敗
容器正常運作不等於服務正常運作
所以該怎麼讓服務正常運作呢?答案是讓 k8s 知道容器目前正常運作。好像有點繞,但是這是使用 k8s 的時候特別重要的觀念:容器需要持續回報正常運作 (我還活著!)。
k8s 提供兩種探測方式:Liveness Probe
與 Readiness Probe
。基本上,Probe 會定期的執行某些動作來確保應用程式在正常運作中。
某些動作可能是執行某個指令或者是傳送一個 Http Request
如果使用 Liveness Probe
,當錯誤發生時 (無回應或回應錯誤),k8s 會嘗試重新建立 (kill then create) 一個新的容器。
如果使用 Readiness Probe
,當錯誤發生時,對應的 Service 物件就會將該容器標示為不可使用,所以任何的需求都不會導向該容器。
讓我們看看底下探測失敗的例子
# error-probe.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: err-probe-nginx
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
httpGet:
path: /healthy <=== 探測一個不存在的位置
port: 80
initialDelaySeconds: 3 <=== 容器啟動後 3 秒開始探測
periodSeconds: 3 <=== 探測間隔 3 秒
readinessProbe:
httpGet:
path: /healthy <=== 探測一個不存在的位置
port: 80
initialDelaySeconds: 3
periodSeconds: 3
接著部署到 k8s 並觀察狀態
$ kubectl apply -f error-probe.yaml
pod "err-probe-nginx" created
kubectl get pods
NAME READY STATUS RESTARTS AGE
err-probe-nginx 0/1 Running 0 11s
這時候會發現 READY: 0/1
,過一下再次查看
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
err-probe-nginx 0/1 Running 2 44s
發現 RESTARTS: 2
居然已經重啟兩次了,於是查看一下 Pod 內容
$ kubectl describe pods err-probe-nginx
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 56s default-scheduler Successfully assigned err-probe-nginx to minikube
Normal SuccessfulMountVolume 56s kubelet, minikube MountVolume.SetUp succeeded for volume "default-token-ld9jt"
Warning Unhealthy 28s (x5 over 46s) kubelet, minikube Readiness probe failed: HTTP probe failed with statuscode: 404 <=== 錯誤在這裡!
Normal Pulling 27s (x3 over 55s) kubelet, minikube pulling image "nginx"
Warning Unhealthy 27s (x5 over 45s) kubelet, minikube Liveness probe failed: HTTP probe failed with statuscode: 404 <=== 錯誤在這裡!
Normal Killing 27s (x2 over 39s) kubelet, minikube Killing container with id docker://nginx:Container failed liveness probe.. Container will be killed and recreated.
...
Liveness probe failed: HTTP probe failed
因為 Liveness Probe 探測結果回應 statuscode: 404
,即頁面不存在故 k8s 會嘗試重啟 Pod。
大於 200 小於 400 的 http code 皆判定為正常
建議方案
Probe 指定的位置是否正確
:上面例子的 /healthy 就不存在是否太快進行探測
:服務還沒運行就探測所以無法正確回應服務錯誤無法回覆
:服務發生錯誤,也許是資料庫設定錯誤或某些檔案不存在
請注意,這邊提到的 Probe 是指 k8s 本身。如果套用雲端服務,k8s 外可能還會再包一層 Load Balancer (LB),而 LB 本身也會需要探測服務是否正確運行,而探測的規則可能根據服務商而有所差異。
例如 Google 的 LB 只判定 200 為正常運行,因此如果探測位置回覆介於 200 到 400 但不等於 200 的回覆碼,Google LB 就會判定為異常。
容器映像檔未更新
程式開發難免會遇到需要修改 bug,而在容器環境下修改 bug 後,通常會把修正後的內容包成映像檔後再發佈到像 k8s 這類的環境中使用。這時候會有機會發生一個問題:k8s 啟動 Pod 時,並未抓取更新後的映像檔。
要討論為什麼會有這個問題?先要知道 k8s 是根據何種策略抓取映像檔即 pull policy。在 pull policy 中可以有以下設定
Always
:總是抓取Never
:不抓取IfNotPresent
:如果不存在的時候抓取
在不指定 :latest tag 下,預設會使用 IfNotPresent
這個抓取策略,如果有指定使用 :latest tag 則會套用 Always
策略。
關於 :latest tag 請參考 Docker 官網說明
接著預設一個情境
- 部署一個使用
jlptf/myapp:v1
映像檔的 Deployment - 發現 myapp 有問題需要修正
- 修正 myapp 後建立映像檔
jlptf/myapp:v1
- 刪除原本使用
jlptf/myapp:v1
映像檔的 Pod - k8s 自動建立使用
jlptf/myapp:v1
映像檔的 Pod - 問題並沒有被修正
寫到這裡聰明的大家應該都知道發生什麼事情了,由於並未指定 :latest tag 所以抓取映像檔會使用 IfNotPresent
策略,而 jlptf/myapp:v1
早就存在系統中,因此 k8s 並不會抓取修改過後的映像檔
建議方案
- 使用 :latest tag
- 在部署 Deployment 的設定中指定
ImagePullPolicy: Always
- 分配一個唯一的 tag
第一種方式不是很建議在正式環境下使用,因為只使用 :latest 無法追蹤映像檔變化,而且回復也會很困難。
使用第二種方式雖然可以解決映像檔未更新的問題,但是每次都需要重新抓取表示建構時間會加長。如果更新的內容與映像檔無關,那麼重新抓取映像檔就會浪費時間與流量。
如果使用雲端服務,流量是要算錢的
因此,如果能使用唯一的 tag,是較佳的解決方式。
小結
我們花了五天的時間分享了 k8s 常見的問題與建議方案。總結如下
- 善用
kubectl get pods
與kubectl describe pods/<name>
觀察 Pod 狀態 - 記得
kubectl describe deployment/<name>
觀察 Deployment 狀態 kubectl logs
可以幫你查看容器的訊息- Event 區塊包含了很多對除錯有幫助的訊息
經過這五天的分享,相信各位在未來面對錯誤時會比較有概念該如何處理。
本文與部署檔案同步發表於 https://jlptf.github.io/ironman2018-day24/