旅游网站建设国内外现状,seo学徒招聘,中山做app网站公司哪家好,wordpress添加优酷视频教程集群相关
Coredns容器或local-dns容器重启
集群中的coredns组件发生重启(重新创建)#xff0c;一般是由于coredns组件压力较大导致oom#xff0c;请检查业务是否异常#xff0c;是否存在应用容器无法解析域名的异常。
如果是local-dns重启#xff0c;说明local-dns的性能…集群相关
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%会导致该节点上的所有容器被驱逐也就是当前节点由于磁盘压力不再对外提供服务直到磁盘空间释放。
解决方案
检查节点的磁盘分配情况通常有以下一些常见情况导致磁盘占用率过高
有大量日志在磁盘上没有清理请清理日志。有进程在宿主机不停的写文件请控制文件大小将文件存储至OSS或者NAS。下载的或者是其他的静态资源文件占用空间过大静态资源请存储至OSS或CDN。 Attempting to xxxx
节点资源不足(EvictionThresholdMet)一般是节点资源将要达到阈值可能会触发Pod驱逐。如 Attempting to reclaim ephemeral-storage
原因描述
ephemeral storage是临时存储空间当磁盘空间使用率达到阈值会触发临时存储空间的回收任务。回收任务会尝试回收系统日志以及没有正在使用的镜像缓存等数据。当磁盘空间占用率持续增长超过90%会导致该节点上的所有容器被驱逐也就是当前节点由于磁盘压力不再对外提供服务直到磁盘空间释放。
解决方案
请注意磁盘空间的使用
避免使用“空目录”类型的挂载方式使用NAS或者其他类似方式替代。尽量避免使用“宿主机目录”类型的挂载方式以便于保证容器是无状态的可以迁移的。要注意避免在容器内大量写文件而导致容器运行时可写数据层过大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%具体原因与节点上进程使用情况相关
打开文件未释放打开管道未释放建立网络连接未释放pipe,eventpoll多出现在 NIO 网络编程未释放资源 —— selector.close()创建进程调用命令未释放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
原因描述
节点磁盘不足无法分配空间给容器镜像
解决方案
检查节点的磁盘分配情况通常有以下一些常见情况导致磁盘占用率过高
有大量日志在磁盘上没有清理请清理日志。有进程在宿主机不停的写文件请控制文件大小将文件存储至OSS或者NAS。下载的或者是其他的静态资源文件占用空间过大静态资源请存储至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表示集群节点临时存储空间不足一般是由于磁盘使用量较大导致。请参考文档上方解决方案
检查节点的磁盘分配情况通常有以下一些常见情况导致磁盘占用率过高
有大量日志在磁盘上没有清理请清理日志。有进程在宿主机不停的写文件请控制文件大小将文件存储至OSS或者NAS。下载的或者是其他的静态资源文件占用空间过大静态资源请存储至OSS或CDN。
可以对系统盘进行扩容扩大磁盘空间。 集群DNS性能瓶颈
背景
集群中的容器实例DNS解析均依赖集群内的DNS组件应用中业务请求的地址都需要经过集群DNS组件。例如代码中访问RDS、REDIS、TOP api等。如果集群dns性能不足会出现业务请求失败的问题。
集群DNS组件
默认已安装的集群组件为coredns副本数为2可选的高性能组件为localdns 是否有性能瓶颈
应用有大量DNS请求的场景(比如连接rds凡是涉及到域名地址解析的)PHP等语言自身没有连接池特性的或者应用自身没有DNS缓存的偶尔出现域名地址无法解析错误的
解决方案
一、集群默认已安装的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进行通信。
