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

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

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

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

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

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

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

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

1. 學(xué)習(xí)曲線

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

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

下面這個圖展示了 Kubernetes 架構(gòu)的高級概述

Kubernetes 架構(gòu)（Kubernetes Components，CC-BY 4.0）

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

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

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

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

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

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

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

你應(yīng)該仔細(xì)衡量一下，遷移成本（學(xué)習(xí)曲線的增加和配置開銷）和遷移好處。

2. 應(yīng)用程序需要擴(kuò)展嗎？

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

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

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

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

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

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

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

如果擴(kuò)展能力是吸引你轉(zhuǎn)向 Kubernetes 的原因，那么首先要考慮下其他不太需要維護(hù)的選項。

3. 運行微服務(wù)

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

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

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

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

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

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

4. 小結(jié)

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

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

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

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