人們聽到“微服務”時，常常想到Kubernetes，這是一種聲明式容器編排系統。由于具有聲明性，Kubernetes將微服務視作實體，這在故障排除方面帶來了一些難題。不妨看看為什么在Kubernetes環境下為微服務排除故障可能具有挑戰性，以及一些相應的最佳實踐。

想了解為什么為微服務排除故障可能具有挑戰性，不妨看一個例子。

如果您在Kubernetes中有一個應用程序，就可以將它部署為pod，利用Kubernetes對其進行擴展。該實體是您可以監控的pod。若使用微服務，您不應該監控pod;相反，應該監控服務。所以您可能擁有整體式工作負載(部署為pod的單個容器)并對其進行監控，但如果您的服務由幾個不同的pod組成，就需要了解這些pod之間的相互關系，才能明白服務是如何運行的，以及進行監控，如果不這么做，您認為的事件可能不是真正的事件(即可能對服務的運作并不重要)。

說到監控微服務，您需要在服務層面、而不是在pod層面進行監控。如果您嘗試在pod層面進行監控，將與編排系統發生沖突，并且可能出岔子。

1、為微服務排除故障時常見問題的根源

為微服務排除故障時，網絡、基礎架構和應用程序等問題都很常見。

網絡

網絡層面的問題最難調試。如果問題出在網絡上，您需要查看套接字層統計信息。底層網絡擁有將A點連接到B點的套接字，因此您需要在網絡層面查看往返時間，看看數據包是否在傳輸、是否存在路由問題等。

基礎架構

pod重新啟動時，基礎架構問題會顯露出來(Kubernetes中的崩潰循環)。發生這種情況的原因有很多。比如說，如果您的服務中有一個pod無法訪問Kubernetes數據存儲，Kubernetes會重新啟動它。您需要跟蹤支持該服務的那些pod的狀態。如果您看到數次或頻繁的pod重新啟動，這就成了問題。

另一個常見的基礎架構問題是Kubernetes API服務器過載，需要很長的時間才能響應。每當需要執行某個操作，pod都要與API服務器通信——因此，如果API服務器過載，這就成了問題。

第三個基礎架構問題與域名系統(DNS)有關。在Kubernetes中，您的服務由名稱來標識，名稱則由DNS服務器來解析。如果這些解析很慢，您會開始看到問題。

應用程序

有幾個常見的應用程序問題可能導致重新啟動和錯誤。比如說，如果您的服務負載均衡未起作用，比如說由于您的URL發生了變化或者負載均衡系統沒有執行正確的操作，就可能會導致某一個pod過載，從而導致它重新啟動。

如果您的URL構建不正確，您會收到響應代碼“404頁面未找到”。如果服務器過載，您會收到500錯誤。這些是應用程序問題，只不過表現為基礎架構問題。

2、微服務故障排除方面的最佳實踐

以下是有效識別和排除微服務問題的兩個最佳實踐。

在服務層面聚合數據

您需要使用一款工具來提供在服務層面聚合的數據(即日志)，以便可以查看出現了多少次pod重新啟動和錯誤代碼等。這與當今大多數DevOps工程師使用的方法不同;在后一種方法中，每次pod重新啟動都是單獨的警報，導致工程師陷入到可能只是正常操作或Kubernetes自我糾正的警報中。

一些DevOps工程師可能想知道是否可以使用服務網格來聚合數據。雖然服務網格內置了可觀察性工具，但您要小心：由于涉及大量數據，許多服務網格會采樣數據;它們為您提供了原始數據，并提供了標簽，以便您自行聚合數據。您真正需要的是一種工具，為您僅提供服務所需的數據以及服務層面的報告機制。

使用機器學習

在試圖識別和解決微服務問題時，您需要監控屬于服務的每個pod在如何運行。這意味著監控延遲、進程重啟次數和網絡連接錯誤等度量指標。有兩種方法可以做到這一點：

• 設置閾值——比如說，如果有20多個錯誤，就設置警報。在像Kubernetes這樣的動態系統中，這種方法有點原始，尤其是在使用微服務的情況下。
• 確立基準——使用機器學習來研究度量指標隨時間的推移而如何變化，構建機器學習模型，以預測該指標在未來有怎樣的表現。如果指標偏離基準，您會收到一則警報，指明哪些參數導致機器學習算法認為存在問題。
• 我建議別嘗試設置閾值——你會被大量警報所淹沒，這會導致警報疲勞。相反，應使用機器學習。久而久之，機器學習算法可以在問題出現之前發出警報。

參考：https://www.kubernetes.org.cn/9812.html