📋 Prerequisites
📝 Feature Summary
Support for multiple kagent instances in 1 cluster for staging purposes
❓ Problem Statement / Motivation
Description
Kagent has the potential to be run as multiple instances simulatenously in one cluster for staging new releases before fully upgrading. This can be accomplished through settings specific override values for rbac permissions in the kagent helm install. However, when doing this kcmp metrics can only be enabled on one instance
Requirements
- Run multiple kagent instances in separate namespaces on one cluster ( for staging purposes).
- Install a second instance without it failing on already-existing cluster-scoped resources.
- Keep kmcp controller metrics enabled while more than one instance runs on the cluster.
- Isolate each instance's RBAC to its own namespace across the whole suite, kmcp included.
Assessment
It appears the kagent chart already supports namespace-isolated installs: setting rbac.namespaces and kmcp.rbac.namespaces to the install namespace makes the kagent controller possible to run as multiple instances on one cluster. The remaining blocker comes from the bundled kmcp subchart, whose metrics authz RBAC is emitted with fixed cluster-scoped names, so a second instance collides on them.
This means multi-instance for staging works today only with kmcp metrics disabled (or enabled on a single instance). Once the kmcp chart scopes those names per release/namespace, the kagent chart should expose/propagate that so kmcp.rbac.namespaces (or the kagent namespace-isolation switch) fully isolates kmcp too with no per-instance metrics trade-off.
💡 Proposed Solution
These three objects genuinely need cluster-scoped APIs (tokenreviews/subjectaccessreviews and the /metrics nonResourceURL), so they can't collapse into namespaced Roles but they don't need fixed names. The fix is to template their names through the chart's existing fullname/release helper (the same one every other RBAC object in the chart already uses).
e.g. {{ include "kmcp.fullname" . }}-metrics-auth-role / -metrics-reader / -metrics-auth-rolebinding, and update the binding's roleRef.name to match. The binding's subject already points at the per-namespace ServiceAccount, so no authz behavior changes and each instance simply owns a uniquely named copy, eliminating the cross-release ownership collision. That lets metrics stay enabled on every instance with no new values or flags; it falls out automatically once the names are release-scoped like the rest of the chart.
🔄 Alternatives Considered
No response
🎯 Affected Service(s)
No response
📚 Additional Context
No response
🙋 Are you willing to contribute?
📋 Prerequisites
📝 Feature Summary
Support for multiple kagent instances in 1 cluster for staging purposes
❓ Problem Statement / Motivation
Description
Kagent has the potential to be run as multiple instances simulatenously in one cluster for staging new releases before fully upgrading. This can be accomplished through settings specific override values for rbac permissions in the kagent helm install. However, when doing this kcmp metrics can only be enabled on one instance
Requirements
Assessment
It appears the
kagentchart already supports namespace-isolated installs: settingrbac.namespacesandkmcp.rbac.namespacesto the install namespace makes the kagent controller possible to run as multiple instances on one cluster. The remaining blocker comes from the bundled kmcp subchart, whose metrics authz RBAC is emitted with fixed cluster-scoped names, so a second instance collides on them.This means multi-instance for staging works today only with kmcp metrics disabled (or enabled on a single instance). Once the kmcp chart scopes those names per release/namespace, the kagent chart should expose/propagate that so
kmcp.rbac.namespaces(or the kagent namespace-isolation switch) fully isolates kmcp too with no per-instance metrics trade-off.💡 Proposed Solution
These three objects genuinely need cluster-scoped APIs (tokenreviews/subjectaccessreviews and the /metrics nonResourceURL), so they can't collapse into namespaced Roles but they don't need fixed names. The fix is to template their names through the chart's existing fullname/release helper (the same one every other RBAC object in the chart already uses).
e.g. {{ include "kmcp.fullname" . }}-metrics-auth-role / -metrics-reader / -metrics-auth-rolebinding, and update the binding's roleRef.name to match. The binding's subject already points at the per-namespace ServiceAccount, so no authz behavior changes and each instance simply owns a uniquely named copy, eliminating the cross-release ownership collision. That lets metrics stay enabled on every instance with no new values or flags; it falls out automatically once the names are release-scoped like the rest of the chart.
🔄 Alternatives Considered
No response
🎯 Affected Service(s)
No response
📚 Additional Context
No response
🙋 Are you willing to contribute?