k8s 開船記-修船：改 readinessProbe ，去 DaemonSet ，上 Autoscaler
（圖片來自網路）
改 readinessProbe
對於昨天 k8s 尼克號發生的觸礁事故，我們分析下來主要是2個原因，一是當時4個節點不夠用造成部分容器負載過高而宕機，二是 readinessProbe 健康檢查配置不合理，造成重啟後的容器無法通過健康檢查。
skipping: failed to "StartContainer" for "blog-web" with CrashLoopBackOff.
CrashLoopBackOff 是指容器“啟動 -> 掛了 -> 又啟動了 -> 又掛了…”。（參考資料： Kubernetes Troubleshooting Walkthrough - Pod Failure CrashLoopBackOff）
對於原因一，已改為在訪問低峰也用5個節點。
對於原因二，將 readinessProbe 的配置由
readinessProbe: initialDelaySeconds: 30 periodSeconds: 5
改為
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）
initialDelaySeconds 表示在容器啟動後進行第一次檢查的等待時間（預設是0秒）。
periodSeconds 表示每隔多長時間進行檢查（預設是30秒）。
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
* Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Pod Autoscaler, and Vertical Pod Autoscaler
這次修船到此，預計明天開上新船。