fix: return success on DEL when CNI cache is missing

[kvaps]

Summary

• When CNI ADD never completes (e.g. sandbox creation fails), no cache file is written
• On cleanup, CmdDel reconstructs delegate configs from the API and calls DEL on each plugin
• Delegate plugins fail because they require runtime state from a successful ADD
• This creates a deadlock: containerd cannot release sandbox name reservations
• Fix: return success immediately when cache file does not exist (ADD never completed)

Problem

After a node disruption, containerd accumulates stale sandbox name reservations. When it tries
to clean them up, CNI DEL is called through multus. Without a cache file, multus reconstructs
the config from the Kubernetes API, but delegate plugins (e.g. kube-ovn) reject the config
because it lacks runtime state (socket paths, cached results) that only exists after ADD.

This causes:

1. Sandbox name reservations persist indefinitely
2. New pods cannot be created on the affected node
3. DEL retry storm overloads multus, causing ADD timeouts for new pods

Fix

If the cache file does not exist (os.IsNotExist), return nil immediately since there is
nothing to clean up. This matches the existing graceful fallback when both cache and pod are
missing (the else branch at the former line 978).

Related issues

• one pod failed #1454
• Multus: failed to get the cached delegates file #1446
• Fix Plan: failed to recover state: failed to reserve container name xxx: name xxx is reserved for xxx containerd/containerd#11504

Test plan

• Verify existing unit tests pass
• Manual test: create a pod sandbox failure scenario, verify DEL returns success without cache

[gemini-code-assist]

Code Review

This pull request simplifies the CmdDel logic in pkg/multus/multus.go by skipping the deletion process when a cache file is missing, which indicates that the ADD operation was never completed. This change prevents failures during sandbox cleanup by avoiding attempts to reconstruct configurations from the API without necessary runtime state. Feedback was provided to enhance the observability of error logs by including the container ID and to clarify log messages when cache parsing fails. Additionally, a refactor was suggested to combine redundant return paths for better readability.

[gemini-code-assist]

The error logging and logic in this block can be improved for better observability and clarity:

1. Context: The log message at line 968 loses the pod/container context. Including args.ContainerID (as done in the Verbosef call at line 963) would significantly help in identifying which container failed cleanup in the logs.
2. Clarity: If err is nil (which occurs if the cache file was read successfully but failed to unmarshal at line 941), the log will show : <nil>, which is misleading. It should ideally distinguish between a filesystem error and a parsing failure.
3. Simplification: Since both branches return nil, the logic can be combined to reduce redundancy and improve readability.

Suggested change

	if os.IsNotExist(err) {
	logging.Verbosef("Multus: no cache found for container %s (ADD was never completed), skip DEL", args.ContainerID)
	return nil
	}
	// The options to continue with a delete have been exhausted
	// We cannot exit with an error as this may cause a sandbox to never get deleted.
	logging.Errorf("Multus: failed to get the cached delegates file: %v, cannot properly delete", err)
	return nil
	if os.IsNotExist(err) {
	logging.Verbosef("Multus: no cache found for container %s (ADD was never completed), skip DEL", args.ContainerID)
	} else {
	// The options to continue with a delete have been exhausted
	// We cannot exit with an error as this may cause a sandbox to never get deleted.
	logging.Errorf("Multus: failed to get or parse the cached delegates file for container %s: %v, cannot properly delete", args.ContainerID, err)
	}
	return nil

[mattia-eleuteri]

We had the same issue specified here
and I can confirm that the fix proposed in this MR resolved our issue.