爲何你沒必要懼怕 Kubernetes

Kubernetes 絕對是知足複雜 web 應用程序需求的最簡單、最容易的方法。

Digital creative of a browser on the internet

在 90 年代末和 2000 年代初，在大型網站工做頗有趣。個人經歷讓我想起了 American Greetings Interactive，在情人節那天，咱們擁有了互聯網上排名前 10 位之一的網站（以網絡訪問量衡量）。咱們爲 AmericanGreetings.com、BlueMountain.com 等公司提供了電子賀卡，併爲 MSN 和 AOL 等合做夥伴提供了電子賀卡。該組織的老員工仍然深切地記得與 Hallmark 等其它電子賀卡網站進行大戰的史詩般的故事。順便說一句，我還爲 Holly Hobbie、Care Bears 和 Strawberry Shortcake 運營過大型網站。

我記得那就像是昨天發生的同樣，這是咱們第一次遇到真正的問題。一般，咱們的前門（路由器、防火牆和負載均衡器）有大約 200Mbps 的流量進入。可是，忽然之間，Multi Router Traffic Grapher（MRTG）圖示忽然在幾分鐘內飆升至 2Gbps。我瘋了似地東奔西跑。我瞭解了咱們的整個技術堆棧，從路由器、交換機、防火牆和負載平衡器，到 Linux/Apache web 服務器，到咱們的 Python 堆棧（FastCGI 的元版本），以及網絡文件系統（NFS）服務器。我知道全部配置文件在哪裏，我能夠訪問全部管理界面，而且我是一位經驗豐富的，打過硬仗的系統管理員，具備多年解決複雜問題的經驗。

可是，我沒法弄清楚發生了什麼……

當你在一千個 Linux 服務器上瘋狂地鍵入命令時，五分鐘的感受就像是永恆。我知道站點可能會在任什麼時候候崩潰，由於當它被劃分紅更小的集羣時，壓垮上千個節點的集羣是那麼的容易。

我迅速跑到老闆的辦公桌前，解釋了狀況。他幾乎沒有從電子郵件中擡起頭來，這使我感到沮喪。他擡頭看了看，笑了笑，說道：「是的，市場營銷可能會開展廣告活動。有時會發生這種狀況。」他告訴我在應用程序中設置一個特殊標誌，以減輕 Akamai 的訪問量。我跑回個人辦公桌，在上千臺 web 服務器上設置了標誌，幾分鐘後，站點恢復正常。災難也就被避免了。

我能夠再分享 50 個相似的故事，但你腦海中可能會有一點好奇：「這種運維方式將走向何方?」

關鍵是，咱們遇到了業務問題。當技術問題使你沒法開展業務時，它們就變成了業務問題。換句話說，若是你的網站沒法訪問，你就不能處理客戶交易。

那麼，全部這些與 Kubernetes 有什麼關係？一切！世界已經改變。早在 90 年代末和 00 年代初，只有大型網站纔出現大型的、規模級web-scale的問題。如今，有了微服務和數字化轉型，每一個企業都面臨着一個大型的、規模級的問題——多是多個大型的、規模級的問題。

你的企業須要可以經過許多不一樣的人構建的許多不一樣的、一般是複雜的服務來管理複雜的規模級的網站。你的網站須要動態地處理流量，而且它們必須是安全的。這些屬性須要在全部層（從基礎結構到應用程序層）上由 API 驅動。

進入 Kubernetes

Kubernetes 並不複雜；你的業務問題才複雜。當你想在生產環境中運行應用程序時，要知足性能（伸縮性、性能抖動等）和安全性要求，就須要最低程度的複雜性。諸如高可用性（HA）、容量要求（N+一、N+二、N+100）以及保證最終一致性的數據技術等就會成爲必需。這些是每家進行數字化轉型的公司的生產要求，而不只僅是 Google、Facebook 和 Twitter 這樣的大型網站。

在舊時代，我還在 American Greetings 任職時，每次咱們加入一個新的服務，它看起來像這樣：全部這些都是由網站運營團隊來處理的，沒有一個是經過訂單系統轉移給其餘團隊來處理的。這是在 DevOps 出現以前的 DevOps：

1. 配置 DNS（一般是內部服務層和麪向公衆的外部）
2. 配置負載均衡器（一般是內部服務和麪向公衆的）
3. 配置對文件的共享訪問（大型 NFS 服務器、羣集文件系統等）
4. 配置集羣軟件（數據庫、服務層等）
5. 配置 web 服務器羣集（能夠是 10 或 50 個服務器）

