（图片来自网络）
改 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
这次修船到此，预计明天开上新船。