唉，这周过得真够呛…… 如果你身处科技行业，你肯定知道我说的是哪一周。 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/ dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn