你的Kubernetes健康检查正在意外唤醒服务。这是解决方案。
内容提要
KubeElasti的ProbeResponse功能解决了Kubernetes服务缩容至零时健康检查误触发扩容的问题。该功能在解析器层匹配探针规则，直接响应健康检查请求，不触发扩容，使服务保持真正空闲。它支持方法、路径、头和查询参数匹配，仅在代理模式生效，无额外开销，特别适合GPU工作负载和许可软件场景。
延伸解读
健康检查与缩容的冲突根源
文章指出，负载均衡器需要确认服务存活，而自动扩缩器需要确认服务已死，两者天然矛盾。当服务缩容至零后，负载均衡器仍会定期发送健康检查，这些请求被解析器视为扩容信号，导致服务不断被唤醒，无法真正空闲。这种冲突在云负载均衡器、Kubernetes探针和平台监控中普遍存在，是缩容至零难以落地的根本原因。
传统方案的局限
常见的建议是将健康检查路由到独立服务，但文章认为这不可行：云负载均衡器无法指定不同后端，分离路由增加运维复杂度且易漂移，更重要的是健康检查端点本身就是应用端点。其他工具通过常驻代理拦截请求，但会引入延迟和架构妥协。ProbeResponse通过在解析器层直接响应探针，避免了这些弊端。
适用场景与配置要点
ProbeResponse特别适合GPU工作负载、许可软件和内部服务，这些场景下健康检查导致的冷启动成本高昂。配置前需审计所有健康检查来源，包括云负载均衡器、Ingress注解、外部监控和服务网格。规则支持方法、路径（精确/前缀/正则）、头和查询参数匹配，需确保响应体与真实服务一致，并利用头或参数区分健康检查与真实流量。
Q&A
KubeElasti的ProbeResponse功能主要解决什么问题？
它解决了Kubernetes服务缩容至零时，健康检查请求误触发扩容的问题，使服务能保持真正的空闲状态。
ProbeResponse是如何工作的？
当服务缩容至零时，KubeElasti的解析器会拦截所有流量。ProbeResponse在解析器层添加匹配规则，如果请求匹配探针规则，解析器直接返回预设的响应（如200 OK），而不通知操作员触发扩容，从而保持工作负载为零。
ProbeResponse支持哪些匹配条件？
支持HTTP方法（如GET、HEAD）、路径匹配（精确、前缀、正则）、请求头匹配（所有条件AND）和查询参数匹配（所有条件AND）。规则按顺序评估，第一个匹配的规则生效。
ProbeResponse在什么模式下生效？
仅在代理模式下生效，即当服务缩容至零、解析器处于活动状态时。当服务有活跃Pod时，解析器不在请求路径中，因此不会产生任何性能开销。
哪些场景最适合使用ProbeResponse？
GPU工作负载、许可软件、内部开发服务等场景。这些服务成本高或需要保持空闲，但健康检查会频繁唤醒它们，ProbeResponse能避免不必要的扩容。
配置ProbeResponse前需要做哪些准备？
需要审计所有健康检查来源，包括云负载均衡器、Kubernetes ingress注解、uptime监控（如Prometheus Blackbox Exporter）和服务网格（如Istio）。记录它们的路径、方法和频率，然后为每个来源创建对应的ProbeResponse规则。
ProbeResponse与传统的健康检查分离方案相比有什么优势？
传统方案如将健康检查路由到独立服务或使用始终在线的代理，会增加复杂性和延迟。ProbeResponse在解析器层直接处理，无需额外组件，且服务运行时零开销，避免了架构妥协。
