-
Notifications
You must be signed in to change notification settings - Fork 90
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
Enable dedicated interceptor/scalers with the same operator #241
Comments
Note that this functionality would interact with #240. See #240 (comment) for more details |
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. |
This issue has been automatically closed due to inactivity. |
Reopening with label to keep the stale bot from closing this. This is still a valid feature that we'd like to explore |
Discussed in #218
Originally posted by rwkarg August 4, 2021
This issue (#36) has been closed but I don't see a way to currently add annotations to the interceptor service.
The specific use case we have is using autoneg-controller to add workload instances from multiple clusters as backends to a single Load Balancer. In GCP, this requires that the service (would be the interceptor service) has two annotations to create the Network Endpoint Group (NEG) and to associate that NEG with a Backend Service on the Load Balancer (not important what it does, just that we need annotations on the interceptor service).
Looks like #206 may complicate this, if there is only one service. We can't add the annotations to individual services any more for
autonet-controller
to work in that case.Is the multi-tenant interceptor something that can be opted out of?
Further along in that discussion, @tomkerkhove and I talked through how to allow operators to opt-out of the shared interceptor/scaler while still using the same operator. in this proposal, I outline how to enable that exact scheme.
New CRD:
HTTPScalingComponents
The purpose of this new, optional, CRD, is to specify a set of running interceptor and scaler. Interceptor and scaler are always deployed together. When an
HTTPScalingComponents
CRD is submitted, the operator will react by ensuring the following are installed.Deployment
Service
s for proxy and admin endpointsScaledObject
Deployment
Service
s for gRPC and health check/admin endpointsSample YAML for a
HTTPScalingComponents
CRD would be similar to:Usage in
HTTPScaledObject
sA user submitting an
HTTPScaledObject
will optionally be allowed to specify the components that they would like their app to use. The field,scalingComponents
, would be used as follows:Note the new
spec.scalingInfrastructure
section.spec.scalingInfrastructure.name
specifies an already-installedHTTPScalingComponents
CRD and is optional. The HTTP Addon operator is configured with a defaultHTTPScalingComponents
on startup (and one is installed by default in the official helm chart). Users who omit thisname
field will simply use the defaultImplementation notes
The biggest changes will come to the operator if this proposal is implemented. The changes of note are:
HTTPScalingComponents
is createdHTTPScalingComponents
, and write one routing tableConfigMap
perHTTPScalingComponents
CRDDeployment
which aforementionedConfigMap
to consumeHTTPScaledObject
submission, createScaledObjects
that point to the proper scalerService
cc/ @rwkarg @tomkerkhove
The text was updated successfully, but these errors were encountered: