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

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

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

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

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

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

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

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

1. 學習曲線

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

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

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

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

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

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

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

• 表示應用程序的Deployment對象；
• ReplicaSet用于擴展與部署相關的Pod；
• 可選，一個或多個Service處理部署的網(wǎng)絡需求；
• 表示實際容器的一個或多個Pod。這是 Kubernetes 架構中的最小組件。

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

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

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

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

2. 應用程序需要擴展嗎？

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

如果一個應用程序有一個或多個熱點組件需要處理突發(fā)事件，那這個特性就很有價值。例如，在推出新擴展或新特性時，在線游戲的身份驗證服務可能會出現(xiàn)登錄請求突然增加的情況?；蛘呤悄切┰诎l(fā)行后變得非常受歡迎并需要快速擴展基礎設施的游戲，就無需擔心網(wǎng)絡、存儲等問題。

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

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

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

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

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

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

3. 運行微服務

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

因此，這里要考慮的不是在 Kubernetes 上運行微服務是否是一個好主意，而是微服務是否是特定應用程序恰當?shù)募軜嬙瓌t。雖然微服務架構通常比傳統(tǒng)的單體架構更受歡迎，但它們也給開發(fā)人員帶來巨大負擔。比如，Uber 支付體驗平臺放棄微服務，轉而使用宏服務，這一事情引起網(wǎng)友熱議。

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

這讓整個應用程序更加難以有效地工作。由于開發(fā)人員不能僅在他們的開發(fā)機器上運行應用程序，因此，你需要引入一整套工具來分析解決問題?？紤]每個環(huán)境的分布式日志記錄、消息隊列和性能監(jiān)視。

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

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

4. 小結

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

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

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

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