解讀Kubernetes常見(jiàn)退出碼

作者：zouyee 2024-03-04 07:47:06

在Linux系統(tǒng)中，進(jìn)程退出碼的使用與Unix系統(tǒng)類似。Linux繼承了Unix的進(jìn)程管理機(jī)制，并在其基礎(chǔ)上進(jìn)行了擴(kuò)展和改進(jìn)。因此，Linux中的進(jìn)程退出碼仍然是一個(gè)重要的概念，用于幫助理解和診斷進(jìn)程的執(zhí)行狀態(tài)。

本文轉(zhuǎn)載自微信公眾號(hào)「DCOS」，作者zouyee。轉(zhuǎn)載本文請(qǐng)聯(lián)系DCOS公眾號(hào)。

一、退出碼歷史

退出碼的歷史可以追溯到Unix操作系統(tǒng)的早期。在Unix系統(tǒng)中，進(jìn)程退出碼是進(jìn)程終止時(shí)向其父進(jìn)程傳遞的一個(gè)整數(shù)值，用于表示進(jìn)程的終止?fàn)顟B(tài)。這個(gè)整數(shù)值通常在0到255之間，其中0表示進(jìn)程成功終止，其他值通常用來(lái)表示不同的錯(cuò)誤或異常情況。

進(jìn)程退出碼最初被設(shè)計(jì)用于提供一種簡(jiǎn)單的機(jī)制，使父進(jìn)程能夠了解子進(jìn)程的執(zhí)行結(jié)果。這使得父進(jìn)程能夠根據(jù)子進(jìn)程的退出碼來(lái)采取適當(dāng)?shù)男袆?dòng)，比如處理錯(cuò)誤情況或繼續(xù)執(zhí)行其他操作。

在Unix系統(tǒng)中，特定的退出碼值通常具有特定的含義，例如：

0：表示成功執(zhí)行，沒(méi)有錯(cuò)誤。
1：通常表示通用的錯(cuò)誤。
2：表示命令的語(yǔ)法錯(cuò)誤。
127：表示命令未找到。

隨著時(shí)間的推移，Unix操作系統(tǒng)的發(fā)展和不同的實(shí)現(xiàn)，進(jìn)程退出碼的含義可能有所不同，但基本的概念保持不變。

進(jìn)程退出碼的歷史可以追溯到早期的Unix系統(tǒng)，是Unix和Linux操作系統(tǒng)中的一個(gè)重要概念，為進(jìn)程間通信提供了一種簡(jiǎn)單而有效的機(jī)制。當(dāng)應(yīng)用程序或命令因致命錯(cuò)誤而終止或執(zhí)行失敗時(shí)，將產(chǎn)生 128 系列退出碼（128+n），其中 n 為信號(hào)編號(hào)。n 包括所有類型的終止代碼，如 SIGTERM、SIGKILL 等。

二、退出碼 127

退出碼 127 不是特定于 Kubernetes 的錯(cuò)誤代碼，而是 Linux 和類 Unix 操作系統(tǒng)中使用的標(biāo)準(zhǔn)退出碼。當(dāng)然，我們?cè)贙ubernetes中經(jīng)常看到它，并且通常表示容器內(nèi)執(zhí)行的命令或二進(jìn)制文件找不到。

一些標(biāo)準(zhǔn)的退出碼包括：

圖片

常見(jiàn)原因

讓我們看一下退出碼 127 的一些常見(jiàn)原因：

命令或二進(jìn)制文件未安裝Kubernetes 容器的 command 字段中指定的可執(zhí)行文件未安裝在容器的文件系統(tǒng)中。需要確保所需的二進(jìn)制文件或命令可用。
路徑或命令不正確Pod 定義中指定的命令不正確或在指定的路徑中不存在。這是錯(cuò)誤的最常見(jiàn)原因之一，通常是由于 Dockerfile 或 pod spec中的entrypoint或command輸入不正確造成的。
缺少依賴在容器內(nèi)運(yùn)行的應(yīng)用程序或腳本未安裝相關(guān)依賴。需要確保所有必需的依賴項(xiàng)包含在容器映像中。
shell 解釋器如果指定了腳本作為命令，需要確保腳本有效（例如#!/bin/bash），且在容器中可用。
shell 腳本語(yǔ)法錯(cuò)誤如果 shell 腳本退出碼是127，請(qǐng)檢查腳本是否存有語(yǔ)法錯(cuò)誤或可能阻止其執(zhí)行的問(wèn)題。
權(quán)限不足在容器內(nèi)運(yùn)行命令的用戶可能沒(méi)有執(zhí)行指定命令所需的必要權(quán)限。確保容器以適當(dāng)?shù)奶貦?quán)運(yùn)行。
鏡像兼容性問(wèn)題確保使用的容器鏡像與宿主機(jī)架構(gòu)和操作系統(tǒng)兼容。不匹配的映像可能導(dǎo)致命令找不到，比如x86的鏡像運(yùn)行在arm的機(jī)器上
卷掛載如果命令是卷掛載的文件，請(qǐng)檢查卷掛載是否配置正確，且所需的文件可以被訪問(wèn)到。
環(huán)境變量一些命令可能依賴于特定的環(huán)境變量。確保必需的環(huán)境變量設(shè)置正確。
Kubernetes RBAC 策略如果啟用了RBAC，需要確保具有執(zhí)行指定命令所需的權(quán)限。

