注意:以下文档只适用于TOP接口,请谨慎使用!

文档中心 > 聚石塔

K8S相关常见问题

更新时间:2020/08/05 访问次数:306

集群相关

Out of memory: Kill process

原因描述:

一般是操作系统把容器内进程Kill而导致的系统内核事件。比如一个java应用,当实际占用内存超过堆内存配置大小时,就会出现OOM错误。发生进程被Kill之后,容器依旧是存活状态,容器的健康检查还会继续进行。所以后面通常会伴随出现健康检查失败的错误。

解决方案:

要具体分析进程被Kill的原因,适当的调整进程内存的限制值。可以结合应用监控来参考进程内存的变化趋势。

 

Memory cgroup out of memory: Kill process

原因描述:

一般是由于容器的内存实际使用量超过了容器内存限制值而导致的事件。比如容器的内存限制值配置了1Gi,而容器的内存随着容器内进程内存使用量的增加超过了1Gi,就会导致容器被操作系统Cgroup Kill。发生容器被Kill之后,容器已经被停止,所以后续会出现应用实例被重启的情况。

解决方案:

检查容器内进程是否有内存泄漏问题,同时适当调整容器内存的限制值大小。可以结合应用监控来看变化趋势。需要注意的是,容器内存限制值大小不应该过大,否则可能导致极端资源争抢情况下,容器被迫驱逐的问题。参考:https://www.yuque.com/fczggw/wu7u0k/fvv2kv#OL7hK

 

System OOM encountered

原因描述:

上述两种OOM(进程OOM,容器OOM)发生后,都可能会伴随一个系统OOM事件,该事件的原因是由上述OOM事件伴随导致。

解决方案:

需要解决上面进程OOM或者容器CgroupOOM的问题。

 

failed to garbage collect required amount of images

原因描述:

当容器集群中的节点(宿主机)磁盘使用率达到85%之后,会触发自动的容器镜像回收策略,以便于释放足够的宿主机磁盘。该事件发生于当触发镜像回收策略之后,磁盘空间仍然不足以达到健康阈值(默认为80%)。通常该错误是由于宿主机磁盘被占用太多导致。当磁盘空间占用率持续增长(超过90%),会导致该节点上的所有容器被驱逐,也就是当前节点由于磁盘压力不再对外提供服务,直到磁盘空间释放。

解决方案:

检查节点的磁盘分配情况,通常有一下一些常见情况导致磁盘占用率过高:

  1. 有大量日志在磁盘上没有清理;请清理日志。
  2. 有进程在宿主机不停的写文件;请控制文件大小,将文件存储至OSS或者NAS。
  3. 下载的或者是其他的静态资源文件占用空间过大;静态资源请存储至OSS或CDN。

 

Attempting to reclaim ephemeral-storage

原因描述:

ephemeral storage是临时存储空间,临时存储空间详情参考https://www.yuque.com/fczggw/wu7u0k/yi8257#9Ry7z。当磁盘空间使用率达到阈值,会触发临时存储空间的回收任务。回收任务会尝试回收系统日志,以及没有正在使用的镜像缓存等数据。当磁盘空间占用率持续增长(超过90%),会导致该节点上的所有容器被驱逐,也就是当前节点由于磁盘压力不再对外提供服务,直到磁盘空间释放。

解决方案:

请注意磁盘空间的使用:

  1. 避免使用“空目录”类型的挂载方式;使用NAS或者其他类似方式替代。
  2. 尽量避免使用“宿主机目录”类型的挂载方式,以便于保证容器是无状态的,可以迁移的。
  3. 要注意避免在容器内大量写文件,而导致容器运行时可写数据层过大(imagefs)。

 

NTP service is not running

原因描述:

NTP service是系统时间校准服务,由操作系统systemd管理的服务。可以通过 systemctl status chronyd 查看对应服务的状态。

解决方案:

使用命令`systemctl start chronyd`尝试重新启动。也可以通过命令 journalctl -u chronyd 查看服务的日志。

 

应用相关

Container Restart

原因描述:

该事件表示应用实例(重启)重启,一般是由于配置了健康检查且健康检查失败导致,会伴随有Readiness probe failed和Liveness probe failed等事件。健康检查失败的原因有很多,通常情况下,比如进程OOM被Kill、比如高负载情况下应用无法正常响应(例如RDS瓶颈导致应用线程全部hang住),都可能会导致健康检查失败

解决方案:

需要结合临近的相关事件定位具体的Pod重启原因。如伴随有集群相关的Out of memory事件,参考此文档上面Out of memory事件的解决方案;其他情况下,结合应用监控或者云产品自身监控来定位问题

 

The node had condition: [XXX]

原因描述:

该事件表示Pod由于节点上的异常情况被驱逐,比如The node had condition: [DiskPressure],表示节点磁盘使用率比较高,通常会伴随有 failed to garbage collect required amount of images 和 Attempting to reclaim ephemeral-storage 等集群维度(节点)的异常事件

解决方案:

需要结合临近的相关事件定位具体的驱逐原因。对于已经被驱逐的Pod实例,可以在聚石塔控制台,环境管理-管理资源-异常实例,进行查看和手动清理

 

K8S Pod Pending

原因描述:

该事件表示集群调度Pod被挂起,一般是由于节点资源不足以调度容器或者Volume挂载失败(比如持久化存储卷找不到)或者其他原因导致。

解决方案:

需要结合临近的相关事件定位具体的Pod挂起原因

 

Readiness probe failed

原因描述:

由于应用就绪探针失败而引发的异常事件。应用就绪探针失败会导致相应容器的流量被摘除,例如被动从SLB摘掉该容器的流量入口。

解决方案

需要结合应用就绪探针的配置(https://www.yuque.com/fczggw/wu7u0k/fvv2kv#ZZRBy),定位应用就绪探针失败的原因。

 

Liveness probe failed

原因描述:

由于应用存活探针失败而引发的异常事件。该事件可能会导致后续达到一定阈值之后,容器被动重启。具体要看应用就绪探针的配置。

解决方案:

需要结合应用存活探针的配置(https://www.yuque.com/fczggw/wu7u0k/fvv2kv#q3K10),定位探针检查失败的原因。

 

Container runtime did not kill the pod within specified grace period.

原因描述:

此事件表示容器没有在优雅下线的时间段内正常退出。比如如果配置了优雅下线脚本,脚本执行时长需要60s,而优雅下线时间(默认为30s)配置为30s。就会在容器下线期间触发这个事件。

解决方案:

调整优雅下线探针的配置,或者优雅下线时间的配置。

 

Back-off restarting failed container

原因描述:

此事件表示容器启动失败,而被再次拉起尝试启动。通常常见与应用发布过程中的容器启动失败。具体的原因常见为镜像拉取失败,或者容器启动失败(容器没有打到running状态)。

解决方案:

需要在发布页查看容器启动日志或者调度日志,进一步定位容器启动失败的原因。

 

FAQ

关于此文档暂时还没有FAQ
返回
顶部