（图片来自网络）
改 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
这次修船到此，预计明天开上新船。
原文地址：https://www.cnblogs.com/cmt/p/12044012.html