docs: fix the router ConfigMap example key and nesting

[aeron-gh]

/kind documentation

What this PR does / why we need it:

The first ConfigMap example in the router configuration guide could not work as written. Three separate defects, all in the same block:

1. The data key was schedulerConfiguration, which no code path reads. The deployment subPath-mounts routerConfiguration to the fixed path the router loads, so the example's config was never seen.
2. The fields sat at top level, but the parser unmarshals into RouterConfiguration, which expects them under scheduler:. They were dropped as unknown fields.
3. It set namespace: default, while the chart creates the router's ConfigMap in the release namespace (documented install: kthena-system), so applying it produced an unrelated ConfigMap the router never mounts.

Mechanism and file references in #1599.

Running the example through the router's own ParseRouterConfig plus LoadSchedulerConfig shows what the first two cost:

• before: pluginConfigs=0 scoreWeights=map[] filters=[], an entirely empty scheduler config
• after: pluginConfigs=4 scoreWeights=map[kvcache-aware:1 least-latency:1 least-request:1 prefix-cache:1] filters=[least-request]

The example now uses the routerConfiguration key with the scheduler: nesting, and namespace: <namespace>, matching both the authentication example further down this page and the other router-ConfigMap examples in the repo (kvcache-aware.md, examples/redis/README.md).

Scope: all five published doc versions carry this example (versions.json lists v1.0.0 through v0.1.0), and every release tag from v0.1.0 to v1.0.0 subPath-mounts routerConfiguration and loads /etc/config/routerConfiguration.yaml, so it was never correct for any of them. Each versioned copy is fixed in place, keeping its own plugin set and names (the v0.x copies keep kv-cache); only the data key, the nesting, and the namespace change. The four v0.x copies additionally had the ConfigMap header pasted twice inside the same snippet, which is removed. Each result was verified by parsing it back through the router's config loader.

Which issue(s) this PR fixes:
Fixes #1599

Does this PR introduce a user-facing change?:

NONE

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[aeron-gh]

@acsoto @kube-gopher
PTAL

[kube-gopher]

/lgtm
/approve

[volcano-sh-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kube-gopher
Once this PR has been reviewed and has the lgtm label, please assign lizhencheng9527 for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• docs/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[aeron-gh]

@LiZhenCheng9527 this one has lgtm and kube-gopher's approval, just needs a docs/OWNERS approve when you get a minute. thanks!