Kubernetes 应用 troubleshooting

设置合理的 Req 和 Limit

其中:

• Guaranteed, 全部容器设置 CPU、MEM 的请求和限制，同时相等
• Burstable, 至少一个容器具有 CPU、MEM 的请求或限制
• BestEffort, 容器都没有设置 CPU、MEM 的请求或限制

Req 与 Limit 不应该相差太大，通常 Limit = Req * 1.5 或者根据监控历史进行设置。资源消耗越多的 Pod，Req 和 Limit 应该越相近。

关注应用的 CPU 限流

由于 CPU 是可压缩的资源，在设置了 Limit 之后，即使高负载，应用通常也是可用的。但是会很慢。这是由于系统对 CPU 的分配是分片的，在一个周期内，如果应用对 CPU 分片的使用达到 Limit 限制，那么应用需要等待下一个周期才能获得 CPU 使用机会。此时，应用处于 CPU 限流状态。CPU 限流会导致，应用的响应变慢。需要注意的是不仅仅是 Pod 的 CPU 使用达到 Limit 限制，如果节点的 CPU 负载高，同样也会存在 CPU 限流，应用能使用的资源是除去节点自身消耗的部分。

使用伸缩重启 Prometheus

不要滚动重启，滚动重启会导致，短时间内组件资源消耗加倍，影响集群稳定性。

1
2

kubectl scale deployment prom-prometheus-server --replicas=0
kubectl scale deployment prom-prometheus-server --replicas=1

同时，默认没有开启 --storage.tsdb.no-lockfile 参数下的 Prometheus 无法滚动重启，也只能使用上述方法重启。否则报错，opening storage failed: lock DB directory: resource temporarily unavailable。一个存储卷，多个 Prometheus 可能会导致脏数据。

运行容器时，exec user process caused: no such file or directory

有两种情况:

• 基础镜像是 alpine:latest，换其他镜像试试
• ENTRYPOINT 脚本的编码问题，修改 Windows 下的 CRLF 为 Linux 下的 LF