Add design proposal for K8s-aware vMCP with dynamic backend discovery #2884
+760
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2884 +/- ##
=======================================
Coverage 56.00% 56.00%
=======================================
Files 328 328
Lines 32314 32314
=======================================
+ Hits 18096 18099 +3
+ Misses 12680 12670 -10
- Partials 1538 1545 +7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
jhrozek
force-pushed
the
thv-k8s-rework
branch
from
018ebef to
f98d0be
Compare
github-actions
bot
added
size/M
jhrozek
force-pushed
the
thv-k8s-rework
branch
from
f98d0be to
c8f6fc6
Compare
github-actions
bot
added
size/M
jhrozek
force-pushed
the
thv-k8s-rework
branch
from
c8f6fc6 to
ac8ad1b
Compare
github-actions
bot
added
size/M
jhrozek
force-pushed
the
thv-k8s-rework
branch
from
ac8ad1b to
485eeb9
Compare
github-actions
bot
added
size/M
JAORMX
reviewed
Dec 4, 2025
JAORMX
reviewed
Dec 4, 2025
The vMCP implementation currently has duplicated logic between the operator and vMCP server. The operator discovers backends, resolves ExternalAuthConfigs, and embeds backend configuration into a ConfigMap. Meanwhile, the vMCP server has its own discovery code but only loads config statically from the ConfigMap at startup. This duplication creates inconsistency risk, requires pod restarts for backend changes to take effect, and has grown the operator complex with auth resolution logic scattered across components. This proposal flips responsibilities: the operator becomes a "dumb" infrastructure manager handling only Deployment/Service/RBAC, while vMCP becomes "smart" by running controller-runtime with informers to watch MCPServer/ExternalAuthConfig/Secret resources directly. Relates-to: #2855
Clarify that vMCP's K8s API access to secrets is scoped to the same namespace through two mechanisms: 1. RBAC: Operator creates namespace-scoped Role (not ClusterRole) 2. API design: SecretKeyRef has no Namespace field Also document the idiomatic controller-runtime pattern for secret change propagation using Watches() with mapping functions. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Introduce two mutually exclusive discovery modes for VirtualMCPServer, selected via outgoingAuth.source: Dynamic mode (discovered): - vMCP runs controller-runtime with informers - Watches MCPServer/ExternalAuthConfig/Secret resources - Real-time backend updates without pod restarts - Requires namespace-scoped K8s API access Static mode (inline): - Operator discovers MCPServers, embeds config in ConfigMap - All auth configuration inline in VirtualMCPServer spec - Secrets mounted as environment variables by operator - vMCP has zero K8s API access (no RBAC resources created) This addresses security concerns about internet-facing vMCP pods having K8s API access while still supporting dynamic discovery for environments that need it. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
CLI mode and K8s static mode both use one-time discovery at startup with immutableRegistry. Only K8s dynamic mode adds controller-runtime complexity. This simplifies implementation since CLI and K8s static share identical vMCP binary behavior. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
jhrozek
force-pushed
the
thv-k8s-rework
branch
from
485eeb9 to
09378f1
Compare
github-actions
bot
added
size/L
JAORMX
approved these changes
Dec 8, 2025
github-actions
bot
added
size/L
github-actions
bot
added
size/L
github-actions
bot
added
size/L
JAORMX
approved these changes
Dec 9, 2025
github-actions
bot
added
size/L
github-actions
bot
added
size/L
JAORMX
approved these changes
Dec 9, 2025
github-actions
bot
added
size/L
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The vMCP implementation currently has duplicated logic between the operator and vMCP server. The operator discovers backends, resolves ExternalAuthConfigs, and embeds backend configuration into a ConfigMap. Meanwhile, the vMCP server has its own discovery code but only loads config statically from the ConfigMap at startup.
This duplication creates inconsistency risk, requires pod restarts for backend changes to take effect, and has grown the operator complex with auth resolution logic scattered across components.
This proposal flips responsibilities: the operator becomes a "dumb" infrastructure manager handling only Deployment/Service/RBAC, while vMCP becomes "smart" by running controller-runtime with informers to watch MCPServer/ExternalAuthConfig/Secret resources directly.
Relates-to: #2855