[英]Kubernetes pod unwanted restart
我在生产环境中运行 Python 应用程序,但我的 pod 在生产环境中频繁重启。 在暂存环境中,它不会发生。
所以我认为这可能是 CPU & Memory 限制问题。 我也更新了。
进一步调试我得到137
退出代码。
更多调试我在 Kubernetes 节点内的 go 并检查容器。
使用的命令: docker inspect < container id >
这是 output:
{
"Id": "a0f18cd48fb4bba66ef128581992e919c4ddba5e13d8b6a535a9cff6e1494fa6",
"Created": "2019-11-04T12:47:14.929891668Z",
"Path": "/bin/sh",
"Args": [
"-c",
"python3 run.py"
],
"State": {
"Status": "exited",
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 0,
"ExitCode": 137,
"Error": "",
"StartedAt": "2019-11-04T12:47:21.108670992Z",
"FinishedAt": "2019-11-05T00:01:30.184225387Z"
},
OOMKilled 是错误的,所以我认为这不是问题。
使用 GKE 主版本: 1.13.10-gke.0
从技术上讲,所有 137 意味着您的进程因 SIGKILL 而终止。 不幸的是,这没有足够的信息来知道它来自哪里。 最重要的是,auditd 或 Falco 等工具可以通过记录这些类型的系统调用来帮助收集数据,或者至少让你更接近。
退出代码 137 是docker 退出代码,它告诉我们容器已被 OOM 杀手杀死。 这并不意味着容器本身达到了 memory 限制,或者它没有足够的 memory 来运行。 由于操作系统级别的 OOM 杀手正在杀死应用程序,因此 pod 和 docker 不会为容器本身注册 OOM,因为它不一定达到 memory 限制。
上面链接的文档详细介绍了如何调试错误 137,但您也可以检查节点指标以了解 memory 的使用情况,或检查节点日志以查看是否曾在操作系统级别注册过 OOM。
如果这是一个常见问题,请确保您的 python 容器包含限制,并确保集群中的其他容器设置了适当的请求和限制。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.