Cache https.Agent and Dispatcher per cluster/user pair to fix FD leaks on Watch reconnection

[Copilot]

KubeConfig.createAgent() and createDispatcher() unconditionally construct a new instance on every call. With Watch's reconnect pattern, this leaks a new socket pool each cycle — orphaned agents are not promptly GC'd due to reference chains through node-fetch response body streams, causing steady FD growth and eventual EMFILE.

Changes

src/config.ts

• Add agentCache: Map<string, Agent> and dispatcherCache: Map<string, Dispatcher | undefined> to KubeConfig, keyed by "clusterName::userName" (the tuple that uniquely determines TLS config and auth)
• createAgent() and createDispatcher() now return a cached instance on subsequent calls for the same cluster/user pair, constructing only on first use
• Add private getAgentCacheKey(cluster) helper

src/config_test.ts

• 4 new tests: same-instance reuse for both agent and dispatcher, distinct instances across different cluster/user contexts

Behavior

const watch = new k8s.Watch(kc);

// Before: new https.Agent created on every reconnection → FD growth
// After:  same https.Agent reused for the same cluster/user → stable FD count
async function startWatch() {
  await watch.watch('/apis/...', {}, (type, obj) => {}, (err) => {
    setTimeout(startWatch, 1000); // reconnect — agent is now reused
  });
}

The cache is keyed by cluster+user names rather than a single global entry, so multi-cluster configs that switch context get the correct per-endpoint agent.

[linux-foundation-easycla]

• ❌ - login: @Copilot / name: copilot-swe-agent[bot]. The commit (0da2d81, 2e12737, 39e1aa4, fdc7763) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please visit our EasyCLA portal and chat with our support bot.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Copilot
Once this PR has been reviewed and has the lgtm label, please ask for approval from brendandburns. For more information see the 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:

• OWNERS

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

[brendandburns]

I'm worried that using string concatenation to build the hash key may lead to unexpected (and hard to debug) conflicts, is there a better hashing function you can think of?

[brendandburns]

@copilot I'm worried that using string concatenation to build the hash key may lead to unexpected (and hard to debug) conflicts, is there a better hashing function you can think of?

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Copilot
Once this PR has been reviewed and has the lgtm label, please ask for approval from brendandburns. For more information see the 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:

• OWNERS

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

[Copilot]

@copilot I'm worried that using string concatenation to build the hash key may lead to unexpected (and hard to debug) conflicts, is there a better hashing function you can think of?

Good catch. Switched to JSON.stringify([clusterName, userName]) in commit 2e12737. This encodes the two-element array as a JSON string, so names containing :: (or any other delimiter) can never produce the same key as a different pair — e.g. ["a::b","c"] vs ["a","b::c"] are always distinct.