K8S常见异常事件与解决方案

这篇具有很好参考价值的文章主要介绍了K8S常见异常事件与解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

集群相关

Coredns容器或local-dns容器重启

集群中的coredns组件发生重启(重新创建),一般是由于coredns组件压力较大导致oom,请检查业务是否异常,是否存在应用容器无法解析域名的异常。

如果是local-dns重启,说明local-dns的性能也不够了,需要优化

Pod was OOM killed

云应用容器实例发生OOM,请检查云应用是否正常。一般地,如果云应用配置了健康检查,当进程OOM了,健康检查如果失败,集群会自动重启容器。

OOM问题排查步骤:

检查应用进程内存配置,如Java的jvm参数,对比应用监控-基础监控中的内存指标,判断是否是参数设置低导致进程内存不够用,适当进行参数优化

Out of memory: Kill process

原因描述:

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

解决方案:

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

Memory cgroup out of memory: Kill process

原因描述:

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

解决方案:

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

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 xxxx

节点资源不足(EvictionThresholdMet),一般是节点资源将要达到阈值,可能会触发Pod驱逐。如 Attempting to reclaim ephemeral-storage

原因描述:

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

解决方案:

请注意磁盘空间的使用:

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

NTP service is not running

原因描述:

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

解决方案:

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

节点PLEG异常

原因描述:

PLEG是pod生命周期事件生成器,会记录Pod生命周期中的各种事件,如容器的启动、终止等。一般是由于节点上的daemon进程异常或者节点systemd版本bug导致。出现该问题会导致集群节点不可用

解决方案:

可以尝试重启kubelet;再尝试重启Docker进程。重启这两个进程过程中,不会对已运行容器造成影响

//重启kubelet
systemctl restart kubelet

//重启docker
systemctl restart docker

//查看docker日志
journalctl -xeu docker > docker.log

如果是由于systemd版本问题导致,重启节点可短暂修复,彻底解决的话需要升级节点的systemd

systemd: (rpm -qa | grep systemd, 版本<219-67.el7需要升级)
升级systemd指令: 
yum update -y systemd && systemctl daemon-reexec && killall runc

节点PID不足

原因描述:

暂无

解决方案:

节点FD不足

原因描述:

节点文件句柄使用数量超过80%,具体原因与节点上进程使用情况相关

  1. 打开文件未释放
  2. 打开管道未释放
  3. 建立网络连接未释放(pipe,eventpoll多出现在 NIO 网络编程未释放资源 —— selector.close())
  4. 创建进程调用命令未释放(Runtime.exe(…) 得到的 Process, InputStream, OutputStream 未关闭,这也会导致 pipe,eventpoll 未释放)

解决方案:

删除不需要的文件,调整应用代码,文件流等操作结束后记得关闭。或者尝试先排空再重启主机

节点Docker Hung

原因描述:

节点docker daemon异常,导致集群无法与之通信,伴随有docker ps、docker exec等命令hung住或异常失败

解决方案:

尝试重启docker服务,重启过程不会影响已存在容器的运行

//重启节点上的docker daemon,对运行中容器没有影响
systemctl restart docker

//查看docker日志
journalctl -xeu docker > docker.log

如果docker服务重启后依然无法解决,可以尝试重启主机。主机重启过程会对容器有影响,谨慎操作。

节点磁盘资源不足

InvalidDiskCapacity

原因描述:

节点磁盘不足,无法分配空间给容器镜像

解决方案:

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

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

应用相关

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实例,可以通过kubectl get po 进行查看和手动清理

K8S Pod Pending

原因描述:

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

解决方案:

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

Readiness probe failed

原因描述:

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

解决方案

需要结合应用就绪探针的配置,定位应用就绪探针失败的原因。

Liveness probe failed

原因描述:

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

解决方案:

需要结合应用存活探针的配置,定位探针检查失败的原因。

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

原因描述:

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

解决方案:

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

Back-off restarting failed container

原因描述:

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

解决方案:

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

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。

可以对系统盘进行扩容,扩大磁盘空间。

集群DNS性能瓶颈

背景

集群中的容器实例,DNS解析均依赖集群内的DNS组件,应用中业务请求的地址都需要经过集群DNS组件。例如,代码中访问RDS、REDIS、TOP api等。如果集群dns性能不足,会出现业务请求失败的问题。

集群DNS组件:

  • 默认已安装的集群组件为coredns,副本数为2
  • 可选的高性能组件为localdns

是否有性能瓶颈

  1. 应用有大量DNS请求的场景(比如连接rds,凡是涉及到域名地址解析的)
  2. PHP等语言自身没有连接池特性的,或者应用自身没有DNS缓存的
  3. 偶尔出现域名地址无法解析错误的

解决方案

一、集群默认已安装的coredns组件,进行扩容。扩容比例为1/5的节点数(如15台ecs,那么coredns数量为3)

二、为集群安装更高性能的localdns组件(该组件为daemonset,会在每个ECS节点起一个本地缓存)

一般来说,如果业务量小,扩容下coredns就足够了;如果业务量大(域名地址解析QPS高,比如访问RDS),特别是php等不带连接池的开发语言,建议直接上localdns。如果是java等配置了连接池的应用,可以先扩容coredns观察,如果仍然有解析问题,再上localdns。

localdns缓存原理

