Change:
var IP string // TODO: Remove this when sandbox is available on windows <del> // Currently windows supports both sandbox and non-sandbox cases. </del> // This is a workaround for windows, where sandbox is not in use, and pod IP is determined through containers belonging to the Pod. <del> if IP = ds.determinePodIPBySandboxID(podSandboxID, r); IP == "" { </del> <ins> if IP = ds.determinePodIPBySandboxID(podSandboxID); IP == "" { </ins> IP = ds.getIP(podSandboxID, r) }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: PR tries to reduce CNI calls for sandboxed containers: case is for Windows Server 2016 and for Windows Server version greater than 1709 which use Hyper-V containers. Currently, the CNI on Windows fetches the IP from the containers within the pods regardless of the mode. This should be done only in the non-sandbox mode where the IP of the actual container will be different than the IP of the sandbox container. from the same pod will share the network details of the sandbox container. when this mode is supported. However, for Windows 1709 and 1803 we didnt have the Namespace support in Windows which we are bringing in RS5. So we need this second call to replicate the DNS registry key to the Workload container. This is a platform requirement and removing this will break DNS for the workload containers. IP/Gateway/MAC is set separately than DNS. (Refer ) In Rs5 once we move the namespace model, we will update CRI and CNI to add endpoints and add it to the namespace. So the PR breaks dns for windows containers. We should revert it. /sig windows /kind bug
Since is headed for 1.11, this issue should be similarly milestone 1.11 labeled and approved. /milestone v1.11 /status approved-for-milestone
You must be a member of the github team to set the milestone. <detailsIn response to : Since is headed for 1.11, this issue should be similarly milestone 1.11 labeled and approved. /status approved-for-milestone Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
You must be a member of the github team to add status labels.
/milestone v1.11 /status approved-for-milestone
if you can drop an update here on status of the PR revert of PR , and if there's anything additional that might be happening like a re-fix of what was being attempted in the earlier PR, the 1.11 release team would appreciate the additional context.

PR has been reviewed by but still waiting for sig-node's approval
/priority critical-urgent /status in-progress
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details