為什么你不必害怕 Kubernetes
在 90 年代末和 2000 年代初，在大型網(wǎng)站工作很有趣。我的經(jīng)歷讓我想起了 American Greetings Interactive，在情人節(jié)那天，我們擁有了互聯(lián)網(wǎng)上排名前 10 位之一的網(wǎng)站(以網(wǎng)絡訪問量衡量)。我們?yōu)?AmericanGreetings.com 、 BlueMountain.com 等公司提供了電子賀卡，并為 MSN 和 AOL 等合作伙伴提供了電子賀卡。該組織的老員工仍然深切地記得與 Hallmark 等其它電子賀卡網(wǎng)站進行大戰(zhàn)的史詩般的故事。順便說一句，我還為 Holly Hobbie、Care Bears 和 Strawberry Shortcake 運營過大型網(wǎng)站。
我記得那就像是昨天發(fā)生的一樣，這是我們第一次遇到真正的問題。通常，我們的前門(路由器、防火墻和負載均衡器)有大約 200Mbps 的流量進入。但是，突然之間，Multi Router Traffic Grapher(MRTG)圖示突然在幾分鐘內(nèi)飆升至 2Gbps。我瘋了似地東奔西跑。我了解了我們的整個技術堆棧，從路由器、交換機、防火墻和負載平衡器，到 Linux/Apache web 服務器，到我們的 Python 堆棧(FastCGI 的元版本)，以及網(wǎng)絡文件系統(tǒng)(NFS)服務器。我知道所有配置文件在哪里，我可以訪問所有管理界面，并且我是一位經(jīng)驗豐富的，打過硬仗的系統(tǒng)管理員，具有多年解決復雜問題的經(jīng)驗。
但是，我無法弄清楚發(fā)生了什么……
當你在一千個 Linux 服務器上瘋狂地鍵入命令時，五分鐘的感覺就像是永恒。我知道站點可能會在任何時候崩潰，因為當它被劃分成更小的集群時，壓垮上千個節(jié)點的集群是那么的容易。
我迅速跑到老板的辦公桌前，解釋了情況。他幾乎沒有從電子郵件中抬起頭來，這使我感到沮喪。他抬頭看了看，笑了笑，說道：“是的，市場營銷可能會開展廣告活動。有時會發(fā)生這種情況。”他告訴我在應用程序中設置一個特殊標志，以減輕 Akamai 的訪問量。我跑回我的辦公桌，在上千臺 web 服務器上設置了標志，幾分鐘后，站點恢復正常。災難也就被避免了。
我可以再分享 50 個類似的故事，但你腦海中可能會有一點好奇：“這種運維方式將走向何方?”
關鍵是，我們遇到了業(yè)務問題。當技術問題使你無法開展業(yè)務時，它們就變成了業(yè)務問題。換句話說，如果你的網(wǎng)站無法訪問，你就不能處理客戶交易。
那么，所有這些與 Kubernetes 有什么關系?一切!世界已經(jīng)改變。早在 90 年代末和 00 年代初，只有大型網(wǎng)站才出現(xiàn)大型的、 規(guī)模級(web-scale)的問題。現(xiàn)在，有了微服務和數(shù)字化轉(zhuǎn)型，每個企業(yè)都面臨著一個大型的、規(guī)模級的問題——可能是多個大型的、規(guī)模級的問題。
你的企業(yè)需要能夠通過許多不同的人構建的許多不同的、通常是復雜的服務來管理復雜的規(guī)模級的網(wǎng)站。你的網(wǎng)站需要動態(tài)地處理流量，并且它們必須是安全的。這些屬性需要在所有層(從基礎結構到應用程序?qū)?上由 API 驅(qū)動。
進入 Kubernetes
Kubernetes 并不復雜;你的業(yè)務問題才復雜。當你想在生產(chǎn)環(huán)境中運行應用程序時，要滿足性能(伸縮性、性能抖動等)和安全性要求，就需要最低程度的復雜性。諸如高可用性(HA)、容量要求(N+1、N+2、N+100)以及保證最終一致性的數(shù)據(jù)技術等就會成為必需。這些是每家進行數(shù)字化轉(zhuǎn)型的公司的生產(chǎn)要求，而不僅僅是 Google、Facebook 和 Twitter 這樣的大型網(wǎng)站。
在舊時代，我還在 American Greetings 任職時，每次我們加入一個新的服務，它看起來像這樣：所有這些都是由網(wǎng)站運營團隊來處理的，沒有一個是通過訂單系統(tǒng)轉(zhuǎn)移給其他團隊來處理的。這是在 DevOps 出現(xiàn)之前的 DevOps：
- 配置 DNS(通常是內(nèi)部服務層和面向公眾的外部)
- 配置負載均衡器(通常是內(nèi)部服務和面向公眾的)
- 配置對文件的共享訪問(大型 NFS 服務器、群集文件系統(tǒng)等)
- 配置集群軟件(數(shù)據(jù)庫、服務層等)
- 配置 web 服務器群集(可以是 10 或 50 個服務器)
大多數(shù)配置是通過配置管理自動完成的，但是配置仍然很復雜，因為每個系統(tǒng)和服務都有不同的配置文件，而且格式完全不同。我們研究了像 Augeas 這樣的工具來簡化它，但是我們認為使用轉(zhuǎn)換器來嘗試和標準化一堆不同的配置文件是一種反模式。
如今，借助 Kubernetes，啟動一項新服務本質(zhì)上看起來如下：
- 配置 Kubernetes YAML/JSON。
- 提交給 Kubernetes API(kubectl create -f service.yaml)。
Kubernetes 大大簡化了服務的啟動和管理。服務所有者(無論是系統(tǒng)管理員、開發(fā)人員還是架構師)都可以創(chuàng)建 Kubernetes 格式的 YAML/JSON 文件。使用 Kubernetes，每個系統(tǒng)和每個用戶都說相同的語言。所有用戶都可以在同一 Git 存儲庫中提交這些文件，從而啟用 GitOps。
而且，可以棄用和刪除服務。從歷史上看，刪除 DNS 條目、負載平衡器條目和 Web 服務器的配置等是非常可怕的，因為你幾乎肯定會破壞某些東西。使用 Kubernetes，所有內(nèi)容都處于命名空間下，因此可以通過單個命令刪除整個服務。盡管你仍然需要確保其它應用程序不使用它(微服務和函數(shù)即服務 [FaaS] 的缺點)，但你可以更加確信：刪除服務不會破壞基礎架構環(huán)境。
構建、管理和使用 Kubernetes
太多的人專注于構建和管理 Kubernetes 而不是使用它(詳見 Kubernetes 是一輛翻斗車 )。
在單個節(jié)點上構建一個簡單的 Kubernetes 環(huán)境并不比安裝 LAMP 堆棧復雜得多，但是我們無休止地爭論著構建與購買的問題。不是 Kubernetes 很難;它以高可用性大規(guī)模運行應用程序。建立一個復雜的、高可用性的 Kubernetes 集群很困難，因為要建立如此規(guī)模的任何集群都是很困難的。它需要規(guī)劃和大量軟件。建造一輛簡單的翻斗車并不復雜，但是建造一輛可以運載 10 噸垃圾并能以 200 邁的速度穩(wěn)定行駛的卡車 則很復雜。
管理 Kubernetes 可能很復雜，因為管理大型的、規(guī)模級的集群可能很復雜。有時，管理此基礎架構很有意義;而有時不是。由于 Kubernetes 是一個社區(qū)驅(qū)動的開源項目，它使行業(yè)能夠以多種不同方式對其進行管理。供應商可以出售托管版本，而用戶可以根據(jù)需要自行決定對其進行管理。(但是你應該質(zhì)疑是否確實需要。)
使用 Kubernetes 是迄今為止運行大規(guī)模網(wǎng)站的最簡單方法。Kubernetes 正在普及運行一組大型、復雜的 Web 服務的能力——就像當年 Linux 在 Web 1.0 中所做的那樣。
由于時間和金錢是一個零和游戲，因此我建議將重點放在使用 Kubernetes 上。將你的時間和金錢花費在 掌握 Kubernetes 原語 或處理 活躍度和就緒性探針 的最佳方法上(表明大型、復雜的服務很難的另一個例子)。不要專注于構建和管理 Kubernetes。(在構建和管理上)許多供應商可以為你提供幫助。
結論
我記得對無數(shù)的問題進行了故障排除，比如我在這篇文章的開頭所描述的問題——當時 Linux 內(nèi)核中的 NFS、我們自產(chǎn)的 CFEngine、僅在某些 Web 服務器上出現(xiàn)的重定向問題等)。開發(fā)人員無法幫助我解決所有這些問題。實際上，除非開發(fā)人員具備高級系統(tǒng)管理員的技能，否則他們甚至不可能進入系統(tǒng)并作為第二雙眼睛提供幫助。沒有帶有圖形或“可觀察性”的控制臺——可觀察性在我和其他系統(tǒng)管理員的大腦中。如今，有了 Kubernetes、Prometheus、Grafana 等，一切都改變了。
關鍵是：
時代不一樣了。現(xiàn)在，所有 Web 應用程序都是大型的分布式系統(tǒng)。就像 AmericanGreetings.com 過去一樣復雜，現(xiàn)在每個網(wǎng)站都有擴展性和 HA 的要求。
運行大型的分布式系統(tǒng)是很困難的。絕對是。這是業(yè)務的需求，不是 Kubernetes 的問題。使用更簡單的編排系統(tǒng)并不是解決方案。
Kubernetes 絕對是滿足復雜 Web 應用程序需求的最簡單，最容易的方法。這是我們生活的時代，而 Kubernetes 擅長于此。你可以討論是否應該自己構建或管理 Kubernetes。有很多供應商可以幫助你構建和管理它，但是很難否認這是大規(guī)模運行復雜 Web 應用程序的最簡單方法。
