Change:
} // PodSandboxNetworkStatus is the status of the network for a PodSandbox. <ins> // Currently ignored for pods sharing the host networking namespace. </ins> type PodSandboxNetworkStatus struct { // IP address of the PodSandbox. Ip string `protobuf:"bytes,1,opt,name=ip,proto3" json:"ip,omitempty"`

Discussion:
What happened: We have installed k8s cluster on openstack cloud provider setup. K8s cluster is dual-stack enabled. During fresh deployment or worker node reboots (master nodes , worker nodes) , k8s control plane pods (other host networking pods aswell) such as kube-proxy, kube-scheduler , kube-controller-manager get only 1 IP address instead of dual-stack address. What you expected to happen: We expect all host networking pods to get dual-stack addresses , since cluster is dual-stack enabled. How to reproduce it (as minimally and precisely as possible): a) Openstack cloud provider setup with minimum 4-5 VMs. b) 3 master nodes, 2 worker nodes c) Execute simultaneous reboot of all nodes. Environment: Kubernetes version : v1.22.0
/sig node
/sig network /triage needs-information /assign Hi When you describe your node what are the IPs assigned in node object? kubelet copies from node object into pods. The way they are set on node object is by the cloud provider, manual via kubelet's flag or auto-detect which prefers IPv4 (check: ).
when i describe the node object , they contain dual-stack addresses. Yes i debugged kubelet with few additional logs. I could see that when kubelet is reading node obj to create these static pods, it sees only 1 IP. But eventually node object is populated with both the addresses. I also understand, is for baremetal installation. But we have cloud provider setup which might be delaying setting both the IPs in node obj. Before cloud provider sets both the IPs ,kubelet is fast enough to create these static pods. Let me know if you need any additional logs.
thanks again Few additional questions: are these static pods? When the node object gets its dualstack addresses and pods were created after the node object updates do you still get single address pods?
I've chatted with the reporter in slack, it seems a race on populating the node addresses by the cloud-provider,
Yes. It would seem so. Two things here i am trying to clarify. cloud providers node register with taints (no schedule) until cloud provider adds provider-Id and other details including IPs.

these are static pods then I am not sure if kubelet respects no-schedule (those are respected by scheduler which is out of the picture for static pods) If they are then they will run - most likely - before node gets IP addresses from cloud provider. The questions i asked above should put some lights on this.
Yes i am referring to kube-proxy , kube-api-server ,kube-scheduler pods which use host-networking. This is not under our control. I mean , we are just rebooting the nodes in quick succession and at the end we just check the IP addresses of the above static pods. As i see the code , kubelet brings them up as soon as he is UP.
IMO the cloud provider really needs to figure out the IPs before kubelet starts. OR the node startup needs to block until both IP addresses are available so that the cloud provider and/or kubelet can read them.
Should we accept this as a bug? Do we think we need to force some taint on new nodes that cloud-providers need to clear (obviously not compatible, but you get the idea)?
-- There is a no-schedule taint already there (if cloud provider is configured on kubelet). It is a bug (or undocumented behavior). I think we should always update PodIPs in host network mode. /triage accepted
xref
so i looked at this again. I believe should fix this issue as well. i don't think we should place this behind a feature gate. We already update when the host IP changes. We just need to edit the release note of to describe the behavior and caveats. Thoughts?
Please ignore that comment. The PR does not solve for
/remove-sig node
: Any more info needed from me ?
no thank you. We are addressing this by and the related KEP.
, any idea when will the fix be available ?