Sonos 是一家总部位于美国加利福尼亚的家庭智能无线音响制造商，主要研发和生产家庭无线智能音响系统。
通过不同产品组合满足用户个性化的家庭音乐娱乐需求，Sonos 将无线技术与高品质声音完美结合，以支持用户多样化的音乐服务。
2016 年，Sonos 实现年营收 9 亿美元，两年后成功登陆纳斯达克；到今天，年收入已突破 15.2 亿美元，产品累计销售超过 4928 万台，进入超过 1600 万个家庭。
作为 Karpenter 的早期采用者，Sonos 在 Kubernetes 环境中积极探索弹性伸缩与 Spot 实例的组合，成功实现了成本优化与高可用性的平衡，还在内部建立起了完整的推广机制。
本文将在 Sonos 的资深 DevOps 工程师 Josh Cipher 的实战经验分享下，带你深入了解 Sonos 团队如何通过 Karpenter 和 Spot 实例，构建出自动化、高弹性、可预测且更具性价比的云原生基础设施。
Karpenter 带来的变化
作为 Karpenter 的先驱用户，在采用这项节点自动伸缩技术后，最显著的改变是基础设施管理的简化。
过去，我们需要维护复杂的节点池配置，维护一大堆 NodePool，花费大量的人力和精力进行长期的容量规划、实例类型分析。
现在通过 Kubernetes 和 Karpenter 的结合，我们可以只关注架构需求，不用每天盯着 AWS 新发布的 800 种实例类型。
团队从最开始对"你为什么要选这个实例类型？为什么不换个更便宜的？"争论不休，进化到能够选一组合适的实例类型扔给 Karpenter，让它根据实际 Pod 的资源使用情况自动做决策。
通过 Karpenter 优雅的 API 和设计理念，工程师团队能够更直观地理解和协作管理，可读性和沟通效率都提升很多。
在我看来，Karpenter 带来的最有意义的变化就是让工程师可以真正专注在那些能为组织创造价值的事上，而不是一直处理基础设施的重复性劳动。
虽然我们仍然需要 IaC 和强配置管理来保证可重复性，但有些事情确实更适合自动化工具去做。
我们不用再考虑要不要为某个特定架构专门维护一个节点组，也不用手动调优每个集群。省下的时间我们能够去做更有价值的工作，比如改进我们的平台。
部署与推广
作为集中管理的 DevOps 团队，为了向其他部门推广这项技术，我们采取了两步走的分阶段策略。
早期我们团队就在推 Kubernetes，到 EKS 平台后，自然引入了 Karpenter。我们先为各个服务做实操演示，展示效果，然后再邀请大家进行迁移。
过程中的关键是与各团队建立伙伴关系------部分团队自己上线，部分团队依赖我们协助配置。
这种紧密的协作方式对新技术落地至关重要，只有实际部署后，大家才能看到直观的效益。
成本可视化的重要性
除了自动化流程，成本的可视化也很关键。
数据呈现能帮助工程团队对数据理解得更清楚、更具可扩展性地广泛使用服务。尤其当服务规模大、调用多时，相较于手动扩容，这套方案的节省效果会更加明显，对上层决策的推动力量会更强。
最欣赏的三大特性
🟢节点中断控制
节点中断控制（PDB）可限制同时被驱逐的 Pod 数量，防止在 Spot 实例回收时大批 Pod 同时终止，当 Karpenter 清空节点时，它会遵守服务的 Pod 可用性，以免导致宕机。
这种限制对于在更新或扩展操作期间维持应用程序的可用性至关重要，确保在进行必要更新的同时，至少有部分 Pod 继续运行，从而保证 Kubernetes 环境的可靠性和稳定性。
🟢智能合并
Karpenter 利用合并（Consolidation）功能识别低利用率节点并将其移除或替换，可终止多个小实例，转而使用更大的实例，从而提高性价比并减少集群的管理成本。
🟢优雅终止周期
这听起来很简单，但是从安全和合规性角度来看，优雅终止周期允许设定节点的最大存续时间，使节点能够自动安全下线。
团队不再需要手动配置自定义脚本，不再需要为扫描工具额外付费，既提升了系统的安全性和稳定性，也降低了运维成本。
但 Karpenter 并不完美，在单副本工作负载高可用、bin-pack 时实例类型的选择、工作负载分布等方面都存在限制，点击此处查看这篇文章了解 Karpenter 的局限性及其解决方案。
Spot 实例带来的收获
Sonos 在 Spot 实例上的采用率很高，这其实是一件值得骄傲的事。不仅因为 Spot 实例帮助我们节省了不少成本，也考虑到了环境友好和对闲置资源的合理利用。
不是每家企业一开始都敢这么用 Spot 实例。
在传统观念里，大家都觉得应该先从最小单位做起，把容器包得紧紧的，再考虑节点大小、架构、RI 或 SP 的购买时机。
但我们发现，实际上使用 Spot 实例的灵活度更高 ，能够快速提升性价比，尤其是在迁移已有工作负载时。
成功的关键
第一，我们原本就有很多短生命周期的应用，Web 服务都是可以快速启停的，Spot 中断对我们影响不大。
虽然我们也有一些长期运行的任务，比如机器学习或语音服务，但大多数工作负载是非常适合用 Spot 的。
第二，我们用了一些提前预警工具 ，能给我们提供一点点 "预测能力" 。不是几秒钟的通知，而是几分钟的预警，这就有很大的帮助了。
通过内建的 Spot 智能预测引擎，CloudPilot AI 能提前最多 45 分钟预测 Spot 实例中断风险，并主动迁移和替换高风险节点，极大减少高峰期或部署期间发生资源中断的概率。
整体来看，Spot 实例成功给我们带来了 30%、40%，有时甚至 50% 的成本节省，而且我们可以选择超多种实例类型，不用只盯着 c6.8xlarge 这种热门型号担心资源抢不到。
推广的经验
要向工程团队推广 Spot 实例，不是件容易的事。
大家的第一反应通常是："不行，我的工作负载怎么可能被中断？"这就像《空中大灌篮》里的灌篮犯规，你知道其实没什么问题，但人们的本能反应就是"这犯规了"。
这其实更多是"人"的问题，而不是技术本身的限制。
我觉得这没什么不好，作为云平台工程的负责人，我希望我的团队能够对这种提议提出质疑，这样我就有机会用数据和实际案例去说服他们，这才是建设性的讨论方式。
我们采用 Spot 的方法是渐进式的，而不是一下子推翻整个基础设施重建。
作为 DevOps 团队，我们从自己的管理集群开始试水，"吃自己的狗粮"，先在自己负责的服务上应用 Spot 实例。
这个集群中大多数服务都不需要持久化，属于非常适合 Spot 实例的应用场景。
从这里开始，我们逐步将 Spot 实例引入到更广的测试环境中。 Sonos 有很多测试环境，涉及各种产品和固件的测试需求，负载很重。我们可以在多个环境中推广 Spot，进行实际验证。
我们还有一个名为 Performance 的预生产环境，它是我们生产环境的镜像。
我们会在 Perf 环境中做性能测试，比如扔给它每秒 15 万次的请求，观察系统在 Spot 实例下的表现，这为我们后续调优提供了极大便利。
所以我想给任何想采用 Spot 实例的团队一个建议：一定要花点时间做负载测试。
就算是用你自己随便写的一个小 Flask API、容器化部署一下，也没关系。
搭个简单的测试服务，用 Blazemeter 试用版或者 k6 这种工具，模拟真实流量，把数据打出来，观察行为，调整参数，测完之后分享给团队。这种自己先测试一遍的策略，效果是最好的。
我们从自己开始，花了几个月去按部就班地验证、推进，而不是一股脑地推翻重建。
说到底，我们做这些工作，是代表整个企业在行动，不仅仅只是为了优化某几个集群的成本------我们要确保策略正确，效果显著，才会稳步前进。
可预测性的意义
如果遵循 AWS 推荐的 Spot 实践，最大的收获就是 "可预测性" 。
Spot 实例并不神秘，更像股市，遵循一些简单原则：不要一把梭哈，要做好多样化。
预测 Spot 并不是什么玄学，而是统计数据、概率理念，在这些基础上再借助 AI 的能力。
CloudPilot AI 基于大量实际数据结合机器学习算法，升级了 Spot 预测引擎，可提前45分钟预测 Spot 中断事件，并自动将工作负载迁移至更稳定的实例上，使得 Spot 中断事件降低 90% 。
如果把 Spot 比作一张股票投资组合。什么时候节点生命周期结束，什么时候该切换实例系列，其实都有迹可循。
我们能从每 CPU 的成本、实例被中断的频率等各种角度去衡量和预测，一旦有了这样的度量基础，团队就无需自己从零构建算法工具，没有太多人力，也更容易向上沟通：我们在 Spot 上做得怎么样了，可以用数据说话。
局限性
不过，Spot 省钱，但不能把关键业务全部绑上它，我们都知道鸡蛋不能放到同一个篮子里。
即使我们有时候能做到 EKS 上平均 70% 的效果，也没有把数据库完全扔进 Spot ，依然保留按需付费与 Savings Plans 的混合模型。
这就像投资的组合策略：你不会把所有钱压在股票，有些保守资产要放在长期稳定的选择上。
我们会用按需实例或 Savings Plans 支撑关键业务，Spot 实例负责弹性伸缩，确保服务即使被中断，也不会大范围宕机。