Change:
continue } <del> if containerIP := ds.getIP(c.ID, r); containerIP != "" { return containerIP </del> <ins> // Versions and feature support // ============================ // Windows version == Windows Server, Version 1709,, Supports both sandbox and non-sandbox case // Windows version == Windows Server 2016   Support only non-sandbox case // Windows version < Windows Server 2016 is Not Supported // Sandbox support in Windows mandates CNI Plugin. // Presence of CONTAINER_NETWORK flag is considered as non-Sandbox cases here // Todo: Add a kernel version check for more validation if networkMode := os.Getenv("CONTAINER_NETWORK"); networkMode == "" { // On Windows, every container that is created in a Sandbox, needs to invoke CNI plugin again for adding the Network, // with the shared container name as NetNS info, // This is passed down to the platform to replicate some necessary information to the new container // // This place is chosen as a hack for now, since ds.getIP would end up calling CNI's addToNetwork // That is why addToNetwork is required to be idempotent // Instead of relying on this call, an explicit call to addToNetwork should be // done immediately after ContainerCreation, in case of Windows only. TBD Issue # to handle this if r.HostConfig.Isolation == kubeletapis.HypervIsolationValue { // Hyper-V only supports one container per Pod yet and the container will have a different // IP address from sandbox. Return the first non-sandbox container IP as POD IP. // TODO(feiskyer): remove this workaround after Hyper-V supports multiple containers per Pod. if containerIP := ds.getIP(c.ID, r); containerIP != "" { return containerIP } } else { // Do not return any IP, so that we would continue and get the IP of the Sandbox. // Windows 1709 and 1803 doesn't have the Namespace support, so getIP() is called // to replicate the DNS registry key to the Workload container (IP/Gateway/MAC is // set separately than DNS). // TODO(feiskyer): remove this workaround after Namespace is supported in Windows RS5. ds.getIP(sandboxID, r) } } else { // ds.getIP will call the CNI plugin to fetch the IP if containerIP := ds.getIP(c.ID, r); containerIP != "" { return containerIP } </ins> } }

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