KEDA运行是否需要配置Service、ServiceMonitor或Ingress资源？

1. KEDA是否必须定义Service和/或ServiceMonitor才能正常工作？ #

完全不需要，KEDA的伸缩逻辑和面向Web服务的常规HPA场景差异很大：

• 你当前对接ActiveMQ消息消费的场景，直接用KEDA官方内置的ActiveMQ scaler即可，这种模式下KEDA Operator会主动连接ActiveMQ Broker，直接拉取主题消息堆积量、在线消费者数等伸缩判断所需的核心指标，整个判定过程不需要和你部署的Spring Boot消费者应用产生任何网络交互，自然不需要给消费者创建Service，更用不着ServiceMonitor。
• 仅存在一种例外情况：你不使用内置的ActiveMQ scaler，选择prometheus类型的scaler，完全依赖自建Prometheus存储的自定义指标计算伸缩阈值，这时候才需要保证Prometheus能采集到对应指标。如果相关指标是从消费者应用本身暴露的，你可能需要配置Service支撑Prometheus抓数，但这属于自身指标采集链路的配置要求，不是KEDA的强制规则；而ServiceMonitor本身是Prometheus Operator生态下的服务发现CRD，如果你不用Prometheus Operator做自动抓数，而是手动配置Prometheus抓取目标，连ServiceMonitor都不需要创建。
• 补充说明：哪怕是原生HPA也不是所有场景都需要Service，只有依赖应用层自定义指标做伸缩时才需要考虑服务可达性问题，基于CPU、内存这类工作负载自带的资源指标做伸缩时，完全不需要Service。

2. 部署消息队列消费者是否有配置Ingress的必要？ #

没有对外暴露HTTP服务需求的话，完全没必要配置：

• Ingress的核心作用非常单一：就是将集群内的HTTP/HTTPS服务暴露到集群外部，为外部用户或系统提供七层访问入口，本身就是为Web服务、对外API这类需要承接外部流量的工作负载设计的。
• 纯消息队列消费者的运行逻辑是主动发起连接到ActiveMQ Broker拉取、处理消息，全程不会被动等待外部流量主动访问，没有对外暴露服务的刚需，配置Ingress属于冗余操作。
• 就算你有访问应用的需求，比如调用Spring Boot Actuator监控端点、临时调试接口，集群内访问建个ClusterIP类型的Service就足够，临时调试直接用kubectl port-forward做端口转发即可，不需要用到Ingress。

内容的提问来源于stack exchange，提问作者ThisIsJerryPepper