I don't see a proof that this is an apiserver fault. Actually in your linked search I see legitimate case of that error message Uninstall operator: delete customresourcedefinition "" Many others are leader-election which suggests that leader election has a bug.
*** Bug 1959927 has been marked as a duplicate of this bug. ***
Tomofumi, Check v4.8 in https://search.ci.openshift.org/?search=resource+name+may+not+be+empty&maxAge=48h&context=1&type=bug%2Bjunit&name=4.8&excludeName=&maxMatches=5&maxBytes=20971520&groupBy=job QE does not see the message about "status update failed for pod /: resource name may not be empty" in the past two days, but still see the tons of message about "resource name may not be empty". Should QE verify this bug?
"resource name may not be empty" error message is pretty common because it is client-go message. This bz only mentioned error message that is: - Multus generates the this error message - "pod /" is contained (this means pod/podnamespace is empty, pretty weird) Looking the error message in CI, we don't see any logs that met above condition, so I suppose we verify the bug.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:2438