Kubernetes 等云原生技術使公司能夠快速構建軟件并輕松擴展。然而，由于構建面向服務的架構（微服務）和運行底層Kubernetes基礎設施的復雜性增加，調試這些基于 Kubernetes 的應用程序可能非常具有挑戰性。

錯誤是不可避免的，通常是由于軟件開發過程中的錯誤或疏忽而發生的。因此，為了讓企業跟上應用程序交付的步伐并讓最終用戶滿意，開發人員需要一種高效且有效的調試方式。這涉及查找、分析和修復這些錯誤。

本文重點介紹了五個 Kubernetes 調試挑戰以及如何解決它們。

1.由于構建和重新部署容器導致開發循環緩慢

當開發團隊采用像 Kubernetes 這樣的云原生技術時，他們的開發人員體驗會發生顯著改變，因為他們現在需要在內部開發循環中執行額外的步驟。他們不再像以前在整體環境中那樣編寫代碼并立即看到代碼更改的結果，而是必須管理外部依賴項、構建容器并實施編排配置（例如 Kubernetes YAML）才能看到影響他們的代碼更改。

有幾種方法可以解決這個 Kubernetes 調試挑戰：

• 第一個是讓您在本地開發服務并專注于單元測試而不是端到端測試，但是當服務/Web 應用程序具有身份驗證要求和對數據庫的依賴性時，這會很痛苦。
• 解決這個問題的另一種方法是使用一個名為 DevSpace 的工具，它將自動執行您的構建和部署步驟，從而使其更快。
• 最后，您還可以利用名為 Telepresence 的 CNCF 工具將本地開發環境連接到遠程 Kubernetes 集群，從而可以訪問遠程 Kubernetes 集群中的這些外部依賴項，并針對本地正在開發的服務進行即時測試反饋回路。

2.分布式應用程序的端到端流程缺乏可見性

使用 Kubernetes 時的另一個調試挑戰是全面了解應用程序的端到端流程，因為服務通常太多了。如果沒有完全可見性，就很難識別和修復錯誤。

理想情況下，您應該能夠獲得跨服務可見性，了解什么在調用什么、什么在超時等。要解決這個問題，您需要利用能夠使可觀察性和跟蹤更加無縫的工具。例如，工具 OpenTelemetry、Jaeger 和 Grafana Tempo 可以幫助您獲取重現錯誤所需的信息。這里的目標是獲取盡可能多的信息，當您這樣做時，您將能夠實時修復錯誤并最終提高應用程序的整體性能。

3.無法將調試器附加到代碼

開發人員需要的最重要的事情之一是能夠將調試器附加到他們的代碼，而使用 Kubernetes 并不能使這變得容易。是的，打印/日志語句之類的東西可以工作，但它們遠不及能夠將調試器放在某物上并單步執行代碼，特別是如果它是用戶不熟悉的新代碼庫。

解決此 Kubernetes 調試問題的兩種可能方法是：

• 在本地開發并找到模擬或啟動本地依賴項實例的方法。
• 確保代碼是可單元測試的，并專注于這些代碼，因為它們更容易編寫測試，也更容易調試。

4.使用本地更改執行集成測試的復雜設置

云原生應用程序通常由各種微服務組成。通常情況下，這些微服務相互依賴地工作并相互通信以處理更大的業務請求。

例如，社交媒體應用程序的時間線服務可能需要與用戶配置文件服務對話以確定用戶的關注者，同時可能需要與身份驗證服務對話以確定用戶的身份驗證狀態。由于微服務之間發生的這種多向的、服務到服務的通信，在部署任何更改之前對微服務執行集成測試至關重要，因為單獨的單元測試并不總能保證目標中應用程序的行為環境。

在此上下文中執行集成測試自然涉及運行多個服務并連接到（可能是遠程的）中間件和數據存儲。這需要帶來多重挑戰的技術和工具。這些挑戰包括資源有限以及生產和非生產環境之間的數據不一致；管理不同環境的不同配置；以及與管理服務版本控制、發布和部署周期相關的困難。

5.重現僅在生產/暫存中發生的問題

有時，重現在本地生產或暫存中發生的錯誤可能非常復雜。此時，您的模擬或現有值是不夠的。

你會想，我怎樣才能真正重現這個問題？我怎樣才能更快地找到問題的根源？好吧，在面對 K8s 調試挑戰時，一個名為 Telepresence 的開源工具通常是我的首選——該工具允許您訪問遠程依賴項，就像它們在本地運行一樣，并將流量從遠程服務重新路由到本地服務。

這意味著您可以實時調試它們，重現這些問題，并更快地將修復推送到您首選的版本控制和CI/CD管道。

結論

大多數組織堅持認為任何重要的軟件交付都要經過多次迭代測試，但重要的是要記住錯誤是不可避免的。能夠有效地調試應用程序是識別、理解和修復錯誤的最佳技術之一。Kubernetes 等容器技術為軟件開發人員帶來了許多好處，但也帶來了應用程序調試挑戰。幸運的是，有多種方法可以輕松應對這些挑戰。