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

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

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

說到監(jiān)控微服務(wù)，您需要在服務(wù)層面、而不是在pod層面進(jìn)行監(jiān)控。如果您嘗試在pod層面進(jìn)行監(jiān)控，將與編排系統(tǒng)發(fā)生沖突，并且可能出岔子。

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

為微服務(wù)排除故障時，網(wǎng)絡(luò)、基礎(chǔ)架構(gòu)和應(yīng)用程序等問題都很常見。

網(wǎng)絡(luò)

網(wǎng)絡(luò)層面的問題最難調(diào)試。如果問題出在網(wǎng)絡(luò)上，您需要查看套接字層統(tǒng)計信息。底層網(wǎng)絡(luò)擁有將A點連接到B點的套接字，因此您需要在網(wǎng)絡(luò)層面查看往返時間，看看數(shù)據(jù)包是否在傳輸、是否存在路由問題等。

基礎(chǔ)架構(gòu)

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

另一個常見的基礎(chǔ)架構(gòu)問題是Kubernetes API服務(wù)器過載，需要很長的時間才能響應(yīng)。每當(dāng)需要執(zhí)行某個操作，pod都要與API服務(wù)器通信——因此，如果API服務(wù)器過載，這就成了問題。

第三個基礎(chǔ)架構(gòu)問題與域名系統(tǒng)(DNS)有關(guān)。在Kubernetes中，您的服務(wù)由名稱來標(biāo)識，名稱則由DNS服務(wù)器來解析。如果這些解析很慢，您會開始看到問題。

應(yīng)用程序

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

如果您的URL構(gòu)建不正確，您會收到響應(yīng)代碼“404頁面未找到”。如果服務(wù)器過載，您會收到500錯誤。這些是應(yīng)用程序問題，只不過表現(xiàn)為基礎(chǔ)架構(gòu)問題。

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

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

在服務(wù)層面聚合數(shù)據(jù)

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

一些DevOps工程師可能想知道是否可以使用服務(wù)網(wǎng)格來聚合數(shù)據(jù)。雖然服務(wù)網(wǎng)格內(nèi)置了可觀察性工具，但您要小心：由于涉及大量數(shù)據(jù)，許多服務(wù)網(wǎng)格會采樣數(shù)據(jù);它們?yōu)槟峁┝嗽紨?shù)據(jù)，并提供了標(biāo)簽，以便您自行聚合數(shù)據(jù)。您真正需要的是一種工具，為您僅提供服務(wù)所需的數(shù)據(jù)以及服務(wù)層面的報告機(jī)制。

使用機(jī)器學(xué)習(xí)

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

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

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