K8s 故障排除是簡單還是複雜？ 這是用於說明的退出代碼 1

Kubernetes (K8s)已經被認為是容器編排的事實標準。 在推出六年後，它已經達到了開發人員無法再忽視的流行程度。 然而，許多人繼續被這種相對較新的技術嚇倒。 使用 K8s 的挑戰之一是排除錯誤，因為基礎設施非常複雜。 它也相對較新，因此大多數開發人員需要一些時間才能熟悉。

儘管如此，沒有理由害怕使用 Kubernetes。 用前 Amazon Web Services 負責人和 Adob​​e 開發者生態系統負責人 Matt Asay 的話來說，“ Kubernetes 太難了，但值得痛苦。” 它是完全可以學習的，並且是許多人認為的令人生畏的謎，如下面的錯誤故障排除所示。

了解退出代碼 1

退出代碼 1 是使用 Kubernetes 時遇到的常見錯誤之一。 當容器通常由於應用程序故障而終止時，就會發生這種情況。 它也可能由於無效引用而發生，其中用於操作容器的圖像的文件引用不存在或指向不兼容的對象。

聽起來簡單明了？ 不完全是。 了解此錯誤的部分原因還在於熟悉 SIGHUP 或 Signal 7。當應用程序終止並顯示退出代碼 1 時，操作系統會發出相應的信號，稱為 Signal 7。

這只是對動態開發人員在對 Kubernetes 進行故障排除時必須處理的類型的簡單說明。 平台和其中的問題不能孤立地處理。 有必要熟悉互連繫統。 記住或熟悉不同的退出代碼也很重要，因為它們提供了診斷 pod 問題的重要提示。

無論如何，退出代碼 1 並未像命令行界面 (CLI) 中那樣顯示。 如果容器退出，CLI 會顯示“Exited (1)”行——括號中的數字是退出代碼。

診斷退出代碼 1

要開始診斷錯誤，第一步是列出所有以錯誤代碼退出的容器。 在 Docker 中，要使用的命令是“ps -la”。 對於 Kubernetes，命令是“kubectl describe pod [POD_NAME]”。

找到受影響的容器後，下一步是檢查容器引擎日誌，以查看錯誤是否歸因於無效引用，鏡像規範的“未找到”文件證明了這一點。 如果問題不是因為引用無效，下一步是在導致錯誤的容器中找到庫。 有問題的庫的調試如下。

故障排除 - 標準 DIY 流程

有多種方法可以解決退出代碼 1 錯誤，如下所述。

# 容器刪除和重新創建——這種方法就像恢復出廠設置，允許開發人員從頭開始。 所有臨時文件和瞬態條件，包括那些可能導致錯誤的文件，都將被刪除，然後仔細重新創建，以確保它們不再存在問題。

# 通過容器 bashing 排除應用程序故障——這種技術適用於容器不使用入口點並且有理由懷疑退出代碼 1 問題是由應用程序引起的情況。 bashing 需要使用 bashing 命令 (bash) 在容器內的 shell 中運行，以運行懷疑導致問題的應用程序，並檢查它是否退出並返回 Exit Code 1 錯誤。

# 無需抨擊的應用程序故障排除——也可以通過在容器外運行應用程序來識別和解決可能與應用程序相關的問題。 但是，要使其正常工作，運行應用程序的新環境應與可疑應用程序（可能）導致錯誤的先前容器的環境相似，這一點至關重要。

# 應用程序參數實驗 –也可以通過嘗試應用程序的不同配置來查找和解決導致退出代碼 1 錯誤的應用程序相關困難。 這是一個反複試驗的策略，因此需要大量的耐心。 一些可以修改的應用程序配置是內存分配、特殊開關或標誌的切換、用於連接到相關網絡的端口的更改以及環境變量的修改。

# 解決 PID 1 問題 –在某些情況下，退出代碼 1 錯誤是由 PID 1 問題或生成其他進程並導致信號傳輸的 init 進程導致的。 當運行“ps -aux”命令時 PID 顯示為“1”時，就會發生這種情況。 解決 PID 1 問題可以通過強制容器拒絕開始使用類似工具的工具來解決。 在 Kubernetes 中，可以通過共享進程命名空間（PID 5）運行容器來解決它。 在 Docker 中，可能的解決方案是將 init 參數添加到“docker-compose.yml”。

使用自動化解決方案進行故障排除

退出代碼 1 可能是一個具有挑戰性的錯誤，因為很難確定具體原因。 該問題可歸因於已知會產生相同錯誤的各種問題。 經驗不足的開發人員可能很難克服他們可能遇到的困惑和新問題。

現在容器編排領域的好處在於有可以方便地投入使用的自動化解決方案。 Kubernetes 故障排除平台旨在使用開發人員所需的所有必要工具和信息來解決複雜的 K8s 錯誤。

只需單擊幾下即可解決退出代碼 1 錯誤。 無需進行繁瑣的實驗並在此過程中使用猜測。 通過監控應用程序或整個雲基礎架構中的所有更改的時間表，可以快速識別問題。 這些故障排除平台可以提供補救說明或嚮導，並允許開發團隊自行解決錯誤，避免升級錯誤解決過程的需要。

總之

當然，Exit Code 1 的故障排除過程確實代表了 Kubernetes 中將遇到的所有錯誤。 但是，它可以很好地了解 K8s 故障排除的複雜性。 它表明沒有令人信服的理由被 Kubernetes 錯誤或使用 K8s 進行容器編排的想法嚇倒。 對於那些耐心地找到解決問題的方法的人來說，排除故障可能是一件容易的事； 對於那些在遇到一些挑戰後輕易放棄並忘記 Kubernetes 的所有好處的人來說，這很複雜。