Change:
// Generate final API pod status with pod and status manager status apiPodStatus := kl.generateAPIPodStatus(pod, podStatus) <ins> // The pod IP may be changed in generateAPIPodStatus if the pod is using host network. (See #24576) // TODO(random-liu): After writing pod spec into container labels, check whether pod is using host network, and // set pod IP to hostIP directly in runtime.GetPodStatus podStatus.IP = apiPodStatus.PodIP </ins> // Record the time it takes for the pod to become running. existingStatus, ok := kl.statusManager.GetPodStatus(pod.UID)

Discussion:
Turns our that when running a container in host network, its that is passed to dockertools.SyncPod() will always contain empty IP, as a result, the environment becomes empty. Maybe we want to use the instead of in this case to ? Since the apiPodStatus has the valid PodIP, which is when the container runs in host network. Or just populate the podIP with hostIP in when the container runs on host network. Ref cc
Why not just set the same with before ? Ideally, we want to remove from SyncPod() in the future if possible, it may be better to get it from . WDYT?
Do you mean "set the podStatus.IP to apiPodStatus.IP before SyncPod?" IMO, we should call only once. Why don't we populate set the before calling ?
We also use . However, because we don't support host network bandwidth limit, it is fine to leave the IP unset here. However, I think it would be good to have IP always correctly set in .
I must admit, I have been thinking about this in the background since created this issue, and the discussion hasn't up for me. I finally sat down and spent some time getting my numerous fixes for podIP via downward API back into my brain, and now the problem seems very obvious to me. So, after some thought, I believe that for the docker runtime, the problem is that , which is responsible for generating the which is used to supply the pod IP, doesn't check to see whether the host network is being used and return the correct IP address if so. However, does, which is why the obvious fix seems to be to use the value from this method. I think the right thing to do instead is to change the following call stack to correctly determine the IP when the host network is being used.
Today doesn't pass the pod spec, so it cannot know if the pod is running on host. This could be solved if we serialize the pod spec into docker labels. BTW, I think we have a similar issue here for rkt.
As said, GetPodStatus doesn't have full pod spec today. And I don't think docker manager has knowledge about the host ip now.
I think we should think about adding the plbuming.

I have not had a good experience storingthis information in multiple places :)
The code was written so that it'd work in the absence of the pod specs (which we don't always have). I agree with you, but adding the dependency today without some form of checkpointing (e.g., container annotations) of the pod specs may be problematic now. We can revisit this after we store pod specs in the annotations. What do you think? :)
I'm cool with revisiting but if we do that we should drop this to p2
Reopen the issue to capture
Is this fixed?
hi, also interested in knowing if this is fixed.
I don't think anyone is tacking on this one right now since people are mostly working on the new CRI implementation for different runtimes. cc
thanks. it also looks like there might be a specific issue with rkt here. Looking at and , it looks like rkt does not handle the case of status.PodIP when using the host network.
Thanks for the heads up. I will take a look to see if we can quickly work around this.
Issues go stale after 30d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close