你真的需要Kubernetes嗎？

作者丨Martin Cerruti

策劃丨萬佳

引入 Kubernetes 時不能太草率，因為它不一定適合你。本篇文章探討了在使用 Kubernetes 前應該考慮的一些因素。

過去幾年，Docker 成為一種非常受歡迎的應用程序構建、交付和運行方式。使用 Docker，只需一次構建應用程序，即可隨處運行。雖然這是軟體開發方式的一次巨大飛躍，但它也帶來一些新挑戰。對初學者而言，在 Docker 容器和主機間建立網絡連接不是一件簡單的事。這與我們過去傳統的聯網方法有很大不同，它要求具備一定的技能才能做好。

另一個挑戰是存儲。默認情況下，Docker volumes 被綁定到它們的主機。這意味著，如果我們希望運行一個服務的多個實例，並讓它們共享 volume，就不得不設置好複製機制或配置成使用雲存儲服務。

雖然 Docker 被視為一項了不起的技術，但缺少一個能將所有技術聯繫在一起的組件。而 Kubernetes 正是那個組件。尤其是通過 Azure、AWS 等雲平台提供的全託管形式，Kubernetes 解決了所有這些問題，並通過一系列概念將它們從最終用戶那裡抽象出來。

Kubernetes，也被稱為 k8s，它由谷歌開發，用於解決在全球範圍內運行成千上萬個應用程序時所面臨的問題。最近一兩年，k8s 的採用正快速增長，有越來越多的公司尋找精通 k8s 的工程師。Kubernetes 雖然在 Spotify、ING 和許多其他公司的實施取得令人驚歎的成功，但它並非所有公司的終極解決方案。

https://kubernetes.io/case-studies/spotify/

https://kubernetes.io/case-studies/ing/

事實上，在生產環境中運行 Kubernetes 也會帶來一些嚴重問題。在這篇文章，我們將探討在決定使用 Kubernetes 前應考慮的一些因素。

1 學習曲線

Kubernetes 有自己的運行機制。它是圍繞幾個概念設計的，熟悉其中的大多數概念是在生產環境中運行 Kubernetes 的必要條件。所以，這就引入了一個相當陡峭的學習曲線。不僅是對於系統管理員，對於開發人員也是如此。

https://kubernetes.io/docs/concepts/

下面這個圖展示了 Kubernetes 架構的高級概述

Kubernetes 架構（Kubernetes Components，CC-BY 4.0）

https://kubernetes.io/docs/concepts/overview/components/

所有這些管理器、調度器和伺服器負責全天候運行你的應用程序，即 k8s 中的工作負載。它們各司其職，並實現了 Kubernetes 的一個或多個概念。

在使用 Docker 或從事比較傳統的系統管理工作時，你不一定會用到這些概念。每次，你在集群部署一個新的應用程序時，Kubernetes 都會為你的應用程序創建最少數量的以下對象：

表示應用程序的Deployment對象；

ReplicaSet用於擴展與部署相關的Pod；

可選，一個或多個Service處理部署的網絡需求；

表示實際容器的一個或多個Pod。這是 Kubernetes 架構中的最小組件。

如你所見，對一個不熟悉 Kubernetes 的人來說，這可能是很大的負擔。更重要的是，這些對象中的每一種都有無數種配置方式，可以極大改變它們的行為。

事實上，啟動和運行 Kubernetes 並正確配置它的所有組件，這需要大量時間。託管 Kubernetes 供應商承擔了大量底層的配置和集成，但是，有一些工作將不可避免地滲透到開發人員那裡，至少，他們需要基本熟練地使用 Kubernetes 才能正確完成工作。

你不一定非得需要 Kubernetes 來運行應用程序，它只是運行生產軟體的眾多選項之一。

你應該仔細衡量一下，遷移成本（學習曲線的增加和配置開銷）和遷移好處。

2 應用程序需要擴展嗎？

Kubernetes 的一個關鍵特性是能對應用程序的各個部分進行擴展。流量會自動在各個Pod間路由和分配，如果配置完成，Kubernetes 甚至可以自動為你縮放Pod。

如果一個應用程序有一個或多個熱點組件需要處理突發事件，那這個特性就很有價值。例如，在推出新擴展或新特性時，在線遊戲的身份驗證服務可能會出現登錄請求突然增加的情況。或者是那些在發行後變得非常受歡迎並需要快速擴展基礎設施的遊戲，就無需擔心網絡、存儲等問題。

《精靈寶可夢 Go》便是這樣一款遊戲，它在發行後不久便吸引了大量玩家。於是，它們廣泛使用 Kubernetes 來為全世界大量玩家提供服務。

