POD 事件非持久性的，默认只保留 1 个小时。所以如果等的时间过长，事件中则没有事件显示。

有时候如果容器做了资源限制，比如内存限制了 1G。当容器使用的内存资源超过 1G 时，就会触发 Linux 系统的 OOM(Out Of Memory Killer)机制。当触发 OOM 后，容器进程将会被 KILL 掉，因此容器会停止。

但是在 K8S 集群中，K8S 的机制会保证 POD 中的容器一直可用，因此 K8S 会自动重新创建一个新的容器，旧的容器会一直处于停止状态。

• 企业版

  在企业版的 rancher 中，鼠标放在状态栏上，可以查看到容器重启的原因。

• 开源版

  开源版只能通过查看 POD YAML 来查看退出原因(reason)和状态码，在 status.containerStatuses.lastState 字段下可以看到具体的退出原因(reason)和状态码。

• 常见退出状态码

  • 退出代码 0 ：一般为容器正常退出
  • 退出代码 1 ：由于容器中 pid 为 1 的进程错误而失败
  • 退出代码 137 ：由于容器收到 SIGKILL 信号而失败(手动执行或“oom-killer” [OUT-OF-MEMORY])
  • 退出代码 139 ：由于容器收到 SIGSEGV 信号而失败
  • 退出代码 143 ：由于容器收到 SIGTERM 信号而失败

前面已说到，K8S 的机制会保证 POD 中的容器一直可用，因此 K8S 会自动重新创建一个新的容器，旧的容器会一直处于停止状态。因此，如果是容器中进程异常退出导致的容器重启，那么就需要通过旧容器的日志来具体定位问题。

1. 点击 POD 的查看日志

2. 在弹出窗口左下角可以看到 以前的容器 复选框

3. 勾选 以前的容器 复选框后，可以看到日志内容会发生变化。点击 回到底部 则可以看到容器退出前的错误日志

   Kubernetes 具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制、多粒度的资源配额管理能力。健康检查是在 pod 中 ，可能 容器 进程存在， pod 状态也为runing，但 容器 内部无法提供服务了（可能是因为堆内存溢出等）这种k8s自身无法判断，需要用户来提供检查方式从情况下使用的。（可以理解为提出k8s的负载均衡）.yaml，再apply -f? kubectl向api server发送指令，api server通过读取etcd内的配置信息调度kubelet，kubelet通过CRI执行 容器 环境初始化，在初始化的时候会 启 动一个pause基础 容器 ，接下来执行多个initC的初始化（线性初始化），若InitC正常退出，则进入MainC。 readness:判断 容器 内的进程是否可被外网访问，可访问，readness检测完成则 pod 的状态为：running或reading liveness：在 容器 运行的整个过程 中 ，liveness检测一直持续，当liveness检测 容器 内的进程已经是僵尸进程（不能正常提供对外访问）但进程没有停止，系统会自动执行 问题既然已经发生了，肯定得动手术刀解决它。在开始看代码之前，我们可以先来假想一下，发生服务 重 启 的 原因 可能有哪些，然后再根据可能性一条条的排查，这种方式可以快速的帮助我们分析并找到最终的问题点。 服务 重 启 的可能 原因 ： 第三方软件失效导致 容器 重 启 （MySQL、Redis、MQ等） 并发过高，导致cpu满负荷，服务宕机 重 启 容器 所需资源被其它 容器 所干扰，导致资源不够 重 启 重 启 集群 中 的coredns组件发生 重 启 ( 重 新创建)，一般是由于coredns组件压力较大导致oom，请检查业务是否 异常 ，是否存在应用 容器 无法解析域名的 异常 。如果是local-dns 重 启 ，说明local-dns的性能也不够了，需要优化。 我正在开发一个java服务,它基本上在网络文件系统 中 创建文件来存储数据.它运行在Ubuntu 18.04 LTS 中 的k8s集群 中 .当我们开始限制kubernetes(限制：内存：3Gi)的内存时, pod 开始被kubernetes OOMKILL.一开始我们认为这是java进程 中 的内存泄漏,但更深入地分析我们注意到问题是内核的内存.我们验证了查看文件/sys/fs/cgroup/memory/mem... 由于服务器 中 安装的mysql数据库数据量过大,在reboot 重 启 系统后,导致数据库 启 动不成功,然后导致rancher 启 动也不成功. 解决办法: 把mysql下data下的文件删除就可以 启 动了. 参考资料: https://blog.csdn.net/weixin_34290000/article/details/91413102 https://www.oschina.net/question/55448_2280499?sort=time rancher反复 重 启 问题.docx k8s oomkilled 错误 原因 ： 容器 使用的内存资源超过了限制。只要节点有足够的内存资源，那 容器 就可以使用超过其申请的内存，但是不允许 容器 使用超过其限制的资源。 在yaml文件的resources.limits.memory 下定义了 容器 使用的内存限制，如果 容器 中 的进程使用内存超过这个限制，就会出现oomkilled错误， 容器 被终止。 resources: limits: cpu: '8' memory: 32Gi 解决办法：1.优化程序，使之使用内存大小在范围内 2.修改.