Kubernetes pod 不需要重啟

Question

我在生產環境中運行 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

Answer 1

從技術上講，所有 137 意味着您的進程因 SIGKILL 而終止。 不幸的是，這沒有足夠的信息來知道它來自哪里。 最重要的是，auditd 或 Falco 等工具可以通過記錄這些類型的系統調用來幫助收集數據，或者至少讓你更接近。

Answer 2

退出代碼 137 是docker 退出代碼，它告訴我們容器已被 OOM 殺手殺死。 這並不意味着容器本身達到了 memory 限制，或者它沒有足夠的 memory 來運行。 由於操作系統級別的 OOM 殺手正在殺死應用程序，因此 pod 和 docker 不會為容器本身注冊 OOM，因為它不一定達到 memory 限制。

上面鏈接的文檔詳細介紹了如何調試錯誤 137，但您也可以檢查節點指標以了解 memory 的使用情況，或檢查節點日志以查看是否曾在操作系統級別注冊過 OOM。

如果這是一個常見問題，請確保您的 python 容器包含限制，並確保集群中的其他容器設置了適當的請求和限制。