-
Notifications
You must be signed in to change notification settings - Fork 28
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
refactor: Split the agent and api controllers #446
Conversation
|
||
### Overview | ||
|
||
Previously, in the ngrok Ingress Controller, the Tunnel Controller(non leader-elected) ran under the same manager as the rest of the API controllers(leader-elected). This did not allow users to independetly scale the data forwarding and API management features. Going forward, we will be splitting the Tunnel Controller into its own manager so that it can be scaled independently of the rest of the controllers. This will allow users to scale the data forwarding and API management features independently. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I like the historical context, but I feel that the history should come after the present.
Perhaps this paragraph can be 2 paragraphs:
- The current architectural intent with 2 deployments
- The historical reasoning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that format. This will change again once we include the bindings forwarder. I think I'm going to leave it for now since it will get changed soon and reword it for current state once we have the bindings piece
Splits the agent and API controllers into their own managers and k8s deployments. This separates the data path from the API configuration path so that one or the other can easily be turned on or off and scaled independently.
b19cf1f
to
87c5c0a
Compare
What
Splits the agent and API controllers into their own managers and k8s deployments. This separates the data path from the API configuration path so that one or the other can easily be turned on or off and scaled independently. This also helps with providing an upgrade path from the ngrok Ingress Controller to the new ngrok operator.
How
Breaking Changes
There should not be. This should be a passive change.