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

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

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

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

1、為微服務(wù)排除故障時(shí)常見(jiàn)問(wèn)題的根源

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

網(wǎng)絡(luò)

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

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

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

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

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

應(yīng)用程序

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

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

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

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

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

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

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

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

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

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

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