https://scotch.io/@pavan-belagatti/pokemon-go-a-successful-kubernetes-story

然而，對大多數其他應用程序來說，單個服務成為整個環境的瓶頸問題，通過優化而不是擴展解決更好。當然，在這個問題上，你可以多用幾個Pod，並祈禱問題會消失——也就是說，只要沒有達到存儲層的限制，你就可以簡單地通過擴展Pod來解決問題，達到了，就不行了。

不要誤解我的意思——能動態地擴展部署是一個很大優點。但是，在我見過的絕大多數情況下，為解決瓶頸而擴大部署只是治標不治本。

此外，除了能使用 Kubernetes 擴展應用程序外，還有許多其他方法。Heroku、Azure 和 AWS 都提供了動態運行和擴展應用程序的方法。例如，Azure Web App 有橫向擴展選項，這與在 Kubernetes 中運行多個Pod並在前置一個負載均衡器的效果是一樣的。

如果擴展能力是吸引你轉向 Kubernetes 的原因，那麽首先要考慮下其他不太需要維護的選項。

3 運行微服務

Kubernetes 主要用於運行許多小型的工作負載，這些工作負載一起組成一個應用程序。如前一節所述，其關鍵特性之一是獨立擴展基礎設施的各個部分，而不需要擴展整個應用程序。這些架構（通常被稱為微服務架構）在 Kubernetes 上蓬勃發展。其架構支持簡單的服務發現，以及整個拓撲中各個組件間的輕鬆互動。

因此，這裡要考慮的不是在 Kubernetes 上運行微服務是否是一個好主意，而是微服務是否是特定應用程序恰當的架構原則。雖然微服務架構通常比傳統的單體架構更受歡迎，但它們也給開發人員帶來巨大負擔。比如，Uber 支付體驗平台放棄微服務，轉而使用宏服務，這一事情引起網友熱議。

讓每個獨立的服務各自都有定義好的職責是一種合理的架構選擇。下一步，將這些職責劃分為不同服務似乎是合乎邏輯的，但也可以不必如此。為了讓開發人員可以分析和修複微服務環境中的 Bug，他們需要能訪問構成該環境的大部分（如果不是全部的話）服務。

這讓整個應用程序更加難以有效地工作。由於開發人員不能僅在他們的開發機器上運行應用程序，因此，你需要引入一整套工具來分析解決問題。考慮每個環境的分布式日誌記錄、消息隊列和性能監視。

這對開發人員生產力的影響不是很明顯。同樣，這樣做可能是值得的，特別是對於擁有許多開發團隊的大型組織來說，每個開發團隊都在他們自己的微服務上工作，是全局的一部分。然而，對於較小的公司和團隊，微服務架構的成本要高得多。Kubernetes 並不一定使這些問題更容易處理。事實上，它甚至可能讓情況變得更糟糕。

如果啟用微服務架構是吸引你使用 Kubernetes 的原因，那麽請仔細考慮一下，職責分離是不是一個可以用代碼解決的問題，而不是通過在基礎設施中引入 Kubernetes 等大型組件來解決它。

4 小結

在考慮 Kubernetes 是否適合你的項目或組織時，我們討論了一些需要考慮的因素。Kubernetes 最初是由谷歌設計來解決谷歌所面臨的問題。這些問題涉及到在生產環境中運行大量的工作負載，而其伸縮需求對於我們這些普通人來說是不可想象的。

谷歌只有一家。當然，除了谷歌，你可能會遇到與谷歌在設計 Kubernetes 時相同的問題，而你成功的機會卻很小。在決定將 Kubernetes 作為你的業務基礎前，你非常有必要考慮下，在一段較長時間內，它對你的組織、開發團隊和平台穩定性的影響。這項技術仍然相對較新，精通 Kubernetes 的工程師相對較少。

這並不是說 Kuberneets 是解決問題的錯誤方法。此前，我參與過一些項目，它們依賴 Kubernetes 向終端用戶提供價值，而且規模很大，這是其他類似技術難以匹敵的。最重要的是，儘管關於 Kubernetes 的許多宣傳是真的，但在引入 Kubernetes 時還是不能草率。

它有時候很合適——但並不總是很合適。

參考閱讀：

https://medium.com/better-programming/do-you-actually-need-kubernetes-a342b0a90fd8

InfoQ 讀者交流群上線啦！各位小夥伴可以掃描下方二維碼，添加 InfoQ 小助手，回復關鍵字“進群”申請入群。大家可以和 InfoQ 讀者一起暢所欲言，和編輯們零距離接觸，超值的技術禮包等你領取，還有超值活動等你參加，快來加入我們吧！

點個在看少個 bug