本文翻譯自《The Kubernetes Hierarchy of Needs》。

在我的職業生涯中，我很幸運能夠與矽谷的一些最聰明的人和最前沿的公司一起工作。在過去的幾年裡，Kubernetes一直主導著我的客戶。我認識的大多數工程師都在努力開展Kubernetes項目，成為這次技術潮流運動的一部分，以提高其市場價值。但是，即使採用Kubernetes這種瘋狂的衝動，我也目睹了許多這些項目遠未實現其最初目標。

事實是Kubernetes很複雜。生態系統正在迅速發展。這導致許多團隊將重點轉移到技術堆棧上。團隊最終討論每個單獨的組件和/或CNCF項目，而不是將產品交付給他們的客戶並根據反饋進行迭代。

在所有這些失敗中，模式已經開始從成功的Kubernetes部署中出現 - 更具體地說，這些公司用於從白板到生產的想法。我已將這些知識整合到我稱之為「Kubernetes需求層次」的內容中。

Kubernetes需求層次並不專註於單個技術組件，它是一個程序系統，使團隊專註於客戶可交付成果並協調一致以實現業務成功。其目的是在不斷變化的基礎技術領域上保持一層，在這一層大家專註於確定需要解決的問題，以便部署Kubernetes並編寫代碼，釋放到生產環境。

Kubernetes需求層次由三個連續階段組成：構建，部署，運維。這個序列對於驅動力的增強絕對至關重要。在每個階段，您的客戶必須驗證最小可行產品（或可證明的功能），然後再進入下一階段。這完成了三件事：

  • 作為強制功能，專註於可交付成果與個別技術。
  • 通過實現定義明確的里程碑，為企業和客戶提供支持。
  • 在您的團隊和關鍵利益相關者之間創建明確的期望，從而產生必要的反饋循環，以推動進度和效率。

讓我們更詳細地看一下層次結構的每個階段。

構建基礎架構：您必須部署Kubernetes。這不僅是展示進步的第一個里程碑，而且還為您提供了如何操作和與系統交互的第一個真實體驗。您和您的團隊將學習命名法，建立您在部署階段需要與之相關的可信度，並教授將加入的開發人員。此時，您是選擇部署原生Kubernetes還是像GKE這樣的託管服務並不重要。這一切都是為了進入一個可以加入服務的狀態。

很多時候，我看到開發人員在建立他們的Kubernetes環境之前嘗試回答後期問題。「我應該與Istio合作嗎？我們如何跨數據中心的集群提供服務發現？「處理這些問題會帶來不必要的複雜性。

請記住，這個階段就是提供一個可用的集群，並展示您的團隊對其組件的掌握程度。您這樣做的速度越快，團隊的可信度就越高，您的客戶就越想與您合作。

部署應用程序：這是您開始考慮客戶如何在平台上配置應用程序的地方。在構建任何內容之前，請與您的客戶一起定義基本要求。然後建立規範。

例如，如果它是一個12因素的無狀態應用程序，則無需立即提供存儲持久性解決方案。而不是關注如何解決租賃問題，首先要說明用戶如何與API進行交互並推送代碼。一旦您了解了應用程序的生命周期和客戶的能力，CI/CD管道就會變得相關。

令人驚訝的是，在許多情況下，應用程序團隊在轉換到Kubernetes時首次體驗微服務。這對您和您的團隊來說是一個巨大的機會，可以作為指導。保持技術簡單，使這個過程更容易調試和優化。不要強制執行可能會創建其他學習曲線的流程或工具使用。

如果您的客戶不願意與您合作，他們將放棄該平台，影響您的團隊品牌以及您招募其他內部客戶的能力。

運維：恭喜！您的用戶現在可以自由地推送代碼，並且對他們可以實驗和實施更改的速度感到發狂。而且您一直很聰明地了解您加入平台的人員，確保您的團隊了解客戶需求，只考慮適合現有平台功能和規模的應用程序。

不幸的是，你的工作尚未完成。您現在正在經歷第一手微服務的缺點。如果您的團隊組織得像我與之合作過的大多數人一樣，那麼核心架構師和SRE會隨時待命，因為每一個警報都會出現在PagerDuty上。您發現大多數這些基於指標的警報已不再相關。它們由他們依賴的其他服務觸發。更不用說，對於SLO來說，這是狂野的西部，你將與應用團隊攜手合作來定義它們。在事件發生期間，您會發現很多挫折感只是找到每個服務的自定義儀錶板來驗證SLI。最終的結果將是你曾經參與過的一些最大的戰爭室。

不要讓這件事發生在你身上。在這裡，您需要確定事件響應的優先順序並建立SLO。與您的客戶合作，清楚地了解客戶如何監控他們的應用，哪些工作流程最重要，以及他們是否有相關（且準確）的SLO。您的團隊將不再能夠成為每項服務的細微差別和失敗模式的專家。

有成熟的技術和CNCF項目用於記錄和獲取指標，兩者在這些環境中仍然發揮著重要作用。由於能夠提供端到端可見性，依賴性圖表和性能分析，因此跟蹤在微服務監控方面也獲得了很大的動力。我與之合作過的最好的客戶設計了可觀察性數據管道和最佳實踐，使服務所有者能夠構建性能更高，更具彈性的應用程序。您實際上可能確定您只負責監控基礎架構。這也沒關係，但要確保期望從大門出發。

這讓我回到最初帶給我們的地方。有一個商業原因首先資助了這個項目。在一天結束時，它是關於更快地提供客戶體驗。

從業務方面考慮一下。當貴公司決定發布新產品時，它們會根據客戶要求而定。這些要求推動了它們提供的功能的優先順序。對於將在何時提供的內容有一個共同的理解，並且客戶反饋和採用會告知接下來會發生什麼。早期的產品採用推動了持續的投資和產品的發展。以同樣的方式對待您的平台。使用Kubernetes Hierarchy of Needs來保持以客戶為中心，並提供一個能夠提供真正客戶價值的平台。

譯者注： 《Kubernetes實戰：高可用集群搭建,配置,運維與應用》這門實戰課可以幫助你和你的客戶順利度過這三個階段，進而可以深入的走入Kubernetes的世界！

講師主頁：tonybai_cn

講師博客: Tony Bai實戰課：《Kubernetes實戰：高可用集群搭建,配置,運維與應用》免費課：《Kubernetes基礎：開啟雲原生之門》

作者：tonybai_cn

鏈接：imooc.com/article/28956

來源：慕課網

本文原創發佈於慕課網 ，轉載請註明出處，謝謝合作


推薦閱讀：
相关文章