用上Kubernetes后，我們非常興奮，團(tuán)隊(duì)的運(yùn)作速度也變得如此之快，以至于沒有注意到新的分歧正在悄然出現(xiàn)。

K8s激增，但也帶來了分歧

Kubernetes 已經(jīng)存在近 10 年了。在過去五年中，我們看到各種規(guī)模的工程團(tuán)隊(duì)的采用率急劇增加。從靜態(tài)網(wǎng)站到成熟的微服務(wù)解決方案，部署標(biāo)準(zhǔn)化和跨類型的應(yīng)用程序擴(kuò)展的承諾推動了這種爆發(fā)式的增長。

Kubernetes 目前正處于“炒作周期”階段。對于工程師來說，建議 Kubernetes 作為他們選擇的平臺是更容易接受的，無論他們使用的是云還是本地基礎(chǔ)設(shè)施。我們已經(jīng)看到實(shí)體零售店部署單節(jié)點(diǎn) Kubernetes 集群來管理其收銀系統(tǒng)，我們還看到電子商務(wù)網(wǎng)站在數(shù)百個數(shù)據(jù)中心部署數(shù)千個節(jié)點(diǎn)來管理正常運(yùn)行時間。

毫無疑問，Kubernetes 勢不可擋，但這股熱潮消退之時，我們也會發(fā)現(xiàn)：Kubernetes留給我們的，即便不是一地雞毛，也是分歧良多。

有些事情是標(biāo)準(zhǔn)化不了的

人們在宣傳 Kubernetes，往往避不開這個話題：標(biāo)準(zhǔn)化。這個想法是，你運(yùn)行的所有內(nèi)容都可以容器化，使每個服務(wù)都具有標(biāo)準(zhǔn)形狀，并具有標(biāo)準(zhǔn)連接器。

的確，Kubernetes 以標(biāo)準(zhǔn)化的方式解決了大規(guī)模部署軟件的問題。但問題在于：它沒有解決如何知道該軟件是否正在做它應(yīng)該做的事情。我們根本無法標(biāo)準(zhǔn)化了解某件事是否正在做該做的事情，因?yàn)椴煌膽?yīng)用程序解決不同的問題。

K8s破壞了DevOps

我是一名應(yīng)用工程師，而且，我是一名完全擁抱 DevOps 運(yùn)動的應(yīng)用工程師。我稱其為一場運(yùn)動，因?yàn)檫@對我來說就是如此。這不是一個新角色或新職責(zé)，也不是關(guān)于 CI/CD 管道或 IaC。對我來說，DevOps 就是與專家更密切地合作，他們?yōu)槲揖帉懙拇a提供了超越本地計算機(jī)的生命力，并與他們合作以確保我的應(yīng)用程序以最佳狀態(tài)運(yùn)行并快速到達(dá)用戶手中。

這對我來說非常好，因?yàn)槲议_始了解他們面臨的挑戰(zhàn)，而且他們也開始看到我所面臨的限制并可以提供解決方案。我們一起創(chuàng)建了用戶想要的應(yīng)用程序。

使用 Kubernetes，開發(fā)團(tuán)隊(duì)的運(yùn)行速度如此之快，以至于他們沒有注意到新的分歧正在悄然出現(xiàn)，當(dāng)然這一次換了一個新名字：平臺工程。現(xiàn)在，我們有 Kubernetes 管理員可以創(chuàng)建我們的集群，但他們對集群上運(yùn)行的內(nèi)容一無所知，因?yàn)槲覀円呀?jīng)標(biāo)準(zhǔn)化了容器周圍的所有內(nèi)容。

有人可能認(rèn)為這很棒，因?yàn)楝F(xiàn)在應(yīng)用程序（容器）和基礎(chǔ)設(shè)施（集群）之間的界限更加清晰。但對此，我不同意。因?yàn)樵谖铱磥恚こ處?strong>必須考慮部署、服務(wù)、sidecar、服務(wù)網(wǎng)格、節(jié)點(diǎn)、節(jié)點(diǎn)關(guān)聯(lián)性——這樣的例子不勝枚舉。

