fix: update network error msg to match kubelet expectations

[isaac-dasan]

Signed-off-by: GitHub noreply@github.com

Reason for Change:
This is a perf fix. The particular error message is retries with faster backOffInterval than default error messages by the kubelet.

Issue Fixed:

Requirements:

• uses [conventional commit messages]
• includes documentation
• adds unit tests
• relevant PR labels added

Notes:

[Copilot]

Pull Request Overview

This PR aligns the mtpnc is not ready error message with the kubelet’s expected “network is not ready” string and adds a comment explaining the rationale.

• Changed errMTPNCNotReady message to include “network is not ready” prefix
• Added comment referencing kubelet retry logic
• Existing unit tests and documentation adapters are included

Comments suppressed due to low confidence (3)

cns/middlewares/k8sSwiftV2.go:20

• Referencing a specific commit hash can become outdated. Consider linking to stable Kubernetes documentation or describing the relevant code path more generally to improve long-term maintainability.

// In AKS, for kubelet to retry faster it is particularly looking for "network is not ready" error string. 

cns/middlewares/k8sSwiftV2.go:22

• [nitpick] Consider renaming this error variable to errNetworkNotReady or similar to reflect the updated message and improve consistency between the variable name and its content.

errMTPNCNotReady = errors.New("network is not ready - mtpnc is not ready") 

cns/middlewares/k8sSwiftV2.go:22

• [nitpick] Ensure that the kubelet recognizes the exact prefix it expects (e.g., "network is not ready"). If only that substring matters for retry behavior, you may simplify the error string to avoid potential mismatches.

errMTPNCNotReady = errors.New("network is not ready - mtpnc is not ready") 

[QxBytes]

it looks like from upstream code this will reduce the retry interval from ~10 seconds to ~1 second-- wondering if there are concerns if the cns never comes up or if this fast retry will exhaust resources (ex: x10 more fail logs if cns never comes up)? Was there a particular incident or reasoning for needing the 10 sec improvement?

[isaac-dasan]

it looks like from upstream code this will reduce the retry interval from ~10 seconds to ~1 second-- wondering if there are concerns if the cns never comes up or if this fast retry will exhaust resources (ex: x10 more fail logs if cns never comes up)? Was there a particular incident or reasoning for needing the 10 sec improvement?

To clarify this doesn't happen when "CNS doesn't come up" instead this error message is thrown when MTPNC is not found by CNS. Yes this will make 10x more error logs in CNS and CNI, but this is the only way to address perf bottle neck related to swiftv2 podStartupLatency. It is not acceptable for customers to be waiting for a pod for > 30 secs , but today we are at > 50 secs. This fix will shave off 10 to 15 secs and we must take it.

This is in swiftv2 multitenant code path only which is exceedingly small number of clusters in AKS today, so not all CNI error logs will be noisy.

[isaac-dasan]

/azp run Azure Container Networking PR

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[sheylatrudo]

LGTM