feat: introduce Feature Gates

[difrost]

What

This PR introduces a generic feature gate framework (pkg/features/) based on k8s.io/component-base/featuregate.
Feature gates allow controlling feature availability based on maturity level (Alpha, Beta, GA, Deprecated) and can be configured via:

• CLI flag: --feature-gates Feature1=true,Feature2=false
• TOML config: [feature_gates] section (supports SIGHUP reload)

Why

I'm working on enabling Kubernetes MCP in a large environment with many, big clusters. The scale of operations (and the nature of my environment) requires variety of features that we want to introduce gradually. Feature gating will help in managing a lifecycle of features. Some strong candidates from existing codebase:

1. StructuredContent

Maturity: Alpha (default: off)

Description: The StructuredContent field on ToolCallResult provides richer MCP UI rendering by including a JSON-serializable structured payload alongside the text Content. This is a newer MCP spec addition and not all clients support it yet.

Current state: Unconditionally included in tool call results when set by a tool handler. Defined in pkg/api/toolsets.go (ToolCallResult.StructuredContent) and serialized in pkg/mcp/tools_gosdk.go.

Risk: Low. Tools already produce a text Content fallback per MCP spec, so disabling structured content is a graceful degradation.

2. Elicitation

Maturity: Alpha (default: off)

Description: Elicitation enables interactive user confirmation prompts via the MCP protocol. The server can ask the user to confirm or deny an action before proceeding. This depends on MCP client support and already has fallback logic for clients that don't implement it (ErrElicitationNotSupported).

Current state: Wired in pkg/mcp/elicit.go (sessionElicitor), used by pkg/kubernetes/confirmation_validator.go for kube-level confirmation rules, and by pkg/confirmation/ for tool-level rules. Clients that don't support elicitation get an error that is handled gracefully.

Risk: Low. The fallback path already exists for clients without elicitation support.

Among the new features that could be gated behind feature gates is #711 that I would like to work on.

How

• Separate pkg/features/ package — mirrors the Kubernetes convention (k8s.io/apiserver/pkg/util/feature, k8s.io/kubernetes/pkg/features). Keeps the gate instance and feature definitions together, avoids import cycles.
• TOML [feature_gates] table — uses map[string]bool which naturally maps to a TOML table. Follows the existing StaticConfig pattern. Applied via SetFromMap which is the canonical featuregate API.
• Config reload support — SIGHUP reload re-applies the feature_gates map from the new config. Since SetFromMap replaces the full state atomically, features removed from config revert to their defaults.
• CLI overrides config — the --feature-gates flag is applied in loadFlags after config file loading, matching the existing pattern where CLI flags take precedence.
• No existing features gated yet — the framework is introduced with an example/placeholder. Actual features can be gated as needed in subsequent PRs.

[Cali0707]

@difrost it's not clear to me what the advantage of the feature gates over just the normal configuration (which enables/disabled features already) is?

[manusa]

it's not clear to me what the advantage of the feature gates over just the normal configuration (which enables/disabled features already) is?

agreed, this seems to provide abstractions over something that's already covered.
For most cases, feature flags/gates are already provided by configurations themselves.

• Opt-in features or preview features are usually gated on their config or a config switch.
• When the feature matures or is stable, we usually flip its default value(s) in the config. This also provides flexibility for those features that are available downstream|upstream only

[difrost]

IMHO Feature Gates are far more clear abstraction for feature availability widely adapted by K8s ecosystem. I agree that one can build config based solution to that and I'm ok with dropping this out - I'll let @manusa decide.

[manusa]

I'd prefer to close this for now because there's still nothing to take advantage of this and we already have the functionality covered (YAGNI).
If in the future a more advanced feature flag enhancement is needed we can pick it up from this PR.