如何排查

要排除問(wèn)題，可以使用以下命令檢查 Pod 的日志：

kubectl logs -f <pod-name>

還可以檢查 Pod 狀態(tài)，該狀態(tài)提供有關(guān) Pod 的詳細(xì)信息，包括其當(dāng)前狀態(tài)、最近事件和任何錯(cuò)誤消息。

kubectl describe pod <pod-name>

還可以為把調(diào)試容器attach到Pod 中，該容器包括一個(gè) shell（例如 BusyBox）。這允許您進(jìn)入容器并手動(dòng)檢查環(huán)境、路徑和命令的可用性。

使用 BusyBox 進(jìn)行調(diào)試的示例：

containers:
  - name: my-container
    image: my-image:latest
    command: ["/bin/sleep", "infinity"]
  - name: debug-container
    image: busybox:latest
    command: ["/bin/sh"]
    tty: true
    stdin: true

如果是高版本K8s，也可以使用Ephemeral Containers，它就是一個(gè)臨時(shí)容器。這是一個(gè)自Kubernetes v1.16中作為alpha引入的新功能，啟用臨時(shí)容器的特性也非常簡(jiǎn)單，在kubernetes v1.16之后的版本中將啟動(dòng)參數(shù)--feature-gates=EphemeralCnotallow=true配置到kube-api和kubelet服務(wù)上重啟即可。

通過(guò)仔細(xì)查看日志并排查上述幾個(gè)方向，應(yīng)該能夠確定退出碼 127 問(wèn)題的原因。

如何修復(fù)

我們知道了退出碼 127 的常見(jiàn)原因以及排查方式，現(xiàn)在讓我們看看如何修復(fù)它們。

命令或二進(jìn)制文件未安裝

如果所需的命令或二進(jìn)制文件丟失，則可能需要在容器鏡像中安裝。修改 Dockerfile 或構(gòu)建過(guò)程安裝所需軟件。

示例：

FROM alpine:latest 
RUN apk --no-cache add <package-name>

路徑或命令不正確

在 Pod 定義中指定命令時(shí)，考慮使用二進(jìn)制文件的絕對(duì)路徑。這有助于確保不受當(dāng)前工作目錄的影響， runtime可以找到二進(jìn)制文件。

示例：

containers:
  - name: my-container
    image: my-image:latest
    command: ["/usr/local/bin/my-command"]

缺少依賴項(xiàng)

導(dǎo)致命令無(wú)法運(yùn)行的原因可能是容器鏡像需要安裝額外的軟件。如果命令需要額外的設(shè)置或安裝步驟，可以使用init容器在主容器啟動(dòng)之前執(zhí)行這些任務(wù)。

示例（使用init容器安裝軟件包）：

initContainers:
  - name: install-package
    image: alpine:latest
    command: ["apk", "--no-cache", "add", "<package-name>"]
    volumeMounts:
    - name: shared-data
      mountPath: /data

shell解釋器

如果指定了腳本作為命令，需要確保腳本有效（例如#!/bin/bash），且在容器中可用。

示例：

#!/bin/bash

卷掛載

檢查Pod的配置，確保卷已正確掛載。驗(yàn)證卷名稱、掛載路徑和 subPaths是否正確。

示例：

volumes:
  - name: my-volume
    emptyDir: {}
containers:
  - name: my-container
    image: my-image:latest
    volumeMounts:
    - name: my-volume
      mountPath: /path/in/container

同時(shí)我們需要確認(rèn)Pod 定義指定的卷存在且可用。如果是持久卷（PV），需要檢查其狀態(tài)。如果是 emptyDir 或其他類型的卷，需要驗(yàn)證其是否正確創(chuàng)建和掛載。如果在卷掛載中使用了 subPaths，需要確保源目錄或文件中存在指定的 subPaths。

示例：

volumeMounts:
  - name: my-volume
    mountPath: /path/in/container
    subPath: my-file.txt

三、退出碼 137

在Kubernetes中，137退出碼表示進(jìn)程被強(qiáng)制終止。在Unix和Linux系統(tǒng)中，當(dāng)進(jìn)程由于信號(hào)而終止時(shí)，退出碼由信號(hào)編號(hào)加上128確定。信號(hào)編號(hào)為9，意味著“SIGKILL”，因此將9加上128，得到137退出碼。

當(dāng)Kubernetes集群中容器超出其內(nèi)存限制時(shí)，它可能會(huì)被Kubernetes系統(tǒng)終止，并顯示“OOMKilled”錯(cuò)誤，這表示進(jìn)程因內(nèi)存不足而被終止。此錯(cuò)誤的退出碼為137OOM代表“內(nèi)存耗盡（out-of-memory）”。

如果Pod狀態(tài)將顯示為“OOMKilled”，你可以使用以下命令查看：

kubectl describe pod <podname>

OOMKiller

OOMKiller是Linux內(nèi)核中的一種機(jī)制，它負(fù)責(zé)通過(guò)終止消耗過(guò)多內(nèi)存的進(jìn)程來(lái)防止系統(tǒng)耗盡內(nèi)存。當(dāng)系統(tǒng)內(nèi)存耗盡時(shí)，內(nèi)核會(huì)調(diào)用OOMKiller來(lái)選擇一個(gè)要終止的進(jìn)程，以釋放內(nèi)存并保持系統(tǒng)運(yùn)行。

內(nèi)核中有兩種不同的OOM Killer；一種是全局的OOM Killer，另一種是基于cgroup內(nèi)存控制器的OOM Killer，可以是cgroup v1或cgroup v2。

簡(jiǎn)單來(lái)說(shuō)是，當(dāng)內(nèi)核在分配物理內(nèi)存頁(yè)面時(shí)遇到問(wèn)題時(shí)，全局的OOM Killer 會(huì)觸發(fā)。當(dāng)內(nèi)核嘗試分配內(nèi)存頁(yè)面（無(wú)論是用于內(nèi)核使用還是用于需要頁(yè)面的進(jìn)程），并且最初失敗時(shí)，它將嘗試各種方式來(lái)回收和整理內(nèi)存。如果這種嘗試成功或者至少取得了一些進(jìn)展，內(nèi)核將繼續(xù)重試分配；如果無(wú)法釋放頁(yè)面或者取得進(jìn)展，在許多情況下它將觸發(fā)OOM Killer。

一旦OOMKiller選擇要終止的進(jìn)程，它會(huì)向該進(jìn)程發(fā)送信號(hào)，要求其優(yōu)雅地終止。如果進(jìn)程不響應(yīng)信號(hào)，則內(nèi)核會(huì)強(qiáng)制終止該進(jìn)程并釋放其內(nèi)存。

注意：由于內(nèi)存問(wèn)題而被終止的Pod不一定會(huì)被節(jié)點(diǎn)驅(qū)逐，如果其設(shè)置的重啟策略設(shè)置為“Always”，它將嘗試重新啟動(dòng)Pod。

在系統(tǒng)層面，Linux內(nèi)核為運(yùn)行在主機(jī)上的每個(gè)進(jìn)程維護(hù)一個(gè)oom_score。進(jìn)程被終止的機(jī)率取決于分?jǐn)?shù)有多高。

oom_score_adj值允許用戶自定義OOM進(jìn)程，并定義何時(shí)應(yīng)終止進(jìn)程。Kubernetes在定義Pod的Quality of Service（QoS）時(shí)使用oom_score_adj值。

K8s針對(duì)Pod定義了三種QoS，每個(gè)類型具有對(duì)應(yīng)的oom_score_adj值：

