-
Notifications
You must be signed in to change notification settings - Fork 132
Add MCPGroup CRD proposal for Kubernetes operator #2207
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
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2207 +/- ##
=======================================
Coverage 52.99% 52.99%
=======================================
Files 223 223
Lines 29057 29057
=======================================
Hits 15399 15399
Misses 12534 12534
Partials 1124 1124 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
@eleftherias we can probably create a default group in k8s too; We can add a I think one issue is going to be namespaces though.... meaning, two groups of the same name in different namespaces are going to effectively be different. I don't think we should support cross-namespace references as that will complicate things a lot. |
This proposal introduces MCPGroup support to the Kubernetes operator, enabling Virtual MCP Server and logical grouping of MCPServer resources. Key design decisions: - Explicit groupRef field in MCPServer spec (follows K8s naming conventions) - Simple MCPGroup CRD with minimal spec (description) and status tracking - Namespace-scoped groups for security/isolation - No webhooks - controller-based validation for simplicity - Optional group membership (unlike CLI where groups are required) Design rationale: - MCPGroup as first-class construct (not just labels) enables meta-mcp and virtual MCP to discover and aggregate backend servers - Provides seamless CLI-to-Kubernetes transition with consistent API - Explicit group lifecycle management and validation - Foundation for growing ecosystem of ToolHive constructs 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
ec430e1
to
254f920
Compare
Thanks for the thorough review, @ChrisJBurns! I've addressed all your feedback:
Regarding your excellent question about labels vs CRD - you're absolutely right to ask! I've added a section explaining the reasoning: Main drivers:
While labels could work technically, they lack discoverability, metadata storage, and explicit lifecycle management that these aggregation features need. Also added a note about the CLI difference that @eleftherias mentioned - CLI requires groups (with default), K8s makes them optional. Let me know if you'd like any other changes! |
Summary
This PR introduces a proposal for adding MCPGroup support to the Kubernetes operator, enabling the Virtual MCP Server feature and logical grouping of MCPServer resources.
What does this PR do?
Adds a technical proposal document that outlines the design for MCPGroup Custom Resource Definition (CRD) in the Kubernetes operator.
Key Design Decisions
group
field to MCPServer spec (matches CLIWorkload.Group
behavior)spec.group=engineering-team
Why This Design?
spec.group
field is predictable and easy to queryBenefits
Related Issues