adds proposal for toolhive k8s deployment architecture #1497
Conversation
Signed-off-by: ChrisJBurns <29541485+ChrisJBurns@users.noreply.github.com>
Signed-off-by: ChrisJBurns <29541485+ChrisJBurns@users.noreply.github.com>
Signed-off-by: ChrisJBurns <29541485+ChrisJBurns@users.noreply.github.com>
|
Initial thoughts. This makes a lot of sense to me @ChrisJBurns. The operator should indeed be taking responsibility for both the deployment and statefulset creation, and then also their association with various kubernetes services and other resources such that their reconciliation and reclamation can happen cleanly. I also like the idea of having the proxy still being able to request an mcp server replica + or - depending on the load it is experiencing, and while the operator has the big picture the proxy will have the data to determine the need most directly. |
|
|
||
| As described above, the current deployment architecture has it's pains. The aim with the new proposal is to make these pains less painful (hopefully entirely) by moving some of the responsibilities over to other components of ToolHive inside of a Kubernetes context. | ||
|
|
||
| As described above, the current deployment architecture has several pain points. The goal of this proposal is to reduce (ideally eliminate) those issues by shifting certain responsibilities to more appropriate components within ToolHive’s Kubernetes deployment. |
There was a problem hiding this comment.
These two "As described above" sections seem equivalent
|
Thanks for updating the architecture and making it more coherent with standard k8s deployments @ChrisJBurns. |
|
great work thanks @ChrisJBurns |
Wanted to get some early thoughts on this.
@ChrisJBurns to refine technical details if needed