大多數配置是經過配置管理自動完成的，可是配置仍然很複雜，由於每一個系統和服務都有不一樣的配置文件，並且格式徹底不一樣。咱們研究了像 Augeas 這樣的工具來簡化它，可是咱們認爲使用轉換器來嘗試和標準化一堆不一樣的配置文件是一種反模式。

現在，藉助 Kubernetes，啓動一項新服務本質上看起來以下：

1. 配置 Kubernetes YAML/JSON。
2. 提交給 Kubernetes API（kubectl create -f service.yaml）。

Kubernetes 大大簡化了服務的啓動和管理。服務全部者（不管是系統管理員、開發人員仍是架構師）均可以建立 Kubernetes 格式的 YAML/JSON 文件。使用 Kubernetes，每一個系統和每一個用戶都說相同的語言。全部用戶均可以在同一 Git 存儲庫中提交這些文件，從而啓用 GitOps。

並且，能夠棄用和刪除服務。從歷史上看，刪除 DNS 條目、負載平衡器條目和 Web 服務器的配置等是很是可怕的，由於你幾乎確定會破壞某些東西。使用 Kubernetes，全部內容都處於命名空間下，所以能夠經過單個命令刪除整個服務。儘管你仍然須要確保其它應用程序不使用它（微服務和函數即服務 [FaaS] 的缺點），但你能夠更加確信：刪除服務不會破壞基礎架構環境。

構建、管理和使用 Kubernetes

太多的人專一於構建和管理 Kubernetes 而不是使用它（詳見 Kubernetes 是一輛翻斗車）。

在單個節點上構建一個簡單的 Kubernetes 環境並不比安裝 LAMP 堆棧複雜得多，可是咱們無休止地爭論着構建與購買的問題。不是 Kubernetes 很難；它以高可用性大規模運行應用程序。創建一個複雜的、高可用性的 Kubernetes 集羣很困難，由於要創建如此規模的任何集羣都是很困難的。它須要規劃和大量軟件。建造一輛簡單的翻斗車並不複雜，可是建造一輛能夠運載 10 噸垃圾並能以 200 邁的速度穩定行駛的卡車則很複雜。

管理 Kubernetes 可能很複雜，由於管理大型的、規模級的集羣可能很複雜。有時，管理此基礎架構頗有意義；而有時不是。因爲 Kubernetes 是一個社區驅動的開源項目，它使行業可以以多種不一樣方式對其進行管理。供應商能夠出售託管版本，而用戶能夠根據須要自行決定對其進行管理。（可是你應該質疑是否確實須要。）

使用 Kubernetes 是迄今爲止運行大規模網站的最簡單方法。Kubernetes 正在普及運行一組大型、複雜的 Web 服務的能力——就像當年 Linux 在 Web 1.0 中所作的那樣。

因爲時間和金錢是一個零和遊戲，所以我建議將重點放在使用 Kubernetes 上。將你的時間和金錢花費在掌握 Kubernetes 原語或處理活躍度和就緒性探針的最佳方法上（代表大型、複雜的服務很難的另外一個例子）。不要專一於構建和管理 Kubernetes。（在構建和管理上）許多供應商能夠爲你提供幫助。

結論

我記得對無數的問題進行了故障排除，好比我在這篇文章的開頭所描述的問題——當時 Linux 內核中的 NFS、咱們自產的 CFEngine、僅在某些 Web 服務器上出現的重定向問題等）。開發人員沒法幫助我解決全部這些問題。實際上，除非開發人員具有高級系統管理員的技能，不然他們甚至不可能進入系統並做爲第二雙眼睛提供幫助。沒有帶有圖形或「可觀察性」的控制檯——可觀察性在我和其餘系統管理員的大腦中。現在，有了 Kubernetes、Prometheus、Grafana 等，一切都改變了。

關鍵是：

1. 時代不同了。如今，全部 Web 應用程序都是大型的分佈式系統。就像 AmericanGreetings.com 過去同樣複雜，如今每一個網站都有擴展性和 HA 的要求。
2. 運行大型的分佈式系統是很困難的。絕對是。這是業務的需求，不是 Kubernetes 的問題。使用更簡單的編排系統並非解決方案。

Kubernetes 絕對是知足複雜 Web 應用程序需求的最簡單，最容易的方法。這是咱們生活的時代，而 Kubernetes 擅長於此。你能夠討論是否應該本身構建或管理 Kubernetes。有不少供應商能夠幫助你構建和管理它，可是很難否定這是大規模運行復雜 Web 應用程序的最簡單方法。

---

via: opensource.com/article/19/…

做者：Scott McCarty 選題：lujun9972 譯者：laingke 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出