用上Kubernetes后，我們非常興奮，團隊的運作速度也變得如此之快，以至于沒有注意到新的分歧正在悄然出現。

K8s激增，但也帶來了分歧

Kubernetes 已經存在近 10 年了。在過去五年中，我們看到各種規模的工程團隊的采用率急劇增加。從靜態網站到成熟的微服務解決方案，部署標準化和跨類型的應用程序擴展的承諾推動了這種爆發式的增長。

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

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

有些事情是標準化不了的

人們在宣傳 Kubernetes，往往避不開這個話題：標準化。這個想法是，你運行的所有內容都可以容器化，使每個服務都具有標準形狀，并具有標準連接器。

的確，Kubernetes 以標準化的方式解決了大規模部署軟件的問題。但問題在于：它沒有解決如何知道該軟件是否正在做它應該做的事情。我們根本無法標準化了解某件事是否正在做該做的事情，因為不同的應用程序解決不同的問題。

K8s破壞了DevOps

我是一名應用工程師，而且，我是一名完全擁抱 DevOps 運動的應用工程師。我稱其為一場運動，因為這對我來說就是如此。這不是一個新角色或新職責，也不是關于 CI/CD 管道或 IaC。對我來說，DevOps 就是與專家更密切地合作，他們為我編寫的代碼提供了超越本地計算機的生命力，并與他們合作以確保我的應用程序以最佳狀態運行并快速到達用戶手中。

這對我來說非常好，因為我開始了解他們面臨的挑戰，而且他們也開始看到我所面臨的限制并可以提供解決方案。我們一起創建了用戶想要的應用程序。

使用 Kubernetes，開發團隊的運行速度如此之快，以至于他們沒有注意到新的分歧正在悄然出現，當然這一次換了一個新名字：平臺工程。現在，我們有 Kubernetes 管理員可以創建我們的集群，但他們對集群上運行的內容一無所知，因為我們已經標準化了容器周圍的所有內容。

有人可能認為這很棒，因為現在應用程序（容器）和基礎設施（集群）之間的界限更加清晰。但對此，我不同意。因為在我看來，工程師必須考慮部署、服務、sidecar、服務網格、節點、節點關聯性——這樣的例子不勝枚舉。

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

不要誤會我的意思。在這些團隊之間進行良好的對話，并意識到溝通和接受他們需要不同的工具來完成各自的任務，才能讓項目能夠執行下去。平臺工程師管理從自動擴展到網絡路由的所有事務，應用工程師負責產品功能并確?？蛻臬@得最佳體驗。

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

K8s來了，監控工具也失靈了!

隨著轉向 Kubernetes，以及我們用來托管應用程序的基礎設施（例如 Pod）的短暫性，我們用于監控和調試應用程序的方法失敗了。我們正在采用在基礎設施級別使用的方法，并將其應用于應用程序調試技術，因為現在一切都是標準化的，所以一切都是基礎設施。這嚴重影響了在 Kubernetes 中構建的應用程序開發人員，以及希望為他們提供更多系統上下文的平臺工程師的服務。

K8s在支持現代應用程序開發時，維護的方法同樣需要進化。Kubernetes 并沒有讓我們的應用程序更易于觀察，只是讓它們更容易部署和迭代。這并不是一件壞事。

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

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

平臺、應用團隊各自孤立，上下文缺失

正如我所說，用戶并不關心您的基礎設施。Pod只是Kubernetes中最小的資源管理組件，他們根本不關心 Pod 上的 CPU、網絡帶寬或者是否使用服務網格。他們不在乎每項服務是 1 個還是 10 個。他們只關心你的整個系統是否響應他們的請求。

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

然而現實情況是，問題可能是 Pod，但也可能是代碼。在此階段，我們需要能夠了解問題是否局限于單個基礎設施組件（例如 Pod 或節點），或者是否影響到所有內容。這就是考慮高基數數據（例如 Pod 名稱）對于應用程序遙測變得至關重要的地方。

這就是為什么需要彌合這一差距的原因。平臺和應用工程師需要齊心協力。他們需要有關應用程序和基礎設施的上下文、深層上下文數據。他們需要將以客戶為中心的數據（例如由應用程序工程師定制的跟蹤，以提供特定于其應用程序的上下文）與以基礎設施為中心的數據（例如由平臺團隊管理的 Kubernetes 指標）相關聯，以充分了解客戶不滿意的原因。

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

當企業完成向 Kubernetes 的遷移并進入運營模式時，他們需要當心：要避免孤立作戰的方法。平臺工程涉及應用工程師的支持以及他們如何共同為客戶提供最佳服務。要提供流程、工具和文化，以便這些團隊能夠一起工作至關重要。它將確保不存在“我們和他們”的心態，從而導致糟糕的整體客戶體驗。

這是通過協作而不是控制來完成的。請記?。喝绻硞€工具，必須通過命令使用，而不是人們自發想要使用它，則該工具可能存在問題。

要建立這些無縫協作的高績效團隊，你需要使用通用技術語言充當橋梁。使用 OpenTelemetry 等工具可以通過跟蹤（以開發人員、以客戶為中心）和指標（以平臺基礎設施為中心）提供聯合思維，這將有所幫助。

平臺工程團隊和應用程序/產品工程團隊一起才能提供最佳的客戶體驗，但這些關系是需要培養的，當然這不是免費的。

簡而言之，Kubernetes 并不是讓軟件獲得獲更好性能的靈丹妙藥，幾個團隊一起協作才是至關重要的。

編輯：黃飛