Add design proposal for K8s-aware vMCP with dynamic backend discovery #2884
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2884 +/- ##
==========================================
- Coverage 56.59% 56.41% -0.19%
==========================================
Files 322 322
Lines 31439 31643 +204
==========================================
+ Hits 17794 17851 +57
- Misses 12110 12254 +144
- Partials 1535 1538 +3 ☔ 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
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
jhrozek
force-pushed
the
thv-k8s-rework
branch
from
ac8ad1b to
485eeb9
Compare
github-actions
bot
added
size/M
| changes, the informer notifies vMCP which re-resolves auth for affected | ||
| backends. This provides a fast request path while handling secret rotation | ||
| automatically. The existing code in `pkg/vmcp/workloads/k8s.go` already | ||
| follows this pattern. |
There was a problem hiding this comment.
I feel shaky about this because the vMCP server is actually exposed to the internet and receives/serves customer traffic. The operator having extra powers is not too bad given that the operator is beholden to the k8s API and does not serve traffic nor is exposed. But this flip can be tricky. I rather defer this and keep the vMCP server just being aware of secrets via environment variables or files. Files might even be ideal since the process can leverage fsnotify or a similar strategy to react to changes.
| CLI mode should remain static with one-time discovery at startup. Local | ||
| development sessions are typically short-lived, and adding dynamic discovery | ||
| to CLI would add complexity for limited benefit. This can be revisited as a | ||
| separate work item if there's demand. |
There was a problem hiding this comment.
Is this section necessary? If the refactor of vMCP leads to a dynamic CLI mode, that would be a win. Let's not add constraints where they're not needed and work on a best-effort approach instead.
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