Deezer 如何使用自定义指标实现 Kubernetes 自动扩展

Deezer 是一家流行的音乐流媒体服务公司，最近分享了他们如何通过自定义指标在 Kubernetes 基础设施中实现自动扩展的经验。自 2018 年以来，Deezer 在生产环境中成功使用 Kubernetes，主要部署在裸金属环境中，部分集群运行在公有云平台上。然而，服务器利用率和性能问题使得扩展应用程序到合适的大小和副本数量变得具有挑战性。

挑战与解决方案

Deezer 的工程团队发现，使用 Kubernetes 默认的水平 Pod 自动扩展（HPA）功能时，依赖 CPU 和内存使用率作为扩展指标并不能满足其应用程序的需求。为了更准确地扩展，他们构建了一个解决方案，使用 Prometheus 进行指标收集，并通过 Prometheus Adapter 将这些指标暴露给 Kubernetes。

关键技术：事件循环利用率（ELU）

Deezer 的创新之一是使用事件循环利用率（ELU）作为其 Node.js 应用程序的自定义指标。ELU 测量 Node.js 事件循环处理事件的时间与空闲时间的比例。团队发现，ELU 比 CPU 使用率更能代表服务器负载，尤其是在新 Pod 初始加载时 CPU 使用率可能会飙升的情况下。

实施步骤

Deezer 的实现包括以下几个步骤：

1. 部署 Prometheus 以收集应用程序特定的指标。
2. 配置 Prometheus Adapter 将 ELU 指标暴露给 Kubernetes。
3. 创建引用 ELU 指标的 HorizontalPodAutoscaler 资源。

团队在其博客文章中提供了详细的配置示例，展示了整个设置过程。

验证与测试

为了验证新的自动扩展设置，Deezer 使用了 Vegeta，一个 HTTP 负载测试工具。通过生成受控负载并监控 Pod 数量和 HPA 状态，确保系统在各种条件下都能按预期进行扩展。

其他案例与最佳实践

其他组织也成功使用自定义指标驱动自动扩展。例如，Pixie 编写了一个自定义指标服务器，而 Overcast 则介绍了如何使用队列长度作为自定义指标进行自动扩展。Loft 则详细分析了 HPA 的局限性，指出其依赖 CPU 和内存指标可能导致在突发流量情况下的扩展延迟，并建议使用 KEDA 或自定义指标以实现更快的响应。

挑战与建议

尽管基于自定义指标的自动扩展带来了显著的好处，Deezer 也承认其增加了系统的复杂性。团队强调了正确监控和调整 Prometheus Adapter 的重要性，因为它成为了自动扩展的关键组件。为了缓解潜在问题，Deezer 建议：

• 扩展 Prometheus Adapter 的副本以确保高可用性。
• 实施 PodDisruptionBudget 以在集群维护期间保持 HPA 功能。
• 为自动扩展基础设施设置全面的监控。

未来探索

Deezer 正在探索进一步改进其自动扩展设置的方法，分析更高级的场景，并考虑使用 KEDA（Kubernetes 事件驱动自动扩展）等工具以实现更大的灵活性。

通过这一系列的技术创新和实践，Deezer 成功提升了其 Kubernetes 基础设施的自动扩展能力，为其他面临类似挑战的组织提供了宝贵的经验和参考。