你可以說，“但這不是他們應(yīng)該擔(dān)心的，這是平臺的工作！” 但這恰恰證明上文我提到的觀點(diǎn)：現(xiàn)在存在分歧。我們推動基礎(chǔ)設(shè)施和應(yīng)用工程師一起工作，深入了解彼此的世界并了解每個部分，以便我們可以向彼此提出明智的問題。現(xiàn)在我們說，“把它留給別人吧；” 他們知道自己在做什么”，這就是我們 10 年前的情況。當(dāng)出現(xiàn)問題時，孤立的團(tuán)隊(duì)會互相指責(zé)。應(yīng)用工程師現(xiàn)在可以說：“它在我的機(jī)器上運(yùn)行，但在生產(chǎn)中停止運(yùn)行，因此平臺的工作就是修復(fù)它”，平臺工程師可以指著他們的儀表板說一切正常。

不要誤會我的意思。在這些團(tuán)隊(duì)之間進(jìn)行良好的對話，并意識到溝通和接受他們需要不同的工具來完成各自的任務(wù)，才能讓項(xiàng)目能夠執(zhí)行下去。平臺工程師管理從自動擴(kuò)展到網(wǎng)絡(luò)路由的所有事務(wù)，應(yīng)用工程師負(fù)責(zé)產(chǎn)品功能并確保客戶獲得最佳體驗(yàn)。

然而，我們看到的是，遷移到 Kubernetes 被視為結(jié)束。但第二天呢？一旦一切都在那里運(yùn)行，我們就沒有其他事可做了，對嗎？我們不需要每年升級 Kubernetes，不是嗎？

K8s來了，監(jiān)控工具也失靈了!

隨著轉(zhuǎn)向 Kubernetes，以及我們用來托管應(yīng)用程序的基礎(chǔ)設(shè)施（例如 Pod）的短暫性，我們用于監(jiān)控和調(diào)試應(yīng)用程序的方法失敗了。我們正在采用在基礎(chǔ)設(shè)施級別使用的方法，并將其應(yīng)用于應(yīng)用程序調(diào)試技術(shù)，因?yàn)楝F(xiàn)在一切都是標(biāo)準(zhǔn)化的，所以一切都是基礎(chǔ)設(shè)施。這嚴(yán)重影響了在 Kubernetes 中構(gòu)建的應(yīng)用程序開發(fā)人員，以及希望為他們提供更多系統(tǒng)上下文的平臺工程師的服務(wù)。

K8s在支持現(xiàn)代應(yīng)用程序開發(fā)時，維護(hù)的方法同樣需要進(jìn)化。Kubernetes 并沒有讓我們的應(yīng)用程序更易于觀察，只是讓它們更容易部署和迭代。這并不是一件壞事。

輕松更新應(yīng)用程序、促進(jìn)更多部署、進(jìn)行紅/綠部署和金絲雀的能力——這些都是偉大的事情，將提高應(yīng)用程序工程師支持其應(yīng)用程序的能力。它并沒有讓應(yīng)用程序開發(fā)人員更輕松地調(diào)試他們的應(yīng)用程序。最好的情況是，在 Kubernetes 成為首選部署系統(tǒng)之前，我們就處于這樣的狀態(tài)。最壞的情況是，我們引入了更多現(xiàn)在需要調(diào)查的故障點(diǎn)。

當(dāng)我們處理的服務(wù)器數(shù)量固定時，我們會將每臺服務(wù)器添加為應(yīng)用程序指標(biāo)中的一個維度。然后我們添加應(yīng)用程序的版本號。從那里，我們可以深入了解哪個版本/哪個服務(wù)器有問題——或者是否所有服務(wù)器都有問題。服務(wù)器名稱和應(yīng)用程序版本的組合是低基數(shù)數(shù)據(jù)，非常適合時間序列聚合數(shù)據(jù)庫。不過，我們現(xiàn)在所處的情況是 Pod 可以隨時重新安排，從而導(dǎo)致可能使用新節(jié)點(diǎn)。對于每次部署，我們都有一個新的 Pod 名稱，大多數(shù)時候，這都是高基數(shù)數(shù)據(jù)，傳統(tǒng)的基于指標(biāo)的系統(tǒng)很難處理。