NodeLocalDNS 是一个 DaemonSet,会在Kubernetes集群的每个节点上运行一个专门处理 DNS 查询请求的 Pod,该 Pod 会将集群内部域名查询请求发往 CoreDNS;将集群外部请求直接发往外部域名解析服务器。同时能够Cache所有请求。可以被看作是节点级别的高效DNS 缓存,能够大幅提高集群整体 DNS 查询的 QPS。NodeLocalDNS 会在集群的每个节点上创建一个专用的虚拟接口(接口绑定的 IP 需要通过 local_dns_ip 这个值来指定),节点上所有发往该 IP 的 DNS 查询请求都会被拦截到 NodeLocalDNS Pod 内进行处理;通过集群原有的 kube-dns 服务(该服务的 clusterIP 值需要通过kube_dns_ip来指定)来与CoreDNS进行通信。

k8s 重启coredns,kubernetes,jvm,java文章来源地址https://www.toymoban.com/news/detail-729449.html

到了这里,关于K8S常见异常事件与解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【容器】K8s容器内部dns解析慢解决方案

    K8s内,要对做内部域名解析的劫持,解析 *.lol.com 至 172.34.18.12。 通过在coredns的配置文件配置 *.lol.com 的泛域名解析(如下所示),能够解析成功。但是在容器内部解析公网/内部地址慢。正常的http请求花费5-6秒。 DNS解析慢可能出现的问题在解析链路的各个环节。我们按照解析

    2024年01月25日
    浏览(43)
  • K8s 生产环境问题汇总及解决方案(持续更新 ing)

    目录 一、前端页面显示 503 Service Temporarily Unavailable 问题背景 解决方案 原理 二、Dockfile 构建镜像失败:When using COPY with more than one source file, the destination must be a directory and end with a /  问题背景 解决方案 原理 三、前端页面显示 502 Bad Gateway 问题背景  解决方案 原理 时间:2

    2024年02月02日
    浏览(39)
  • kubeadm 安装k8s集群后,master节点notready问题解决方案

    使用kubeadm 安装k8s集群后,加载calico cni 网络组件后,master节点notready问题 表现为: 使用命令查看日志:journalctl -f -u kubelet 报错如下: Failed to start ContainerManager failed to initialize top level QOS containers: failed to update top level Burstable QOS cgroup : failed to set supported cgroup subsystems for cgroup

    2024年01月22日
    浏览(47)
  • K8S1.23.6版本详细安装教程以及错误解决方案(包括前置环境,使用部署工具kubeadm来引导集群)

    一台兼容的 Linux 主机。Kubernetes 项目为基于 Debian 和 Red Hat 的 Linux 发行版以及一些不提供包管理器的发行版提供通用的指令。 每台机器 2 GB 或更多的 RAM(如果少于这个数字将会影响你应用的运行内存)。 CPU 2 核心及以上。 集群中的所有机器的网络彼此均能相互连接(公网和

    2024年03月14日
    浏览(43)
  • K8S:K8S部署常见错误及解决方法

    目录 1、node节点kubelet服务起不来 2、安装cni网络插件时 kubectl get node master和node一直noready①有延时,需要等待10分钟左右,超过15分钟则有问题 3、部署报错kubectl get nodes No resources found 4、k8s部署报错error:kubectl get csr No resources found 问题:node节点kublet起不来服务器内存资源不足

    2024年02月09日
    浏览(47)
  • Hadoop常见异常及其解决方案

    1、Shell$ExitCodeException 现象:运行hadoop job时出现如下异常: 14/07/09 14:42:50 INFO mapreduce.Job: Task Id : attempt_1404886826875_0007_m_000000_1, Status : FAILED Exception from container-launch: org.apache.hadoop.util.Shell E x i t C o d e E x c e p t i o n : o r g . a p a c h e . h a d o o p . u t i l . S h e l l ExitCodeException: org.ap

    2024年02月06日
    浏览(45)
  • Selenium常见异常分析及解决方案

    现象: pycharm中输入 from selenium import webdriver ,  selenium 标红 原因1: pycharm使用的虚拟环境中没有安装selenium, 解决方法: 在pycharm中通过设置或terminal面板重新安装selenium 原因2: 当前项目下有 selenium.py ,和系统包名冲突导致, 解决方法,重命名这个文件 未找到响应的浏览器驱动 WebDri

    2024年02月09日
    浏览(47)
  • K8s 场景下 Logtail 组件可观测方案升级-Logtail 事件监控发布

    随着K8s和云的普及,越来越多的公司将业务系统部署到云上,并且使用K8s来部署应用。Logtail是SLS提供的日志采集Agent,能够非常好的适应K8s下各种场景的日志采集,支持通过DaemonSet方式和Sidecar方式采集Kubernetes集群的容器标准输出或者文件日志。Logtail作为一个K8s场景下非常重

    2024年01月17日
    浏览(41)
  • 阿里云部署k8s及常见的错误解决方法

    目录 一、背景介绍 二、环境准备 2.1 ECS云服务资源清单 2.2 K8s软件列表 三、阿里云ECS服务器网络问题 3.1 问题阐述 3.2 解决方案 四、服务节点调整(master,node1,node2) 4.1 关闭firewalld防火墙,并安装设置Iptables规则为空 4.2 调整内核参数 4.3 关闭 swap  4.4 关闭 selinux 4.5 设置h

    2024年02月08日
    浏览(45)
  • [K8S:命令执行:权限异常:解决篇]:通过更新kubeconfig配置相关信息

    执行K8S相关命令显示关键信息 2.1.1:执行命令: 这一步应该在安装K8S kubeadm init后面执行,之前安装忘记这一步。 [root@vboxnode3ccccccttttttchenyang ~]# mkdir -p $HOME/.kube [root@vboxnode3ccccccttttttchenyang ~]# [root@vboxnode3ccccccttttttchenyang ~]# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config cp:是否覆

    2024年02月03日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包