在这篇文章中，我们将深入分析Kubernetes中的典型退出码127与137，解释它们是什么，K8s和Docker中常见的原因是什么，以及如何修复 编辑｜zouyee 退出码历史 退出码的历史可以追溯到...当Kubernetes集群中容器超出其内存限制时，它可能会被Kubernetes系统终止，并显示“OOMKilled”错误，这表示进程因内存不足而被终止。...如何修复 以下是OOMKilled Kubernetes错误的常见原因及其解决方法。 容器内存限制已达到 这可能是由于在容器指定的内存限制值设置不当导致的。...导致这种情况的常见原因包括大文件上传，因为上传大文件可能会消耗大量内存资源，特别是当多个容器在一个Pod内运行时，以及突然增加的流量量。...过度保守可能会导致因资源利用率低效而造成资金的浪费，同时低估会导致频繁出现OOMKilled现象。 HPA 最佳做法是利用K8s提供的HPA机制，当应用程序的内存使用升高时自动增加Pod副本数量。
最近看了一篇文章：Tracking Down “Invisible” OOM Kills in Kubernetes，其讲述的是由于内存不足导致Pod中的进程被killed，但Pod并没有重启，也没有任何日志或...kubernetes事件，只有一个"Exit Code: 137"的信息，导致难以进一步定位问题。...大意就是只有Pod中的PID 1被OOM kill时才会出现OOMKilled状态，并重启容器，此时我们可以清除地看到OOM信息。...但在出现问题的场景中，被kill的并不是PID 1，这就导致容器或kubernetes无法记录相关信息，且不会重启容器。这种情况下只能通过查看系统日志才能发现相关信息。...出现"被隐藏的OOM"的原因可能是Pod中单独启动了多个独立的进程(进程间无父子关系)，在我的场景中就是单独启动了一个脚本进程，当内存不足的时候会导致kill脚本进程。
存量 Pod 在节点上也有可能发生高负载，这时我们在节点上部署 Pod-Problem-Detecor、NodeProblem-Detecor，检测出哪个 Pod 会导致节点高负载，哪些 Pod 属于敏感...例如在 Pod 下线前，销毁的时候不保证已经剔除路由；又比如在滚动更新时，可能上一批还没有添加路由，下一批就开始销毁重建。...对于运行阶段，例如容器异常自动重启，或者 Pod 其中一个容器通过原地生成的方式启动，这些场景就会绕过前面提到的滚动更新和删除保护。所以还要在运行阶段保证业务之间的快速同步。...这样导致一个问题，如果进行强制销毁，可能老容器会残留，新容器又起来了，这时老的容器会影响节点。...所以容器销毁阶段卡住会影响容器销毁重建这个基本需求，而且它的原因是复杂多样的，在大规模系统环境中更容易出现，而已有的自愈机制是没有涵盖这种场景的，所以我们就需要提供一种全新的自愈机制。
K8s 错误 当 Kubernetes 集群中的容器超出其内存限制时，Kubernetes 系统可能会终止该容器，并显示“OOMKilled”错误，该错误表示该进程因内存不足而终止。...OOMKiller 是一种最后的手段机制，仅在系统面临内存不足的危险时才调用。虽然它可以帮助防止系统因内存耗尽而崩溃，但重要的是要注意，终止进程可能导致数据丢失和系统不稳定。...这可以帮助您确定哪些容器消耗了太多内存并触发了 OOMKilled 错误。 使用内存性能分析器：使用 pprof 等内存性能分析器来识别可能导致内存过度使用的内存泄漏或低效代码。...4OOMKilled K8s 错误和解决的常见原因 已达到容器内存限制。这可能是由于在容器清单中指定的内存限制值上设置了不适当的值，这是允许容器使用的最大内存量。...这也可能是由于应用程序遇到比正常情况更高的负载。解决方法是增加内存限制的值，或调查负载增加的根本原因并进行修正。
本次升级除了更新基础JDK镜像，既没有业务代码的变更也没有修改配置，到底是什么原因导致的呢？...带着十分困惑的心情，我和团队开启了漫长的异常排查之旅。 1） 当时出现服务重启，第一感觉是启动耗时长导致探测接口超时超过一定阈值导致重启。...2）接下来是怀疑pod所在的宿主机会不会是内存不足导致的呢？于是登陆宿主机查看内存 $ free -m 总内存128g, 可用内存有60g以上，宿主机的物理内存是足够的。...4、根因定位 虽然定位到是OOM原因导致的，但是为什么升级了JDK就导致OOM呢？ 经过jinfo命令查看JVM启动参数终于发现根本原因。...原来服务反复OOM被kill掉是因为“-XX:MaxHeapSize”参数失效导致Java进程使用默认值32g（物理机的1/4）超出了pod分配的limit上限8g。
K8s 错误 当 Kubernetes 集群中的容器超出其内存限制时，Kubernetes 系统可能会终止该容器，并显示“OOMKilled”错误，该错误表示该进程因内存不足而终止。...OOMKiller 是一种最后的手段机制，仅在系统面临内存不足的危险时才调用。虽然它可以帮助防止系统因内存耗尽而崩溃，但重要的是要注意，终止进程可能导致数据丢失和系统不稳定。...这可以帮助您确定哪些容器消耗了太多内存并触发了 OOMKilled 错误。 使用内存性能分析器：使用 pprof 等内存性能分析器来识别可能导致内存过度使用的内存泄漏或低效代码。...OOMKilled K8s 错误和解决的常见原因 已达到容器内存限制。这可能是由于在容器清单中指定的内存限制值上设置了不适当的值，这是允许容器使用的最大内存量。...这也可能是由于应用程序遇到比正常情况更高的负载。解决方法是增加内存限制的值，或调查负载增加的根本原因并进行修正。
那超级节点又是什么呢？...超级节点的优势隔离性更强Pod 之间是虚拟机级别的强隔离，不存在 Pod 之间干扰问题(如某个 Pod 磁盘 IO 过高影响其它 Pod)，也不会因底层故障导致大范围受影响。...图片免运维无需运维节点:Pod 重建即可自动升级基础组件或内核到最新版。如果 Pod 因高负载或其它原因导致长时间无心跳上报，底层虚拟机也可以自动重建，迁移到新机器并开机运行实现自愈。...图片成本更省为避免扩容慢，或者因某机型+规格的机器资源不足导致扩容失败，普通节点往往会预留一些 buffer，造成资源的闲置和浪费。...图片而超级节点可按需使用，POD 销毁立即停止计费，由于 POD 规格一般不大，且机型可根据资源大盘情况自动灵活调整，不容易出现售罄的情况，无需预留 buffer，极大提升资源利用率，降低成本。
下意识的我会以为是程序运行超过了所指定的Xmx参数，但是平台运行的情况我还是了解的，之前即便访问量大的是的也是个别服务或者数据库压力大，不会导致这两天无规律性质的死掉服务，几乎什么服务都可能会进行被killed...查看磁盘空间 top #查看CPU 并未发现异常 这里插句话如果磁盘空间超过85%，会导致docker启动回收垃圾机制，删除你的镜像一类的，会导致你的pod启动异常 运行内存不足也会导致pod...启动异常 无异常，就更令我感到诧异并无助 解决问题最怕的就是没发现问题 然后先经过治理表面先及时解决平台运行问题 kubectl delete pod XXX 经过重启pod，然后重新运行没问题的...先了解一下报错内容，它因为过多的连接等才会进行导致不断的kill容器 我们查看一下docker的各项资源 查看无用的镜像、无用的容器卷、无用的容器多不多 docker images docker volume...volume prune #清理无用的容器卷 经过我的排查就是因为docker无用资源过多导致的触发机制进行不断删除容器 进行清理！！！
本文摘自 Kubernetes 学习笔记 背景 K8S 中 Pod 如果有多个 container，正常情况会同时启动或销毁，但有些场景对容器启动或销毁顺序有依赖，就可能存在一些问题，比如在 istio...容器化过渡的应用，业务容器启动时需要调用其它服务(比如从配置中心拉取配置)，如果失败就退出，没有重试逻辑，而当 envoy 启动更慢时，业务容器调用其它服务失败，导致 pod 启动失败，如此循环 (参考...Pod 销毁时: 业务容器和 envoy 同时收到 SIGTERM，envoy 不再处理增量连接，但业务容器在 graceful shutdown 过程中可能需要调用另外的服务（比如通知其它清理进行清理操作...原因总结 总结一下原因就是，很多相关问题都是与 pod 生命周期管理有关，涉及很多场景，不仅仅是局限于一两个场景。...不会退出，导致 Job 永不退出 (Job 需要等所有 container 停止才算退出) 升级 sidecar 版本会重启所有 Pod，对大集群不友好，能够支持单个 container 升级就好了
Burstable：Pod 至少有一个容器有内存或者 CPU 请求且不满足 Guarantee 等级的要求，即内存/CPU 的值设置的不同。...BestEffort：容器必须没有任何内存或者 CPU 的限制或请求。...如果没有设置limits，pod可以使用全部空闲的cpu资源。 对于内存：当一个pod使用内存超过了设置的 limits，pod中 container 的进程会被 kernel 因OOM kill掉。...当container因为OOM被kill掉时，系统倾向于在其原所在的机器上重启该container或其他重新创建一个pod。...比如 filebeat、logstash、fluentd等 建议：k8s 安装时，建议把 Swap 关闭，虽然 Swap 可以解决内存不足问题，但当内存不足使用Swap时，系统负载会出现过高，原因是 swap
Pod 中容器重启原因 查看事件信息（1小时内，超过1个小时的事件查看需要开启 集群事件持久化）。...Describe Pod 查看相关容器退出状态码, 例如状态码为 137 ,一般是收到 kill -9 信号导致，可能是容器本身 OOM ，K8S 重新调度Pod 等，若为其他退出码，可能是容器主进程（...还没有销毁，导致新Pod 无法正常挂载 PVC（PVC 还被旧Pod 挂载）的情况。...超级节点配置 pod 磁盘回收策略（重启容器）不生效？ 可能原因：容器写入层可能挂载的是 emptyDir 卷， 只重启容器是无法释放的，只能重建 Pod 清理。...超级节点 Pod 通过 9100 端口获取metrics 数据超时请求不到？ 可能原因： 1.在容器中请求目的端为所在 pod 导致（产品限制），需要在该 pod 之外的客户端才能访问。 2.
）来定义容器间的访问策略，并兼容Calico的网络策略 在Terway网络插件中，每个Pod都拥有自己网络栈和IP地址。...如果某短时间业务快速增长，导致pod大量消耗可用ip，这个时候就有可能因前期规划不充足导致vSwitch的可用ip不足 这个时候新创建的pod状态为ContainerCreating，describe查看...这是因为Terway分配给pod ip时的策略是，分配node所在可用区中的vSwitch对应的ip，因此，扩容就需要扩容同一可用区的交换机 在初始化集群新建交换机以及扩容交换机的时候都应该考虑，因Pod...Terway使用底层虚拟化底层的网络资源打通容器网络，网络资源的创建和释放需要一系列的API调用，如果在Pod创建销毁时频繁调用API会导致Pod配置时间较长。...eni辅助网卡个数以及最大pod数灵活设置 3.3 重启terway 重启所有Terway的pod以便快速刷新缓存生效 # kubectl -n kube-system delete pod -l app
问题 大家在使用 Kubernetes 时，会遇到创建Pod失败，这时会分析什么原因导致创建Pod失败？...Pod status 状态解释 [1] CrashLoopBackOff：容器退出，kubelet正在将它重启 InvalidImageName：无法解析镜像名称 ImageInspectError：无法校验镜像...，比如 kill -9 是 SIGKILL，ctrl+c 是 SIGINT) 一般程序自身原因导致的异常退出状态区间在 1-128 (这只是一般约定，程序如果一定要用129-255的状态码也是可以的)...这可以由用户或由docker守护程序来发起，手动执行：docker kill 137 比较常见，如果 pod 中的limit 资源设置较小，会运行内存不足导致 OOMKilled，此时state 中的...小结 在排查Pod为什么创建失败时，首先看 Pod 容器退出状态码是非常有用的，能快速的定位问题原因。
如果您是 Kubernetes 用户，容器故障是 pod 异常最常见的原因之一，了解容器退出码可以帮助您在排查时找到 pod 故障的根本原因。...如果容器以退出码 0 终止怎么办？ 检查容器日志，确定哪个库导致容器退出； 查看现有库的代码，并确定它触发退出码 0 的原因，以及它是否正常运行。...该退出码可能的原因是： 容器引擎停止容器时触发，例如使用 docker stop 或 docker-compose down 命令时； 由 Kubernetes 将 Pod 设置为 Terminating...退出码 255：退出状态超出范围 当您看到退出码 255 时，意味着容器的 entrypoint 以该状态停止。这意味着容器停止了，但不知道是什么原因。 如果容器以退出码 255 终止怎么办？...每当 pod 中容器发生故障，或者 Kubernetes 指示 pod 出于任何原因终止时，容器将关闭并记录退出代码。识别退出代码可以帮助您了解 pod 异常的根本原因。
Running Pod 已经被绑定到了一个节点，所有容器已被创建。至少一个容器正在运行，或者正在启动或重新启动。 Succeeded 所有容器成功终止，也不会重启。...Unknown 由于一些原因，Pod 的状态无法获取，通常是与 Pod 通信时出错导致的。 ?...每次探测可能有如下之一的结果： Success：容器诊断通过 Failure：容器诊断失败 Unknown：诊断失败，因此不应采取任何措施 kubelet 可以选择性地对运行中的容器进行两种探测器执行和响应...： livenessProbe：指示容器是否正在运行，如果活动探测失败，则 kubelet 会杀死容器，并且容器将受其 重启策略 的约束。...Pod lifetime 通常，Pod 不会消失，除非人为或者控制器销毁它们。
一个pod可能泄漏两个memory cgroup数量配额。即使pod百分之百发生泄漏， 那也需要一个节点销毁过三万多个pod之后，才会造成后续pod创建失败。...一旦出现会导致新 pod 无法创建，已有 pod不受影响，但pod 漂移到有问题的节点就会失败，直接影响业务稳定性。因为是内存泄露，直接重启机器可以暂时解决，但还会再次出现。...kmem accounting 中的 memory.kmem.limit_in_bytes 就可能会导致不能彻底删除 memcg 和对应的 cssid，也就是说应用即使已经删除了 cgroup (/sys...这个问题可能会导致创建容器失败，因为创建容器为其需要创建 cgroup 来做隔离，而低版本内核有个限制：允许创建的 cgroup 最大数量写死为 65535，如果节点上经常创建和销毁大量容器导致创建很多...一旦出现会导致新pod无法创建,已有 pod不受影响，但pod 漂移到有问题的节点就会失败，直接影响业务稳定性。因为是内存泄露，直接重启机器可以暂时解决，但还会再次出现。
直接部署一个容器可能会更加容易，每个容器都有不同的配置和功能，k8s需要对这些容器进行管理（重启、检测等），那么为了避免在容器这个实体上增加更多的属性，就产生了pod这个概念。.../start.sh & 那么kubelet创建了包含这个容器的pod之后运行完这个命令，则会根据配置发生两种情况： 如果pod未配置RC，则认为该pod执行结束，将立刻销毁该pod。...有一个或多个容器未被创建，可以通过kubectl get po ** 查看原因。 running 运行中。...容器以不为0的状态码终止，自动重启 Never 无论何种状态，都不会重启 其中，Pod的重启策略与控制方式息息相关，不同的控制器对pod的重启策略要求不一样： RC和DaemonSet：必须设置为Always...Preemption）：scheduler的行为，当一个新的pod因资源无法满足而不能调度时，scheduler可能会选择（跨节点或本节点）驱逐部分低优先级的pod实例来满足调度 批处理调度 Job 可以通过
将该 node 标记不可调度，并将其已有的 pod 驱逐到其它节点，这样重启dockerd就会让该节点的pod对应的容器删掉，容器相关的日志(标准输出)与容器内产生的数据文件(可写层)也会被清理： kubectl...drain 10.179.80.31 重启 dockerd: systemctl restart dockerd 取消不可调度的标记: kubectl uncordon 10.179.80.31 定位根因...，彻底解决 问题定位方法见附录，这里列举根因对应的解决方法： 日志输出量大导致磁盘写满: 减少日志输出 增大磁盘空间 减小单机可调度的pod数量 可写层量大导致磁盘写满: 优化程序逻辑，不写文件到容器内或控制写入文件的大小与数量...镜像占用空间大导致磁盘写满: 增大磁盘空间 删除不需要的镜像 附录 查看docker的磁盘空间占用情况 $ docker system df -v [docker-system-df.png] 定位容器写满磁盘的原因...ps 结果匹配可找出对应容器，最后就可以推算出是哪些 pod 搞的鬼 找出可写层数据量大的 pod 可写层的数据主要是容器内程序自身写入的，无法控制大小，可写层越大说明容器写入的文件越多或越大，通常是容器内程序将
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
