Kubernetes 絕對是滿足複雜 web 應用程式需求的最簡單、最容易的方法。
在 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 年代初，只有大型網站才出現大型的、規模級的問題。現在，有了微服務和數字化轉型，每個企業都面臨著一個大型的、規模級的問題——可能是多個大型的、規模級的問題。
你的企業需要能夠透過許多不同的人構建的許多不同的、通常是複雜的服務來管理複雜的規模級的網站。你的網站需要動態地處理流量，並且它們必須是安全的。這些屬性需要在所有層（從基礎結構到應用程式層）上由 API 驅動。
進入 Kubernetes
Kubernetes 並不複雜；你的業務問題才複雜。當你想在生產環境中執行應用程式時，要滿足效能（伸縮性、效能抖動等）和安全性要求，就需要最低程度的複雜性。諸如高可用性（HA）、容量要求（N+1、N+2、N+100）以及保證最終一致性的資料技術等就會成為必需。這些是每家進行數字化轉型的公司的生產要求，而不僅僅是 Google、Facebook 和 Twitter 這樣的大型網站。
在舊時代，我還在 American Greetings 任職時，每次我們加入一個新的服務，它看起來像這樣：所有這些都是由網站運營團隊來處理的，沒有一個是透過訂單系統轉移給其他團隊來處理的。這是在 DevOps 出現之前的 DevOps：
- 配置 DNS（通常是內部服務層和麵向公眾的外部）
- 配置負載均衡器（通常是內部服務和麵向公眾的）
- 配置對檔案的共享訪問（大型 NFS 伺服器、群集檔案系統等）
- 配置叢集軟體（資料庫、服務層等）
- 配置 web 伺服器群集（可以是 10 或 50 個伺服器）
大多數配置是透過配置管理自動完成的，但是配置仍然很複雜，因為每個系統和服務都有不同的配置檔案，而且格式完全不同。我們研究了像 Augeas 這樣的工具來簡化它，但是我們認為使用轉換器來嘗試和標準化一堆不同的配置檔案是一種反模式。
如今，藉助 Kubernetes，啟動一項新服務本質上看起來如下：
- 配置 Kubernetes YAML/JSON。
- 提交給 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 等，一切都改變了。
關鍵是：
- 時代不一樣了。現在，所有 Web 應用程式都是大型的分散式系統。就像 AmericanGreetings.com 過去一樣複雜，現在每個網站都有擴充套件性和 HA 的要求。
- 執行大型的分散式系統是很困難的。絕對是。這是業務的需求，不是 Kubernetes 的問題。使用更簡單的編排系統並不是解決方案。
Kubernetes 絕對是滿足複雜 Web 應用程式需求的最簡單，最容易的方法。這是我們生活的時代，而 Kubernetes 擅長於此。你可以討論是否應該自己構建或管理 Kubernetes。有很多供應商可以幫助你構建和管理它，但是很難否認這是大規模執行復雜 Web 應用程式的最簡單方法。
via: https://opensource.com/article/19/10/kubernetes-complex-business-problem
作者：Scott McCarty 選題：lujun9972 譯者：laingke 校對：wxy
本文由 LCTT 原創編譯，Linux中國 榮譽推出
