Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add service mesh / GAMMA project based scaling #6

Open
Tracked by #350
arschles opened this issue Jan 14, 2021 · 15 comments
Open
Tracked by #350

Add service mesh / GAMMA project based scaling #6

arschles opened this issue Jan 14, 2021 · 15 comments
Labels
enhancement New feature or request good first issue Good for newcomers Hacktoberfest Great issues to tackle for Hacktoberfest 2021 stale-bot-ignore All issues that should not be automatically closed by our stale bot traffic-sources All issues related to where HTTP traffic can come from

Comments

@arschles
Copy link
Collaborator

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 added a commit that referenced this issue Jan 27, 2021
* starting the scaler and interceptor

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Adding interceptor

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* link to issue

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* operator and CLI start

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* starting on the dockerfiles

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Improving the operator Dockerfile

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* fix

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* note

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* adding go based operator

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* a bit of progress

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* moving rust operator to old

will delete this shortly

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* moving goperator to operator

forgot to do this last commit

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* moving go.mod to root

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* marking deprecated

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* it builds
gs

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* progress on the operator

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* more progress

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* more

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* All my changes and implementations (#2)

* Fix error with existing variable

* Rename ScaledObject to HTTPScaledObject

* Add draft implementation for status spec

* Rename files to match new naming

* Remove scaffolding comments

* Change requeue time to 50s

* Variable renaming to better read

* Add new spec field to make polling configurable

* Remove previously added objects in case of error

* Set Statuses

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Fix Typos (#4)

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Add RBAC rules for services, pods and deployments (#5)

* Fix Typos

* Add RBAC rules for services, pods and deployments

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Bunch of changes (#6)

* Fix Typos

* Implement object deletion

* Add prefix for logging

* Remove unused status interface

* Add status check for "Ready"

* Golint

* Generate CRD Manifests

* Reorder RBAC Roles

* Change file namings

* Remove CLI part for now

* Add internal build context for operator

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Charts, docs, readability and other changes (#8)

* Fix Typos

* Implement object deletion

* Add prefix for logging

* Remove unused status interface

* Add status check for "Ready"

* Golint

* Generate CRD Manifests

* Reorder RBAC Roles

* Change file namings

* Remove CLI part for now

* Add internal build context for operator

* Remove Rust-related things

* Add comment docs and reorder packages

* Change variable name and add package docs

* Add package docs

* Add package docs

* Rename var for readability

* Adds package docs

* Remove commented code

* Remove unused admin echo server and rename current one

* Add more logging and docs

* Fix doc

* Update readme on cli

* Add scaffold to operator chart

* Add docs

* Golint

* Update name in kustomization

* Add descriptions to fields

* Update default image name

* Change resource names

* Add version tag to kustomization

* Add make command for charts

* Create base values file

* Add patch for image name

* Add environment variable to manager

* Update charts/operator/Chart.yaml

Co-authored-by: Tom Kerkhove <kerkhove.tom@gmail.com>

* Update charts/operator/Chart.yaml

Co-authored-by: Tom Kerkhove <kerkhove.tom@gmail.com>

* Correct dir name and reuse step

* Rename dir to keda-http-operator

* Add envs to deployment pkg

* Add new statuses for extended objetct

* Fixing interceptor listening port

* Include new "Terminating" status

* Add namespaces for logs

* Change variable names

* Add new statuses

* Code reorder

* Create interceptor

* Add missing return

* Remove comment

* Fix link

* Remove all references to external scaler address

This is because we'll use one external scaler for each new application, so there's no point in having a single environment variable controlling the
address of the external scaler.

The address will be defined by the operator for each new app and a new scaler will be created.

* Fixing external scaler port

* Code reorder and creation of external scaler

* Improve code readability

* Golint

* Add colons

* Further clean the code

* Move functions to other file

* Rename files

* Add more meaninful names

* Rename method

* Update roles and enums

* Make yamls

* Add next TODO

* Add todo

Co-authored-by: Tom Kerkhove <kerkhove.tom@gmail.com>
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Fixing the operator Dockerfile

also adding env vars to allow users to customize docker image names

Fixes #5

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Updating to the KEDA 2.0 external scaler gRPC interface

The notable change here is that there is an added StreamIsActive
RPC call. The New and Close RPCs are removed.

Fixes #3

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Making the scaler talk to interceptors to get pending HTTP queue sizes

Fixes #4

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Initial install docs

Includes various tweaks needed to make install work

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* more

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* more progress

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* proper port and path

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* splitting up helm chart

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* fix chart, example yaml, and fix panic in operator logging

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* fixing log errors

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* minor changes

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* gracefully moving on when deleting kube resources

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* creating dynamic client

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* using proper group for scaled objects

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* adding scaledobject to ClusterRole

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Helm installation in the Makefile

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* more loggign

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* properly specifying namespaces etc...

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* setting operator deployment pull policy to always

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* adding more logs to resource creation

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* fixing namespace problems and simplifying code

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* proper API version

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* aking image names and ports for external scaler and interceptor configurable

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* adding docs

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* proper env var names

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Specifying proper external scaler ports

Also moving the application config in the operator into operator/config

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* ports

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* updated ScaledObject spec

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* proper port formatting for interceptor

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* more logging and not requeueing

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* cscaler => kedahttp

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* trying something out

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* adding finalizer, simplifying get code

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* finalizers

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* ignoring more stuff

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* removing the right things

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* updating deletion & error logic

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* logging status updates

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* check for already exists inside specific creator logic

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Fiddling with status

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* upgrading CRD version

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Adding instructions on microk8s installs

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* Restoring the status file

Don't know why I deleted it in arschles@021b5f1

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* myapp => xkcd

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* service type

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* logging

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* configuring services properly

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

* readme

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>

Co-authored-by: Lucas Santos <lhs.santoss@gmail.com>
Co-authored-by: Tom Kerkhove <kerkhove.tom@gmail.com>
@arschles arschles added the enhancement New feature or request label Feb 9, 2021
@tomkerkhove tomkerkhove added the traffic-sources All issues related to where HTTP traffic can come from label Feb 12, 2021
@arschles
Copy link
Collaborator Author

arschles commented Feb 12, 2021

Service meshes we should consider supporting:

  • Gloo
  • LinkerD
  • Istio
  • Kong
  • Kuma

Others??

@tomkerkhove
Copy link
Member

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

@arschles
Copy link
Collaborator Author

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
Copy link
Member

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

@vitarkah
Copy link

AWS App Mesh

@arschles arschles added the good first issue Good for newcomers label Feb 24, 2021
@arschles
Copy link
Collaborator Author

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

@arschles arschles added the Hacktoberfest Great issues to tackle for Hacktoberfest 2021 label Oct 11, 2021
@stale
Copy link

stale bot commented Dec 11, 2021

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.

@stale stale bot added the stale All issues that are marked as stale due to inactivity label Dec 11, 2021
@tomkerkhove tomkerkhove added stale-bot-ignore All issues that should not be automatically closed by our stale bot and removed stale All issues that are marked as stale due to inactivity labels Dec 11, 2021
kingdonb pushed a commit to kingdonb/http-add-on that referenced this issue Jun 12, 2023
@ajonnavi
Copy link

Hi there, I am curious about the status of this ticket. The roadmap seems to indicate that it's still in the works, but looks like no one is assigned.

As it stands, is it possible at all to use the http add-on with in a cluster that has service mesh?

@tomkerkhove
Copy link
Member

If traffic goes through it, yes. But there is no integration

@tomkerkhove tomkerkhove changed the title Add service mesh / SMI based scaling Add service mesh / GAMMA project based scaling Sep 28, 2023
@ajonnavi
Copy link

But there is no integration

What does that mean? We want to use this for a specific usecase - we have dev deployments that we want to scale to 0 when there is no traffic, and activate and scale back up to previous value when traffic starts again (usually 1 pod), but we also use a service mesh (Istio) and I was wondering how the traffic would flow in that case since envoy already exists as a proxy.

Would this work in current form?

@nvcnvn
Copy link

nvcnvn commented Sep 30, 2023

Maybe also consider https://traefik.io/traefik-mesh/ ?

@ajonnavi
Copy link

ajonnavi commented Oct 3, 2023

Does it have a direct integration or built-in support? Ripping up a fully functional service mesh and replacing it with a new one is a very costly endeavor.

@tomkerkhove
Copy link
Member

The idea is that the used service mesh technology does not have to be changed and we just plug in.

Given the range of service meshes, we should rely on GAMMA

@nvcnvn
Copy link

nvcnvn commented Oct 5, 2023

oh, sorry, a little confuse from my side, I think the traefik mesh compatible with GAMMA but turn out it only follow SMI (but I was thinking that SMI and GAMMA somewhat closed to each other also but it is not).

@pasi-romo-idealo
Copy link

Did someone get this working in the current form in service mesh? We are using Istio and I tried deploying the addon with the side-car injection enabled. The controller runs without problems but external scaler and interceptor pods do not come up due to failing readiness and liveness checks.

wozniakjan added a commit to wozniakjan/http-add-on that referenced this issue Jul 18, 2024
…ontrol_plane

Interceptor: envoy xDS control plane
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers Hacktoberfest Great issues to tackle for Hacktoberfest 2021 stale-bot-ignore All issues that should not be automatically closed by our stale bot traffic-sources All issues related to where HTTP traffic can come from
Projects
Status: To Do
Development

No branches or pull requests

6 participants