Guaranteed: -997
BestEffort: 1000
Burstable: min(max(2, 1000 — (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

其中Pod為Guaranteed QoS，則其oom_score_adj的值是-997，因此它們?cè)诠?jié)點(diǎn)內(nèi)存不足時(shí)最后一個(gè)被終止。BestEffort Pod配置的是1000，所以它們第一個(gè)被被終止。

要查看Pod的QoS，可以通過(guò)下述命令：

kubectl get pod -o jsnotallow='{.status.qosClass}'

下面是定義PodGuaranteed QoS 類型的計(jì)算策略：

Pod 中的每個(gè)容器必須有內(nèi)存 limit 和內(nèi)存 request。
對(duì)于 Pod 中的每個(gè)容器，內(nèi)存 limit 必須等于內(nèi)存 request。
Pod 中的每個(gè)容器必須有 CPU limit 和 CPU request。
對(duì)于 Pod 中的每個(gè)容器，CPU limit 必須等于 CPU request。

退出碼137通常有兩種情況：

1. 最常見(jiàn)的原因是與資源限制相關(guān)。通常情況下，Kubernetes超出了容器的分配內(nèi)存限制。

2. 另一種情況是手動(dòng)干預(yù) - 用戶或腳本可能會(huì)向容器進(jìn)程發(fā)送“SIGKILL”信號(hào)，導(dǎo)致此退出碼。

如何排查

檢查Pod日志

診斷OOMKilled錯(cuò)誤的第一步是檢查Pod日志，查看是否有任何內(nèi)存相關(guān)的錯(cuò)誤消息。

kubectl describe pod <podname>
State:          Running
       Started:      Fri, 12 May 2023 11:14:13 +0200
       Last State:   Terminated
       Reason:       OOMKilled
       Exit Code:    137
       ...

您還可以查詢Pod日志：

cat /var/log/pods/<podname>

當(dāng)然也可以通過(guò)(標(biāo)準(zhǔn)輸出)

kubectl logs -f <podname>

監(jiān)視內(nèi)存使用情況

使用監(jiān)視系統(tǒng)（如Prometheus或Grafana）監(jiān)視Pod和容器中的內(nèi)存使用情況。這可以幫助我們排查出哪些容器消耗了過(guò)多的內(nèi)存從而觸發(fā)了OOMKilled錯(cuò)誤，同時(shí)也可以在容器宿主機(jī)使用dmesg查看當(dāng)時(shí)oomkiller的現(xiàn)場(chǎng)

使用內(nèi)存分析器

使用內(nèi)存分析器（如pprof）來(lái)識(shí)別可能導(dǎo)致過(guò)多內(nèi)存使用的內(nèi)存泄漏或低效代碼。

如何修復(fù)

以下是OOMKilled Kubernetes錯(cuò)誤的常見(jiàn)原因及其解決方法。

容器內(nèi)存限制已達(dá)到

這可能是由于在容器指定的內(nèi)存限制值設(shè)置不當(dāng)導(dǎo)致的。解決方法是增加內(nèi)存限制的值，或者調(diào)查導(dǎo)致負(fù)載增加的根本原因并進(jìn)行糾正。導(dǎo)致這種情況的常見(jiàn)原因包括大文件上傳，因?yàn)樯蟼鞔笪募赡軙?huì)消耗大量?jī)?nèi)存資源，特別是當(dāng)多個(gè)容器在一個(gè)Pod內(nèi)運(yùn)行時(shí)，以及突然增加的流量量。

因?yàn)閼?yīng)用程序內(nèi)存泄漏,容器內(nèi)存使用達(dá)到上限

需要調(diào)試應(yīng)用程序來(lái)定位內(nèi)存泄漏的原因，

所有Pod使用的總內(nèi)存大于節(jié)點(diǎn)可用內(nèi)存

通過(guò)增加節(jié)點(diǎn)可用內(nèi)存來(lái)增加節(jié)點(diǎn)內(nèi)存，或者將Pod遷移到內(nèi)存更多的節(jié)點(diǎn)。當(dāng)然也可以調(diào)整運(yùn)行在節(jié)點(diǎn)上的Pod的內(nèi)存限制，使其符合內(nèi)存限制，注意你還應(yīng)該注意內(nèi)存請(qǐng)求設(shè)置，它指定了Pod應(yīng)該使用的最小內(nèi)存量。如果設(shè)置得太高，可能不是有效利用可用內(nèi)存，關(guān)于資源配置相關(guān)的建議，可以參看VPA組件

在調(diào)整內(nèi)存請(qǐng)求和限制時(shí)，當(dāng)節(jié)點(diǎn)過(guò)載時(shí)，Kubernetes按照以下優(yōu)先級(jí)順序終止Pod：

沒(méi)有請(qǐng)求或限制的Pod。
具有請(qǐng)求但沒(méi)有限制的Pod。
使用超過(guò)其內(nèi)存請(qǐng)求值的內(nèi)存 - 指定的最小內(nèi)存值 - 但低于其內(nèi)存限制的Pod。
使用超過(guò)其內(nèi)存限制的Pod。

如何預(yù)防

有幾種方法可以防止OOMKilled的發(fā)生：

設(shè)置適當(dāng)?shù)膬?nèi)存限制

通過(guò)壓測(cè)及監(jiān)控來(lái)確定應(yīng)用程序的內(nèi)存使用，通過(guò)上述方式配置容器允許使用的最大內(nèi)存量。過(guò)度保守可能會(huì)導(dǎo)致因資源利用率低效而造成資金的浪費(fèi)，同時(shí)低估會(huì)導(dǎo)致頻繁出現(xiàn)OOMKilled現(xiàn)象。

最佳做法是利用K8s提供的HPA機(jī)制，當(dāng)應(yīng)用程序的內(nèi)存使用升高時(shí)自動(dòng)增加Pod副本數(shù)量。