k8s常见异常事件及解决⽅案
⽂章⽬录
1.集相关
1.1 Coredns容器或local-dns容器
重启集中的coredns组件发⽣重启(重新创建)，⼀般是由于coredns组件压⼒较⼤导致oom，请检查业务是否异常，是否存在应⽤容器⽆法解析域名的异常。
如果是local-dns重启，说明local-dns的性能也不够了，需要优化
1.2 Pod was OOM killed
云应⽤容器实例发⽣OOM，请检查云应⽤是否正常。⼀般地，如果云应⽤配置了健康检查，当进程OOM了，健康检查如果失败，集会⾃动重启容器。
OOM问题排查步骤：
检查应⽤进程内存配置，如Java的jvm参数，对⽐应⽤监控-基础监控中的内存指标，判断是否是参数设
置低导致进程内存不够⽤，适当进⾏参数优化
1.3 Out of memory: Kill process
原因描述：
⼀般是操作系统把容器内进程Kill⽽导致的系统内核事件。⽐如⼀个java应⽤，当实际占⽤内存超过堆内存配置⼤⼩时，就会出现OOM错误。发⽣进程被Kill之后，容器依旧是存活状态，容器的健康检查还会继续进⾏。所以后⾯通常会伴随出现健康检查失败的错误。
解决⽅案：
要具体分析进程被Kill的原因，适当的调整进程内存的限制值。可以结合应⽤监控来参考进程内存的变化趋势。
1.4 Memory cgroup out of memory: Kill process
原因描述：
⼀般是由于容器的内存实际使⽤量超过了容器内存限制值⽽导致的事件。⽐如容器的内存限制值配置
了1Gi，⽽容器的内存随着容器内进程内存使⽤量的增加超过了1Gi，就会导致容器被操作系统Cgroup Kill。发⽣容器被Kill之后，容器已经被停⽌，所以后续会出现应⽤实例被重启的情况。
解决⽅案：
检查容器内进程是否有内存泄漏问题，同时适当调整容器内存的限制值⼤⼩。可以结合应⽤监控来看变化趋势。需要注意的是，容器内存限制值⼤⼩不应该过⼤，否则可能导致极端资源争抢情况下，容器被迫驱逐的问题。
1.5 System OOM encountered
原因描述：
上述两种OOM（进程OOM，容器OOM）发⽣后，都可能会伴随⼀个系统OOM事件，该事件的原因是由上述OOM事件伴随导致。
解决⽅案：
需要解决上⾯进程OOM或者容器CgroupOOM的问题。
1.6 failed to garbage collect required amount of images
原因描述：
当容器集中的节点（宿主机）磁盘使⽤率达到85%之后，会触发⾃动的容器镜像回收策略，以便于释放⾜够的宿主机磁盘。该事件发⽣于当触发镜像回收策略之后，磁盘空间仍然不⾜以达到健康阈值（默认为80%）。通常该错误是由于宿主机磁盘被占⽤太多导致。当磁盘空间占⽤率持续增长（超过90%），会导致该节点上的所有容器被驱逐，也就是当前节点由于磁盘压⼒不再对外提供服务，直到磁盘空间释放。
解决⽅案：
检查节点的磁盘分配情况，通常有以下⼀些常见情况导致磁盘占⽤率过⾼：
1. 有⼤量⽇志在磁盘上没有清理；
docker重启容器命令2. 请清理⽇志。有进程在宿主机不停的写⽂件；
3. 请控制⽂件⼤⼩，将⽂件存储⾄OSS或者NAS。下载的或者是其他的静态资源⽂件占⽤空间过⼤；静态资源请存储⾄OSS或CDN。
1.7Attempting to xxxx
节点资源不⾜(EvictionThresholdMet)，⼀般是节点资源将要达到阈值，可能会触发Pod驱逐。如 Attempting to reclaim ephemeral-storage
原因描述：
ephemeral storage是临时存储空间，当磁盘空间使⽤率达到阈值，会触发临时存储空间的回收任务。回收任务会尝试回收系统⽇志，以及没有正在使⽤的镜像缓存等数据。当磁盘空间占⽤率持续增长（超过90%），会导致该节点上的所有容器被驱逐，也就是当前节点由于磁盘压⼒不再对外提供服务，直到磁盘空间释放。
解决⽅案：
请注意磁盘空间的使⽤：
1. 避免使⽤“空⽬录”类型的挂载⽅式；
2. 使⽤NAS或者其他类似⽅式替代。尽量避免使⽤“宿主机⽬录”类型的挂载⽅式，以便于保证容器是⽆状态的，可以迁移的。
3. 要注意避免在容器内⼤量写⽂件，⽽导致容器运⾏时可写数据层过⼤（imagefs）。
1.8 NTP service is not running
原因描述：
NTP service是系统时间校准服务，由操作系统systemd管理的服务。可以通过 systemctl status chronyd 查看对应服务的状态。
解决⽅案：
使⽤命令systemctl start chronyd尝试重新启动。也可以通过命令 journalctl -u chronyd 查看服务的⽇志。
1.9 节点PLEG异常
原因描述：
PLEG是pod⽣命周期事件⽣成器，会记录Pod⽣命周期中的各种事件，如容器的启动、终⽌等。⼀般是由于节点上的daemon进程异常或者节点systemd版本bug导致。出现该问题会导致集节点不可⽤
解决⽅案：
可以尝试重启kubelet；再尝试重启Docker进程。重启这两个进程过程中，不会对已运⾏容器造成影响
//重启kubelet
systemctl restart kubelet
//重启docker
systemctl restart docker
//查看docker⽇志
journalctl -xeu docker > docker.log
如果是由于systemd版本问题导致，重启节点可短暂修复，彻底解决的话需要升级节点的
systemdsystemd: (rpm -qa | grep systemd, 版本<219-67.el7需要升级)
升级systemd指令:
yum update -y systemd && systemctl daemon-reexec && killall runc
1. 10 节点PID不⾜
原因描述：
暂⽆解决⽅案：
1.11 节点FD不⾜
原因描述：
节点⽂件句柄使⽤数量超过80%，具体原因与节点上进程使⽤情况相关打开⽂件未释放打开管道未释放建⽴⽹络连接未释放
（pipe,eventpoll多出现在 NIO ⽹络编程未释放资源 —— selector.close()）创建进程调⽤命令未释放（(…) 得到的Process, InputStream, OutputStream 未关闭，这也会导致 pipe,eventpoll 未释放）
解决⽅案：
删除不需要的⽂件，调整应⽤代码，⽂件流等操作结束后记得关闭。或者尝试先排空再重启主机节点
1.12 Docker Hung
原因描述：
节点docker daemon异常，导致集⽆法与之通信，伴随有docker ps、docker exec等命令hung住或异常失败
解决⽅案：
尝试重启docker服务，重启过程不会影响已存在容器的运⾏
//重启节点上的docker daemon，对运⾏中容器没有影响
systemctl restart docker
//查看docker⽇志
journalctl -xeu docker > docker.log
如果docker服务重启后依然⽆法解决，可以尝试重启主机。主机重启过程会对容器有影响，谨慎操作。
1.13 节点磁盘资源不⾜ InvalidDiskCapacity
原因描述：
节点磁盘不⾜，⽆法分配空间给容器镜像
解决⽅案：
检查节点的磁盘分配情况，通常有以下⼀些常见情况导致磁盘占⽤率过⾼：有
1. ⼤量⽇志在磁盘上没有清理；请清理⽇志。
2. 有进程在宿主机不停的写⽂件；请控制⽂件⼤⼩，将⽂件存储⾄OSS或者NAS。
3. 下载的或者是其他的静态资源⽂件占⽤空间过⼤；静态资源请存储⾄OSS或CDN。
2. 应⽤相关
2.1Container Restart
原因描述：
该事件表⽰应⽤实例(重启)重启，⼀般是由于配置了健康检查且健康检查失败导致，会伴随有Readiness probe failed和Liveness probe failed等事件。健康检查失败的原因有很多，通常情况下，⽐如进程OOM被Kill、⽐如⾼负载情况下应⽤⽆法正常响应(例如RDS瓶颈导致应⽤线程全部hang住)，都可能会导致健康检查失败
解决⽅案：
需要结合临近的相关事件定位具体的Pod重启原因。如伴随有集相关的Out of memory事件，参考此⽂档上⾯Out of memory事件的解决⽅案；其他情况下，结合应⽤监控或者云产品⾃⾝监控来定位问题
2.2 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实例，可以通过kubectl get po 进⾏查看和⼿动清理##
2.3 K8S Pod Pending
原因描述：
该事件表⽰集调度Pod被挂起，⼀般是由于节点资源不⾜以调度容器或者Volume挂载失败（⽐如持久化存储卷不到）或者其他原因导致。
解决⽅案：
需要结合临近的相关事件定位具体的Pod挂起原因
2.4 Readiness probe failed
原因描述：
由于应⽤就绪探针失败⽽引发的异常事件。应⽤就绪探针失败会导致相应容器的流量被摘除，例如被动从SLB摘掉该容器的流量⼊⼝。
解决⽅案
需要结合应⽤就绪探针的配置，定位应⽤就绪探针失败的原因。
2.5 Liveness probe failed
原因描述：
由于应⽤存活探针失败⽽引发的异常事件。该事件可能会导致后续达到⼀定阈值之后，容器被动重启。具体要看应⽤就绪探针的配置。
解决⽅案：
需要结合应⽤存活探针的配置，定位探针检查失败的原因。
2.6 Container runtime did not kill the pod within specified grace period.
原因描述：
此事件表⽰容器没有在优雅下线的时间段内正常退出。⽐如如果配置了优雅下线脚本，脚本执⾏时长需要60s，⽽优雅下线时间（默认为30s）配置为30s。就会在容器下线期间触发这个事件。
解决⽅案：
调整优雅下线探针的配置，或者优雅下线时间的配置。
2.7 Back-off restarting failed container
原因描述：
此事件表⽰容器启动失败，⽽被再次拉起尝试启动。通常常见与应⽤发布过程中的容器启动失败。具体的原因常见为镜像拉取失败，或者容器启动失败（容器没有打到running状态）。
解决⽅案：
需要在发布页查看容器启动⽇志或者调度⽇志，进⼀步定位容器启动失败的原因。
2.8 The node was low on resource: xxxx
⽰例2020-07-21 10:24:43.000 [Event] Type: Warning, Reason: Evicted, Message: The node was low on resource: ephemeral-storage.
原因描述：
该事件表⽰Pod由于节点上的异常情况(资源不⾜)被驱逐
解决⽅案：
需要看具体哪类资源不⾜，例如⽰例中的ephemeral-storage，表⽰集节点临时存储空间不⾜，⼀般是由于磁盘使⽤量较⼤导致。请参考⽂档上⽅解决⽅案检查节点的磁盘分配情况，通常有以下⼀些常见情况导致磁盘占⽤率过⾼：
1. 有⼤量⽇志在磁盘上没有清理；请清理⽇志。
2. 有进程在宿主机不停的写⽂件；请控制⽂件⼤⼩，将⽂件存储⾄OSS或者NAS。
3. 下载的或者是其他的静态资源⽂件占⽤空间过⼤；静态资源请存储⾄OSS或CDN。
可以对系统盘进⾏扩容，扩⼤磁盘空间。
3. 集DNS性能瓶颈
3.1 背景
集中的容器实例，DNS解析均依赖集内的DNS组件，应⽤中业务请求的地址都需要经过集DNS
组件。例如，代码中访问RDS、REDIS、TOP api等。如果集dns性能不⾜，会出现业务请求失败的问题。
集DNS组件：
默认已安装的集组件为coredns，副本数为2
可选的⾼性能组件为localdns
3.2 是否有性能瓶颈
1. 应⽤有⼤量DNS请求的场景(⽐如连接rds，凡是涉及到域名地址解析的)
2. PHP等语⾔⾃⾝没有连接池特性的，或者应⽤⾃⾝没有DNS缓存的
3. 偶尔出现域名地址⽆法解析错误的

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。