(圖片來自網絡)html
改 readinessProbe web
對於昨天 k8s 尼克號發生的觸礁事故,咱們分析下來主要是2個緣由,一是當時4個節點不夠用形成部分容器負載太高而宕機,二是 readinessProbe 健康檢查配置不合理,形成重啓後的容器沒法經過健康檢查。docker
skipping: failed to "StartContainer" for "blog-web" with CrashLoopBackOff.
CrashLoopBackOff 是指容器「啓動 -> 掛了 -> 又啓動了 -> 又掛了…」。(參考資料: Kubernetes Troubleshooting Walkthrough - Pod Failure CrashLoopBackOff)api
對於緣由一,已改成在訪問低峯也用5個節點。網絡
對於緣由二,將 readinessProbe 的配置由app
readinessProbe: initialDelaySeconds: 30 periodSeconds: 5
改成oop
readinessProbe: initialDelaySeconds: 40 periodSeconds: 5 successThreshold: 1 failureThreshold: 5 timeoutSeconds: 5
readinessProbe 健康檢查決定 service 是否將請求轉發給該容器處理。(參考資料:Kubernetes Liveness and Readiness Probes: How to Avoid Shooting Yourself in the Foot)spa
initialDelaySeconds 表示在容器啓動後進行第一次檢查的等待時間(默認是0秒)。3d
periodSeconds 表示每隔多長時間進行檢查(默認是30秒)。code
successThreshold 表示幾回檢查經過纔算成功(默認是1次)
failureThreshold 表示幾回檢查失敗纔算失敗(默認是3次),失敗後會重啓容器。
timeoutSeconds 檢查的超時時間(默認是1秒),當時咱們用的就是默認值,而容器中的 ASP.NET Core 應用第一次請求時預熱時間比較長,使用默認值很容易形成檢查超時,如今改成5秒。
去 DaemonSet
使用 DaemonSet 是由於咱們對 k8s 還不熟悉,在用開漁船(docker swarm)的方式駕駛巨輪(k8s),docker swarm compose 中用的是 mode: global ,換到 k8s 後咱們就用了對應的替代 DaemonSet ,殊不知道 k8s 強大的功能之一 —— 自動伸縮(autoscaling)。昨天故障時,DaemonSet 的部署方式是雪上加霜,部分 pod 掛了,剩下的 pod 即便負載再高,也不會啓動新的 pod 分擔負載。
在此次修船中將 DaemonSet 改成 Deployment
kind: DaemonSet
kind: Deployment
上 Autoscaler
自動伸縮(autoscaling)這個 k8s 強大的功能之一,讓咱們體會到了現代化的巨輪與落後的漁船(docker swarm)之間的巨大差異。以前只在雲上看到到自動伸縮,如今船上就有,並且使用起來很簡單,好比咱們須要根據容器的 CPU 佔用狀況自動伸縮 pod ,採用了下面的配置。
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: blog-web spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: blog-web minReplicas: 5 maxReplicas: 12 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 90
關於自動伸縮的參考資料:
* Horizontal Pod Autoscaler Walkthrough
* How to autoscale apps on Kubernetes with custom metrics
此次修船到此,預計明天開上新船。