Pinterest 在迁移到 Kubernetes 的过程中发现了罕见的搜索失败

作者 | Craig Risi

译者 | 刘雅梦

策划 | 丁晓昀

Pinterest 的工程师 最近披露 了他们在将搜索基础设施迁移到 Kubernetes 时遇到的一个极其罕见的“百万分之一”故障的调试过程，这一举措旨在现代化运维并提高可扩展性。这一事件突出了大规模云原生迁移的技术挑战，以及在分布式系统中需要细致的调试流程。

这个故障是在 Pinterest（负责数十亿用户查询的搜索系统的搜索系统）迁移到基于 Kubernetes 的部署过程中出现的。工程师发现会偶尔出现查询不匹配问题，这些不匹配问题发生的频率极低，导致难以重现。问题在多个测试环境中持续存在，促使工程师深入研究基础设施交互、查询路由 和存储后端。

经过广泛的调查，该团队追溯到故障的根本原因是在容器化搜索组件和遗留基础设施之间过渡时引入的细微不一致。故障是由网络和存储同步中的一种罕见的时序条件触发的，这种场景在正常流量下几乎不可见，但在高流量测试中会暴露出来。

Pinterest 的调试方法结合了组件的增量隔离、自定义日志记录和使用捕获的生产流量重放来识别异常。工程师开发了专门的诊断工具，实时比较新旧系统之间的结果，使他们能够大规模地确定差异。

这一事件凸显了将关键任务搜索和推荐系统迁移到 Kubernetes 这一更广泛行业领域所应汲取的教训。即使是计划周密的迁移，也可能揭示出之前未曾见过的边缘情况，这就要求组织投资于强大的可观测性、混沌测试 和混合部署策略，以确保平稳过渡。

Pinterest 成功解决这一问题，最终为完成其迁移铺平了道路，为其搜索基础设施提供了更灵活的扩展和标准化编排。事后分析突出了在进行云原生转型的大型分布式环境中进行系统调试的操作复杂性和价值。

虽然 Pinterest 的调试故事是独一无二的，但其他大型科技公司在现代化搜索基础设施时也面临着类似的挑战。例如，Netflix 将其部分推荐和搜索系统迁移到 Kubernetes，但在完全部署之前严重依赖于金丝雀部署和混沌测试来发现罕见的错误。他们的重点是自动回滚机制和合成查询重放，Pinterest 也采用了这些策略，但由于他们的缺陷出现的频率极低，因此必须进一步细化。

多年前，LinkedIn 将其搜索平台 Galene 迁移到容器化环境时也遇到了类似的困难。与遇到时序不匹配问题不同，LinkedIn 的团队报告了跨集群的索引延迟和状态同步问题，他们通过开发强大的内部可观测性管道和最小化查询影响的滚动迁移来缓解这些问题。他们的经验与 Pinterest 的教训相呼应，即罕见的边缘情况通常只会在高峰流量负载下出现，要求进行详尽的预生产流量镜像。

Airbnb 也记录了 将实时服务迁移到 Kubernetes 期间 的类似经历。他们的方法包括采用服务网格和流量跟踪，在生产环境中并行测试新集群，在不影响用户的情况下帮助检测异常。这与 Pinterest 的流量重放使用相呼应，但也凸显了一个日益增长的行业实践，即增量切换策略，以降低迁移风险。

这些公司的共同点很明显：将核心搜索或推荐系统迁移到 Kubernetes 总会暴露隐藏的依赖关系、网络边缘情况和时序敏感的缺陷。一致性解决方案模式涉及分层可观测性、重放框架和逐步推出策略，这强化了在现代分布式系统中构建健壮的预部署验证的重要性。

https://www.infoq.com/news/2025/08/pinterest-search-failure-k8/

声明：本文为 InfoQ 翻译，未经许可禁止转载。