在 90 年代末和 2000 年代初，在大型網(wǎng)站工作很有趣。我的經(jīng)歷讓我想起了 American Greetings Interactive，在情人節(jié)那天，我們擁有了互聯(lián)網(wǎng)上排名前 10 位之一的網(wǎng)站(以網(wǎng)絡(luò)訪問(wèn)量衡量)。我們?yōu)?AmericanGreetings.com 、 BlueMountain.com 等公司提供了電子賀卡，并為 MSN 和 AOL 等合作伙伴提供了電子賀卡。該組織的老員工仍然深切地記得與 Hallmark 等其它電子賀卡網(wǎng)站進(jìn)行大戰(zhàn)的史詩(shī)般的故事。順便說(shuō)一句，我還為 Holly Hobbie、Care Bears 和 Strawberry Shortcake 運(yùn)營(yíng)過(guò)大型網(wǎng)站。

[[281366]]

我記得那就像是昨天發(fā)生的一樣，這是我們第一次遇到真正的問(wèn)題。通常，我們的前門(路由器、防火墻和負(fù)載均衡器)有大約 200Mbps 的流量進(jìn)入。但是，突然之間，Multi Router Traffic Grapher(MRTG)圖示突然在幾分鐘內(nèi)飆升至 2Gbps。我瘋了似地東奔西跑。我了解了我們的整個(gè)技術(shù)堆棧，從路由器、交換機(jī)、防火墻和負(fù)載平衡器，到 Linux/Apache web 服務(wù)器，到我們的 Python 堆棧(FastCGI 的元版本)，以及網(wǎng)絡(luò)文件系統(tǒng)(NFS)服務(wù)器。我知道所有配置文件在哪里，我可以訪問(wèn)所有管理界面，并且我是一位經(jīng)驗(yàn)豐富的，打過(guò)硬仗的系統(tǒng)管理員，具有多年解決復(fù)雜問(wèn)題的經(jīng)驗(yàn)。

但是，我無(wú)法弄清楚發(fā)生了什么……

當(dāng)你在一千個(gè) Linux 服務(wù)器上瘋狂地鍵入命令時(shí)，五分鐘的感覺就像是永恒。我知道站點(diǎn)可能會(huì)在任何時(shí)候崩潰，因?yàn)楫?dāng)它被劃分成更小的集群時(shí)，壓垮上千個(gè)節(jié)點(diǎn)的集群是那么的容易。

我迅速跑到老板的辦公桌前，解釋了情況。他幾乎沒有從電子郵件中抬起頭來(lái)，這使我感到沮喪。他抬頭看了看，笑了笑，說(shuō)道：“是的，市場(chǎng)營(yíng)銷可能會(huì)開展廣告活動(dòng)。有時(shí)會(huì)發(fā)生這種情況。”他告訴我在應(yīng)用程序中設(shè)置一個(gè)特殊標(biāo)志，以減輕 Akamai 的訪問(wèn)量。我跑回我的辦公桌，在上千臺(tái) web 服務(wù)器上設(shè)置了標(biāo)志，幾分鐘后，站點(diǎn)恢復(fù)正常。災(zāi)難也就被避免了。

我可以再分享 50 個(gè)類似的故事，但你腦海中可能會(huì)有一點(diǎn)好奇：“這種運(yùn)維方式將走向何方?”

關(guān)鍵是，我們遇到了業(yè)務(wù)問(wèn)題。當(dāng)技術(shù)問(wèn)題使你無(wú)法開展業(yè)務(wù)時(shí)，它們就變成了業(yè)務(wù)問(wèn)題。換句話說(shuō)，如果你的網(wǎng)站無(wú)法訪問(wèn)，你就不能處理客戶交易。

那么，所有這些與 Kubernetes 有什么關(guān)系?一切!世界已經(jīng)改變。早在 90 年代末和 00 年代初，只有大型網(wǎng)站才出現(xiàn)大型的、 規(guī)模級(jí)(web-scale)的問(wèn)題?，F(xiàn)在，有了微服務(wù)和數(shù)字化轉(zhuǎn)型，每個(gè)企業(yè)都面臨著一個(gè)大型的、規(guī)模級(jí)的問(wèn)題——可能是多個(gè)大型的、規(guī)模級(jí)的問(wèn)題。