平臺、應(yīng)用團(tuán)隊(duì)各自孤立，上下文缺失

正如我所說，用戶并不關(guān)心您的基礎(chǔ)設(shè)施。Pod只是Kubernetes中最小的資源管理組件，他們根本不關(guān)心 Pod 上的 CPU、網(wǎng)絡(luò)帶寬或者是否使用服務(wù)網(wǎng)格。他們不在乎每項(xiàng)服務(wù)是 1 個還是 10 個。他們只關(guān)心你的整個系統(tǒng)是否響應(yīng)他們的請求。

我們所處的情況是，除非代碼中有異常、HTTP 錯誤或其他類型的錯誤，否則很可能會將其作為基礎(chǔ)設(shè)施問題推送給平臺團(tuán)隊(duì)。任何與延遲相關(guān)的事情——或者對應(yīng)用工程師來說沒有意義的響應(yīng)——都會被推給平臺團(tuán)隊(duì)進(jìn)行調(diào)查。此時，平臺團(tuán)隊(duì)對應(yīng)用程序的信息很少，只能根據(jù)粗粒度指標(biāo)調(diào)查基礎(chǔ)設(shè)施問題。再說一遍，我們處于孤立的團(tuán)隊(duì)中，彼此之間不交談。

然而現(xiàn)實(shí)情況是，問題可能是 Pod，但也可能是代碼。在此階段，我們需要能夠了解問題是否局限于單個基礎(chǔ)設(shè)施組件（例如 Pod 或節(jié)點(diǎn)），或者是否影響到所有內(nèi)容。這就是考慮高基數(shù)數(shù)據(jù)（例如 Pod 名稱）對于應(yīng)用程序遙測變得至關(guān)重要的地方。

這就是為什么需要彌合這一差距的原因。平臺和應(yīng)用工程師需要齊心協(xié)力。他們需要有關(guān)應(yīng)用程序和基礎(chǔ)設(shè)施的上下文、深層上下文數(shù)據(jù)。他們需要將以客戶為中心的數(shù)據(jù)（例如由應(yīng)用程序工程師定制的跟蹤，以提供特定于其應(yīng)用程序的上下文）與以基礎(chǔ)設(shè)施為中心的數(shù)據(jù)（例如由平臺團(tuán)隊(duì)管理的 Kubernetes 指標(biāo)）相關(guān)聯(lián)，以充分了解客戶不滿意的原因。

寫在最后：K8s不是靈丹妙藥

當(dāng)企業(yè)完成向 Kubernetes 的遷移并進(jìn)入運(yùn)營模式時，他們需要當(dāng)心：要避免孤立作戰(zhàn)的方法。平臺工程涉及應(yīng)用工程師的支持以及他們?nèi)绾喂餐瑸榭蛻籼峁┳罴逊?wù)。要提供流程、工具和文化，以便這些團(tuán)隊(duì)能夠一起工作至關(guān)重要。它將確保不存在“我們和他們”的心態(tài)，從而導(dǎo)致糟糕的整體客戶體驗(yàn)。

這是通過協(xié)作而不是控制來完成的。請記住：如果某個工具，必須通過命令使用，而不是人們自發(fā)想要使用它，則該工具可能存在問題。

要建立這些無縫協(xié)作的高績效團(tuán)隊(duì)，你需要使用通用技術(shù)語言充當(dāng)橋梁。使用 OpenTelemetry 等工具可以通過跟蹤（以開發(fā)人員、以客戶為中心）和指標(biāo)（以平臺基礎(chǔ)設(shè)施為中心）提供聯(lián)合思維，這將有所幫助。

平臺工程團(tuán)隊(duì)和應(yīng)用程序/產(chǎn)品工程團(tuán)隊(duì)一起才能提供最佳的客戶體驗(yàn)，但這些關(guān)系是需要培養(yǎng)的，當(dāng)然這不是免費(fèi)的。

簡而言之，Kubernetes 并不是讓軟件獲得獲更好性能的靈丹妙藥，幾個團(tuán)隊(duì)一起協(xié)作才是至關(guān)重要的。

編輯：黃飛