Change:
expected: true, }, { <ins> name:     "QOSClass set as BestEffort. single-numa-node Policy. No Hints.", qosClass: v1.PodQOSBestEffort, policy:   NewRestrictedPolicy(), hp: []HintProvider{ &mockHintProvider{}, }, expected: true, }, { name:     "QOSClass set as BestEffort. Restricted Policy. No Hints.", qosClass: v1.PodQOSBestEffort, policy:   NewRestrictedPolicy(), hp: []HintProvider{ &mockHintProvider{}, }, expected: true, }, { </ins> name:     "QOSClass set as Guaranteed. BestEffort Policy. Preferred Affinity.", qosClass: v1.PodQOSGuaranteed, policy:   NewBestEffortPolicy(),

Discussion:
What happened: With the latest , which aims to resolve the issue of deploying pods with single-numa-node policy, it seems to have resulted in failure to deploy pods if the pod spec does not have resources and limits constraints. This is resulting in Kube-dns and other pods which do not have resource constraints mentioned fail to deploy due to Topology Affinity Error. kube-system kube-dns--22dks 0/3 Topology Affinity Error 0 What you expected to happen: Ideally, if there are no resource constraints mentioned we will still need the pod to be deployed. We cannot have Kube-dns failing to deploy due to Topology Affinity issue. How to reproduce it (as minimally and precisely as possible): With the latest fix, enabling single-numa-node policy, Kube-dns errors out on the node. One can just try to deploy simple pod without resource constraints in pod spec. Anything else we need to know?: This happens only when policy is single-numa-node. Pods do not fail to deploy for best-case policy. Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-10-02T17:01:15Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.0-alpha.1.338+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2019-10-11T10:39:19Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Baremetal x86 server with 2 NUMA nodes and 32 cpus. OS (e.g: ): Fedora 28 Kernel (e.g. ): 5.0.13-100.fc28.x86_64
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
/cc
/assign
thanks for alerting us to the issue.

Can you try the PR linked?
My guess is that this issue was introduced after landed. Before that, best-effort pods weren't even being considered by the TopologyManager, and the logic for admitting vs. not admitting was skipped. Which means that we need this fix for this on master, but do not need it on the 1.16 branch.
can you verify if it works as expected in the release-1.16 branch. This would verify my claim that it broke with the introduction of not the fix from . The patch for landed just a few hours after , so I could see how its hard to know which one caused the new issue.
PTAL
, That's right. This fix is needed for the master branch and not 1.16. 1.16 works well without .
/cc for visibility. This issue appeared as a result of
Thanks for the ping. So is the proposed fix to always admit best-effort pods in the topology manager?
This only affects the single-numa-node policy because of the "hack" we currently have in place for it: The right long term fix is to address this as part of: However, if we want to put a short term fix in place to "unbreak" master, has a PR linked above that will fix the immediate problem.