你的企業(yè)需要能夠通過(guò)許多不同的人構(gòu)建的許多不同的、通常是復(fù)雜的服務(wù)來(lái)管理復(fù)雜的規(guī)模級(jí)的網(wǎng)站。你的網(wǎng)站需要?jiǎng)討B(tài)地處理流量，并且它們必須是安全的。這些屬性需要在所有層(從基礎(chǔ)結(jié)構(gòu)到應(yīng)用程序?qū)?上由 API 驅(qū)動(dòng)。

進(jìn)入 Kubernetes

Kubernetes 并不復(fù)雜;你的業(yè)務(wù)問(wèn)題才復(fù)雜。當(dāng)你想在生產(chǎn)環(huán)境中運(yùn)行應(yīng)用程序時(shí)，要滿足性能(伸縮性、性能抖動(dòng)等)和安全性要求，就需要最低程度的復(fù)雜性。諸如高可用性(HA)、容量要求(N+1、N+2、N+100)以及保證最終一致性的數(shù)據(jù)技術(shù)等就會(huì)成為必需。這些是每家進(jìn)行數(shù)字化轉(zhuǎn)型的公司的生產(chǎn)要求，而不僅僅是 Google、Facebook 和 Twitter 這樣的大型網(wǎng)站。

在舊時(shí)代，我還在 American Greetings 任職時(shí)，每次我們加入一個(gè)新的服務(wù)，它看起來(lái)像這樣：所有這些都是由網(wǎng)站運(yùn)營(yíng)團(tuán)隊(duì)來(lái)處理的，沒有一個(gè)是通過(guò)訂單系統(tǒng)轉(zhuǎn)移給其他團(tuán)隊(duì)來(lái)處理的。這是在 DevOps 出現(xiàn)之前的 DevOps：

1. 配置 DNS(通常是內(nèi)部服務(wù)層和面向公眾的外部)
2. 配置負(fù)載均衡器(通常是內(nèi)部服務(wù)和面向公眾的)
3. 配置對(duì)文件的共享訪問(wèn)(大型 NFS 服務(wù)器、群集文件系統(tǒng)等)
4. 配置集群軟件(數(shù)據(jù)庫(kù)、服務(wù)層等)
5. 配置 web 服務(wù)器群集(可以是 10 或 50 個(gè)服務(wù)器)

大多數(shù)配置是通過(guò)配置管理自動(dòng)完成的，但是配置仍然很復(fù)雜，因?yàn)槊總€(gè)系統(tǒng)和服務(wù)都有不同的配置文件，而且格式完全不同。我們研究了像 Augeas 這樣的工具來(lái)簡(jiǎn)化它，但是我們認(rèn)為使用轉(zhuǎn)換器來(lái)嘗試和標(biāo)準(zhǔn)化一堆不同的配置文件是一種反模式。

如今，借助 Kubernetes，啟動(dòng)一項(xiàng)新服務(wù)本質(zhì)上看起來(lái)如下：

• 配置 Kubernetes YAML/JSON。
• 提交給 Kubernetes API(kubectl create -f service.yaml)。

Kubernetes 大大簡(jiǎn)化了服務(wù)的啟動(dòng)和管理。服務(wù)所有者(無(wú)論是系統(tǒng)管理員、開發(fā)人員還是架構(gòu)師)都可以創(chuàng)建 Kubernetes 格式的 YAML/JSON 文件。使用 Kubernetes，每個(gè)系統(tǒng)和每個(gè)用戶都說(shuō)相同的語(yǔ)言。所有用戶都可以在同一 Git 存儲(chǔ)庫(kù)中提交這些文件，從而啟用 GitOps。

而且，可以棄用和刪除服務(wù)。從歷史上看，刪除 DNS 條目、負(fù)載平衡器條目和 Web 服務(wù)器的配置等是非?？膳碌模?yàn)槟銕缀蹩隙〞?huì)破壞某些東西。使用 Kubernetes，所有內(nèi)容都處于命名空間下，因此可以通過(guò)單個(gè)命令刪除整個(gè)服務(wù)。盡管你仍然需要確保其它應(yīng)用程序不使用它(微服務(wù)和函數(shù)即服務(wù) [FaaS] 的缺點(diǎn))，但你可以更加確信：刪除服務(wù)不會(huì)破壞基礎(chǔ)架構(gòu)環(huán)境。

構(gòu)建、管理和使用 Kubernetes

太多的人專注于構(gòu)建和管理 Kubernetes 而不是使用它(詳見 Kubernetes 是一輛翻斗車 )。

在單個(gè)節(jié)點(diǎn)上構(gòu)建一個(gè)簡(jiǎn)單的 Kubernetes 環(huán)境并不比安裝 LAMP 堆棧復(fù)雜得多，但是我們無(wú)休止地爭(zhēng)論著構(gòu)建與購(gòu)買的問(wèn)題。不是 Kubernetes 很難;它以高可用性大規(guī)模運(yùn)行應(yīng)用程序。建立一個(gè)復(fù)雜的、高可用性的 Kubernetes 集群很困難，因?yàn)橐⑷绱艘?guī)模的任何集群都是很困難的。它需要規(guī)劃和大量軟件。建造一輛簡(jiǎn)單的翻斗車并不復(fù)雜，但是建造一輛可以運(yùn)載 10 噸垃圾并能以 200 邁的速度穩(wěn)定行駛的卡車 則很復(fù)雜。

管理 Kubernetes 可能很復(fù)雜，因?yàn)楣芾泶笮偷?、?guī)模級(jí)的集群可能很復(fù)雜。有時(shí)，管理此基礎(chǔ)架構(gòu)很有意義;而有時(shí)不是。由于 Kubernetes 是一個(gè)社區(qū)驅(qū)動(dòng)的開源項(xiàng)目，它使行業(yè)能夠以多種不同方式對(duì)其進(jìn)行管理。供應(yīng)商可以出售托管版本，而用戶可以根據(jù)需要自行決定對(duì)其進(jìn)行管理。(但是你應(yīng)該質(zhì)疑是否確實(shí)需要。)

使用 Kubernetes 是迄今為止運(yùn)行大規(guī)模網(wǎng)站的最簡(jiǎn)單方法。Kubernetes 正在普及運(yùn)行一組大型、復(fù)雜的 Web 服務(wù)的能力——就像當(dāng)年 Linux 在 Web 1.0 中所做的那樣。

由于時(shí)間和金錢是一個(gè)零和游戲，因此我建議將重點(diǎn)放在使用 Kubernetes 上。將你的時(shí)間和金錢花費(fèi)在 掌握 Kubernetes 原語(yǔ) 或處理 活躍度和就緒性探針 的最佳方法上(表明大型、復(fù)雜的服務(wù)很難的另一個(gè)例子)。不要專注于構(gòu)建和管理 Kubernetes。(在構(gòu)建和管理上)許多供應(yīng)商可以為你提供幫助。

結(jié)論

我記得對(duì)無(wú)數(shù)的問(wèn)題進(jìn)行了故障排除，比如我在這篇文章的開頭所描述的問(wèn)題——當(dāng)時(shí) Linux 內(nèi)核中的 NFS、我們自產(chǎn)的 CFEngine、僅在某些 Web 服務(wù)器上出現(xiàn)的重定向問(wèn)題等)。開發(fā)人員無(wú)法幫助我解決所有這些問(wèn)題。實(shí)際上，除非開發(fā)人員具備高級(jí)系統(tǒng)管理員的技能，否則他們甚至不可能進(jìn)入系統(tǒng)并作為第二雙眼睛提供幫助。沒有帶有圖形或“可觀察性”的控制臺(tái)——可觀察性在我和其他系統(tǒng)管理員的大腦中。如今，有了 Kubernetes、Prometheus、Grafana 等，一切都改變了。

關(guān)鍵是：

時(shí)代不一樣了?，F(xiàn)在，所有 Web 應(yīng)用程序都是大型的分布式系統(tǒng)。就像 AmericanGreetings.com 過(guò)去一樣復(fù)雜，現(xiàn)在每個(gè)網(wǎng)站都有擴(kuò)展性和 HA 的要求。

運(yùn)行大型的分布式系統(tǒng)是很困難的。絕對(duì)是。這是業(yè)務(wù)的需求，不是 Kubernetes 的問(wèn)題。使用更簡(jiǎn)單的編排系統(tǒng)并不是解決方案。

Kubernetes 絕對(duì)是滿足復(fù)雜 Web 應(yīng)用程序需求的最簡(jiǎn)單，最容易的方法。這是我們生活的時(shí)代，而 Kubernetes 擅長(zhǎng)于此。你可以討論是否應(yīng)該自己構(gòu)建或管理 Kubernetes。有很多供應(yīng)商可以幫助你構(gòu)建和管理它，但是很難否認(rèn)這是大規(guī)模運(yùn)行復(fù)雜 Web 應(yīng)用程序的最簡(jiǎn)單方法。