唉，這周過得真夠嗆……

如果你身處科技行業，你肯定知道我說的是哪一周。 2025年10月AWS us-east-1服務器的大宕機。警報響起時你在哪里？

我當時正在進行演示，突然間，所有功能都失效了。我們的應用程序、身份驗證系統、持續集成/持續交付 (CI/CD) 流水線都無法運行。整個網絡就像一座空城。整整八個小時，互聯網的很大一部分——從流媒體服務、電商網站，到令人恐懼的金融和醫療平臺——都徹底消失了。

此后數日和數周內，各種事后分析報告紛至沓來。《Tom's Guide》等出版物詳細記錄了這場災難帶來的巨大連鎖反應，《福布斯》則一直在統計損失。目前的估計是：超過110億美元的收入和市值損失。

人們很容易跟風指責 AWS。但說實話，如此大規模的工程設計難度極大，失敗在所難免。

現在塵埃落定，我們需要捫心自問一個真正令人不安的問題：為什么我們如此脆弱？

單一云的誘惑

十年來，公有云一直是一個令人難以置信的加速器。我們用運營支出取代了資本支出，作為回報，我們獲得了計算、存儲以及豐富的按需托管服務生態系統，這是一筆非常劃算的交易。

但我們也變得安于現狀。我們圍繞單一云服務商的專有 API 構建了我們全部系統和業務。我們基于 DynamoDB 構建，使用 Lambda 運行函數，并通過身份和訪問管理（IAM）將所有東西連接起來，速度很快、功能強大，但同時這也是一顆定時炸彈。

10 月份的宕機事件不僅僅是服務故障，更是控制層面的崩潰。身份服務宕機后，整個系統瞬間崩塌。這暴露了我們思維中的一個根本缺陷：我們構建的看似極具彈性的應用程序，卻建立在一個單一的、巨大的故障點之上。

《福布斯》的文章指出，華爾街現在最愛用的詞是“多云”。他們說得沒錯。例如，那些在 AWS 和 Google Cloud Platform（GCP）上部署了雙活架構的公司，發布的推文是“我們遇到了一些小問題”，而不是“我們徹底崩潰了”。

但對我們大多數人來說，“直接采用多云”是一個糟糕、簡單化且極其昂貴的建議。

為什么“多云”通常是個陷阱？

如果你的應對方案是讓你的團隊也去學習谷歌的 IAM、Azure 的 Active Directory 以及它們所有不同的托管數據庫服務的來龍去脈……那么祝你好運。

真正的多云部署很難。它不僅僅是在兩個地方運行幾個虛擬機（VM）。它還包括：

• 不同的 API：在 AWS 中配置負載均衡器的方式與在 GCP 中配置負載均衡器的方式完全不同。
• 不同的服務：并非所有托管服務都有完全對應的替代方案。最終，你只能構建滿足最低要求的服務，更糟糕的是，甚至可能需要構建兩個（或三個）完全獨立的服務棧。
• 不同的工具：您的boto3腳本在 Azure 中無法使用。您的整個 CI/CD 和可觀測性堆棧可能需要復制或重新架構。

這種方法不僅會使你的基礎設施成本翻倍，還會使你的認知負擔翻倍。你需要在兩個完全不同的生態系統中發布功能、管理可靠性并處理各種突發狀況。

多年來，這種復雜性一直是彈性的代價。但我們大多數人，理所當然地選擇“不支付”這筆代價。

但是，如果入場券的價格剛剛降為零了呢？如果我們因為其他原因而一直在采用的平臺，自始至終就是那把鑰匙呢？

Kubernetes 作為偉大的抽象層

這就是 Kubernetes（K8s）改變游戲規則的地方。

對許多人來說，Kubernetes 僅僅是一個“容器編排器”，是用來運行微服務的。但這種描述過于簡單，忽略了它真正的價值所在。

Kubernetes 為您的整個應用程序提供了一個一致的、與云平臺無關的 API。

仔細想想：一個 Kubernetes 的 Deployment.yaml 文件，無論你將其提交到運行在 Elastic Kubernetes Service（AWS）、Google Kubernetes Engine 還是 Azure Kubernetes Service 上的集群，它看起來都是一樣的。KubernetesService對象抽象掉了底層云負載均衡器，而 Kubernetes 對象則PersistentVolumeClaim抽象掉了底層存儲類（例如 Amazon Elastic Block Store、Google Persistent Disk 等）。

K8s 正是我們一直缺失的抽象層，它是云計算的"操作系統"。

當你的應用程序只支持 Kubernetes 時，你就不再受限于云服務提供商的專有 API，而是可以使用一個可以在任何地方運行的開源標準。

這使得多云夢想成為切實可行的現實：

• 真正的可移植性：容器鏡像就是容器鏡像。您的應用程序打包成容器后，在您的筆記本電腦上、AWS us-east-1 集群中以及 GCP europe-west-2 集群中都能完全運行。
• 基礎設施即數據：應用程序的整個預期狀態僅僅是一組 YAML 或 JSON 文件。將 Argo CD 或 Flux（GitOps）流水線指向不同區域（或不同云平臺）中的全新空集群非常簡單。
• 聯合和故障轉移：借助現代工具，您可以將多個集群作為一個邏輯單元進行管理。服務網格（例如Linkerd 或 Istio）可以自動將流量從發生故障的區域或云提供商處路由出去，通常無需人工干預。

采用 Kubernetes 不僅僅是容器編排，更是一項戰略性商業決策，它能讓你重獲自由。它不僅能幫你應對宕機，還能讓你省下數十億美元，因為你無需構建和維護 N 個不同版本的平臺。

超越彈性：真正的勝利在于速度

大多數關于“多云”的文章都忽略了這一點：僅僅為了災難恢復而使用 Kubernetes，就好比買了一輛 F1 賽車去買菜一樣。

Kubernetes 真正的日常魔力在于它能提高開發人員的生產力。

我們生活在一個全新的、人工智能原生的世界。智能體能夠生成海量代碼，所以軟件瓶頸不再是編寫代碼，而是測試和驗證代碼。

如何確保人工智能生成的（或初級開發人員生成的）更改不會破壞它需要通信的其他 50 個微服務中的任何一個？

過去的做法是使用共享的測試環境。這是一個單一、脆弱、總是崩潰的“上帝”環境，每個人都害怕觸碰它。它始終是一個瓶頸。但是，如果使用得當，Kubernetes 可以成為速度的超級放大器。

Kubernetes憑借其原生命名空間、資源配額和網絡策略等概念，是一個卓越的多租戶平臺。這種多租戶機制比為每個拉取請求都啟動整個堆棧的完整、隔離的副本要強大得多，也更具可擴展性——對于幾十個甚至幾百個微服務來說，這種策略很快就會變得不可行。

想象一下這種更高級的方法：

• 開發人員提交了一個拉取請求（PR），對單個微服務進行了更改。
• CI/CD流水線會立即啟動已更改的服務。
• 該平臺利用服務網格（如 Linkerd 或 Istio）和上下文感知路由，創建了一個“虛擬”測試環境。
• 當開發人員或自動化端到端測試向此環境發送請求時（例如，通過添加特殊的 HTTP 標頭），網格會智能地路由該請求。
• 對已更改服務的請求會路由到新版本。對所有其他（未更改的）服務的請求則會路由到穩定、共享的基線堆棧。
• 開發人員可以獲得針對整個技術棧的高保真、隔離的測試，而無需承擔復制測試的巨大開銷。
• PR 合并后，只會銷毀這一個輕量級的命名空間。

這是 CI/CD 的終極目標。它讓團隊有信心每天合并和部署 50 次以上。而這在傳統的基于虛擬機的架構上，無論從經濟上還是技術上來說，都是根本不可行的。

不要只盯著上一次宕機，要為未來十年做好準備

AWS宕機事件給我們敲響了警鐘，讓我們深刻體會到過度集中帶來的脆弱性。沒錯，Kubernetes正是華爾街如今所要求的，能夠實現多區域、多云彈性架構的技術解決方案。

但這僅僅是個開始。

不要僅僅為了應對下一次服務商宕機而采用 Kubernetes。采用它是為了構建一個能夠抵御自身開發流程瓶頸的彈性平臺。采用它，是為了讓你的團隊能夠更快、更安全、更自信地交付產品。

這正是令我興奮的愿景。在 Signadot，我們認為 Kubernetes 是提升開發者生產力的終極基礎——即使在如今這個由人工智能驅動、瞬息萬變的新世界中，它也能讓每位開發者按需獲得一個隔離的、高保真的測試環境。（您可以在我們的文檔中了解更多相關信息。）

軟件的未來是快速、分布式和復雜的。別再把城堡建在單一供應商的沙地上了，是時候在磐石上建造了。

作者丨Arjun Iyer    編譯丨Rio

來源丨網址：https://thenewstack.io/the-great-aws-outage-the-11-billion-argument-for-kubernetes/