Airbnb Istio 升级 14 次零宕机！Google、Uber、Netflix 都在借鉴

Airbnb engineering 发布了一份详细报告，介绍公司如何在数万 Pod 和数千 VM 上执行 Istio 升级的同时保持高可用，而且没有发生宕机。该公司的服务网格基础设施支持 Kubernetes 和 VM 环境中的工作负载，在峰值时每秒处理数千万次请求。尽管过程复杂，Airbnb 至今已完成了 14 次 Istio 升级。

关键挑战在于协调不同团队所负责的多样化工作负载。为了解决这个问题，Airbnb 设计了一条升级流水线，它能够“保证”零宕机，支持渐进式发布、回退机制，并确保所有工作负载能在固定时间范围内完成更新。

在技术实现上，这一过程通过 Istio 控制平面的双版本部署来完成，并结合金丝雀发布策略，每个版本通过 revision 标签区分（例如 1-24-5、1-25-2）。工作负载通过 mutating webhook 绑定到指定 revision，从而注入相应的 istio-proxy sidecar。升级过程会根据 rollouts.yml 文件中定义的分发规则，有选择地将部分工作负载切换到新版本。

为了避免不同团队手动更新标签，Airbnb 使用了内部的 Krispr 变更框架。在 CI 流程中，Krispr 会根据发布配置将正确的 revision 标签注入到工作负载规范中。它还会在准入时持续迁移旧 Pod，确保在四周内所有工作负载（包括不活跃的）都能顺利完成迁移。

对于 VM 工作负载，Airbnb 借助 mxagent 守护进程，它会轮询各主机的版本标签，并在必要时一次性完成 istio-proxy 及其配置的升级。一个中央控制器（mxrc）负责协调 VM 的升级发布，它会遵循健康检查与升级安全阈值，类似 Kubernetes 的 maxUnavailable 机制。

在 Airbnb 成功完成最近的服务网格升级之外，业内其他公司也采用了各自不同的升级方式：

Netflix 推出了自己的零配置服务网格。它没有依赖重量级的控制平面模型，而是设计了一个能自动管理服务发现、重试和流量路由的网格，不需要手动配置。这样，Netflix 避开了多版本 Istio 升级中的协调挑战，同时仍然获得了服务网格在流量管理和可靠性方面的好处。

作为全球最大的 Kubernetes 部署之一，LinkedIn 在升级核心基础设施（包括 Kafka 和网络层）时，通常会结合使用金丝雀发布和流量镜像。在服务间通信栈方面，LinkedIn 曾经尝试过基于 Envoy 的解决方案，但更多依赖于带有镜像流量的渐进式发布流水线来确保安全性。这种做法在理念上与 Airbnb 的双 Istio 版本策略相似：两者都能在正式切换前，用新版本先行验证流量。

作为 Istio 的创建者之一，Google Cloud 自身为客户率先提供了多版本控制平面，类似 Airbnb 的实现。GKE 现在支持运维人员同时运行多个 Istio 版本，从而让发布与回退更为简便。Google 还在推动 Ambient Mode，这种模式用轻量级数据平面代理替代 sidecar，大幅减少升级影响范围。Airbnb 已经表示对 Ambient Mode 感兴趣，表明其方向与 Google 的下一代网格演进保持一致。

Uber 运行着一个基于 Envoy 的内部网格框架，并与其定制的服务发现系统深度集成。他们的升级策略通常是按集群逐步部署，而不是通过精细的版本绑定。Uber 还投入大量资源开发工具，用于在升级期间实现自动回滚并执行 SLA 监控，在一定程度上，可以看作是 Airbnb 用于 VM 的 mxagent + mxrc 机制的类似做法。

这些对比反映了一个更广泛的行业趋势：企业不断投入更先进的发布框架或服务网格创新，以平衡复杂性、可靠性与运维可控性。

展望未来，Airbnb 打算尝试 Istio 的 Ambient Mode，以实现更轻量的网格架构，同时通过拆分网格来减少风险范围并提高隔离性。

原文链接：

https://www.infoq.com/news/2025/08/airbnb-istio-upgrade/