标签:关于 and scale average 之一 请求转发 bre 访问 self
(图片来自网络)
改 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
这次修船到此,预计明天开上新船。
k8s 开船记-修船:改 readinessProbe ,去 DaemonSet ,上 ??Autoscaler
标签:关于 and scale average 之一 请求转发 bre 访问 self
原文地址:https://www.cnblogs.com/cmt/p/12044012.html