Add service mesh / GAMMA project based scaling

[arschles]

The interceptor works with the scaler to provide KEDA with the HTTP queue size, which KEDA in turn uses to scale the app. That arrangement lets a user submit a single HTTPScaledObject and have the operator create all the moving pieces required (interceptor, scaler, etc...). We should, however, support service meshes, or really any HTTP server that can (a) route traffic from outside the cluster into a pod (the app) and (b) emit SMI-compatible metrics.

Note: kedacore/keda has discussed consuming SMI metrics as well in kedacore/keda#615. This is a specific use case for consuming those metrics, but if KEDA core doesn't support SMI when we implement SMI support in the external scaler, it could be a "test drive" for building the same functionality into core

[arschles]

Service meshes we should consider supporting:

• Gloo
• LinkerD
• Istio
• Kong
• Kuma

Others??

[tomkerkhove]

We should only support SMI spec which is an open standard, the others are out of luck ;)

[arschles]

Ah yes, you're right. I just meant that we should look into those service meshes (I have no idea which ones support SMI at the moment) and, if they do, test our integration against them, include them in our docs, and so forth...

[tomkerkhove]

No problem! You can see all supported service meshes on https://smi-spec.io/

[vitarkah]

AWS App Mesh

[arschles]

As part of this work, we need to add documentation - including updating the architecture diagram - explaining how service meshes integrate with the HTTP add on

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.