FEATURE: scaling/replication trigger configuration

[3GDXC]

Please consider an abstraction for auto-scaling of containers and/or trigger rules using Kubernetes KEDA (locally) and/or Azure Container Services, Amazon Web Services EKS etc.

[davidfowl]

Do you want to help design this? In order to design an abstraction for something like this the capabilities of each of those services (and others) need to be analyzed so there's an understanding of what commonalities can be abstracted to build such an abstraction. I would start by trying to understand what it would mean to model a single environment (there's no support for that today) and I don't even have an understanding of what that would look like.

[3GDXC]

I would definitely be interesting in helping define and implement scaling; as I personally see scaling to be a key cloud feature, my initial idea would be to extend the ReplicaAnnotation(int x) with a ReplicaAnnotation(int min, int max) which would serve as the limiter for any scaling trigger configuration bound to the service.

[3GDXC]

@davidfowl I've created a fork of aspire for work on the scaling feature at https://github.com/3GDXC/aspire and have started with the ReplicaAnnotation mentioned above; including tests for the annotation etc.

[3GDXC]

basic starter

1. what to scale need to determine what types of resource can/should be scaled.

   • nodes
   • pods

2. what types of scaling need to determine the types of scaling operations.

   • up
   • out

3. when to scale need to determine the events that can be used to trigger a scaling operation.

   • cpu
   • memory
   • external event

what/where the annotations should be placed

[mitchdenny]

@davidfowl would it be better to control this via compute customization. I think it would be difficult to come up with a model that was abstract enough to work across the variety of compute resources we'll eventually target.

[3GDXC]

@mitchdenny I see this as a possible configuration and deployment of keda/triggers for keda to then listen and respond to in a Kubernetes deployment senario; and when deployed to other container/non-container senario the tooling for that deployment using the keda configuration to (attempt) to acheive the same scaling. If the Keda scaling triggers etc. can't be acheive by the deployment (target) tooling then a message/exception should detail the scaling option/trigger is not availible for the deployment (target). I see the inital triggers CPU, memory, request queue, hooking into the health checks, these health checks would have tags associated with them to determin which check is linked to which scaling action; as this would allow for custom/complex health checks to perform some scaling action.