容器（Container）退出代码 137 通常表示容器被外部进程发送了 `SIGKILL` 信号，强制终止。这个信号通常是由于以下几种原因之一导致的：
### 1. **内存不足（Out of Memory, OOM）**
这是最常见的原因。当容器内的进程消耗的内存超过了系统或容器配置允许的最大值时，Linux 内核的 OOM Killer 会启动，并选择一个或多个进程进行终止。如果被终止的进程是容器的主进程（即 PID 为 1 的进程），那么整个容器就会被杀死，退出代码为 137。
- **如何确认**：可以通过查看宿主机的内核日志（`dmesg` 或 `/var/log/kern.log`）来确认是否是 OOM Killer 终止了容器。日志中通常会包含类似以下的信息：
```
[xxxx.xxxx] Killed process 12345 (java) total-vm:123456kB, anon-rss:65432kB, file-rss:0kB
```
- **解决方案**：
- **增加内存限制**：如果你有权限，可以增加容器的内存限制，或者调整容器的资源配额。
- **优化应用程序**：检查应用程序的内存使用情况，确保没有内存泄漏或不必要的内存占用。可以使用工具如 `top`、`htop`、`ps` 或者专门的内存分析工具（如 Java 的 `jmap` 和 `jhat`）来监控和分析内存使用。
- **启用交换分区**：如果可能，可以在宿主机上启用交换分区（swap），以避免 OOM Killer 过早地终止进程。但需要注意，交换分区可能会降低性能，因此应谨慎使用。
### 2. **Docker 资源限制（cgroups）**
Docker 使用 Linux cgroups 来限制容器的资源使用，包括 CPU、内存、磁盘 I/O 等。如果容器超过了这些限制，Docker 可能会发送 `SIGKILL` 信号来终止容器。
- **如何确认**：你可以通过查看 Docker 的日志或使用 `docker stats` 命令来监控容器的资源使用情况，看看是否接近或超出了配置的限制。
- **解决方案**：
- **调整资源限制**：如果你有权限，可以调整容器的资源限制，例如增加内存、CPU 或磁盘 I/O 的配额。你可以在启动容器时使用 `--memory`、`--cpus` 等参数来设置这些限制。
- **优化应用程序**：确保应用程序在给定的资源限制内正常运行，避免过度消耗资源。
### 3. **手动或自动化工具发送 `SIGKILL`**
有时，管理员或自动化工具（如 Kubernetes、Docker Swarm 等）可能会手动或自动发送 `SIGKILL` 信号来终止容器。例如，当需要更新容器镜像、重启服务或执行维护操作时，可能会强制终止容器。
- **如何确认**：检查是否有其他进程或自动化工具在管理容器的生命周期。你可以查看 Docker 的日志或相关管理工具的日志，看看是否有相关的操作记录。
- **解决方案**：
- **确保优雅关闭**：如果你希望容器能够优雅地关闭，建议使用 `SIGTERM` 信号而不是 `SIGKILL`。`SIGTERM` 会给容器足够的时间来清理资源并正常退出。
- **调整自动化工具的配置**：如果你使用的是 Kubernetes 或其他容器编排工具，可以检查其配置，确保在终止容器时使用 `SIGTERM` 而不是 `SIGKILL`。
### 4. **容器内部进程崩溃**
虽然不太常见，但如果容器内的主进程（PID 1）崩溃并且没有正确处理信号，也可能导致容器被 `SIGKILL` 终止。某些情况下，进程可能会忽略 `SIGTERM` 信号，导致只能通过 `SIGKILL` 强制终止。
- **如何确认**：检查容器内的日志文件，看看是否有任何错误信息或异常情况。你还可以使用 `docker logs <container_id>` 查看容器的标准输出和标准错误日志。
- **解决方案**：
- **修复应用程序错误**：如果发现应用程序中有错误或崩溃，修复这些问题可以防止容器被强制终止。
- **确保正确的信号处理**：确保容器内的主进程能够正确处理 `SIGTERM` 信号，以便在收到终止信号时能够优雅地关闭。
### 5. **宿主机资源不足**
如果宿主机本身的资源（如内存、CPU、磁盘空间等）不足，可能会导致容器被强制终止。特别是当宿主机上的多个容器或进程竞争资源时，可能会触发 OOM Killer 或其他资源管理机制。
- **如何确认**：检查宿主机的资源使用情况，确保宿主机有足够的可用资源。你可以使用 `top`、`htop`、`free` 等命令来监控宿主机的资源使用情况。
- **解决方案**：
- **增加宿主机资源**：如果宿主机资源不足，考虑增加物理资源（如内存、CPU）或优化宿主机上的其他进程，释放更多资源给容器。
- **优化容器资源分配**：合理分配每个容器的资源，避免某个容器占用过多资源，影响其他容器的正常运行。
### 6. **Docker 守护进程问题**
在极少数情况下，Docker 守护进程本身可能出现问题，导致容器被意外终止。这可能是由于 Docker 版本的 bug 或配置问题引起的。
- **如何确认**：检查 Docker 守护进程的日志，看看是否有任何错误信息。你可以使用 `journalctl -u docker.service` 查看 Docker 守护进程的日志。
- **解决方案**：
- **更新 Docker**：确保你使用的是最新版本的 Docker，因为旧版本可能存在已知的 bug。
- **检查配置**：检查 Docker 的配置文件，确保没有不合理的设置或冲突。
### 总结
容器退出代码 137 通常表示容器被 `SIGKILL` 信号强制终止。最常见的原因是内存不足（OOM），但也可能是由于 Docker 资源限制、手动或自动化工具发送 `SIGKILL`、容器内部进程崩溃、宿主机资源不足或 Docker 守护进程问题。
1. **检查宿主机和容器的日志**：查看内核日志、Docker 日志以及容器内的应用日志，寻找与 `SIGKILL` 或 OOM 相关的错误信息。
2. **监控资源使用情况**：使用 `docker stats`、`top`、`htop` 等工具监控容器和宿主机的资源使用情况，确保没有资源耗尽的情况。
3. **调整资源限制**：根据实际情况，适当调整容器的资源限制，确保应用程序在给定的资源范围内正常运行。
