引入 Kubernetes 時(shí)不能太草率，因?yàn)樗灰欢ㄟm合你。本篇文章探討了在使用 Kubernetes 前應(yīng)該考慮的一些因素。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 運(yùn)行微服務(wù)

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

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

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

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

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

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

4. 小結(jié)

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

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

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

它有時(shí)候很合適——但并不總是很合適。