Change:
Playing around with kind, I noticed the following somewhat unexpected behavior: Using this deployment on a 3-node kind cluster, all two pods get scheduled onto kind-worker node. Now suppose I drain that node by running . The node gets cordon'ed (no more pods can be assigned to it) and then all pods are evicted. All pods are rescheduled to the same node due to the presence of field, but that node has just been marked as unschedulable. It is clear there is a conflict here, and feature takes precedence, so I assume this behavior is expected. Thus, the section could be updated to reflect it is not safe to turn off the node since there are pods running on it. Quoting the doc:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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
if you set the field on the node you are on purpose forcing that pod to the node and skipping the You are reasoning is correct but does it make sense to highlight every corner case? anyway, you can always submit a PR to the docs with your suggestions /sig docs /sig scheduling
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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

Discussion:
if len(serverList) == 0 { return nil, ErrNotFound <del> } else if len(serverList) > 1 { return nil, ErrMultipleResults </del> } return &serverList[0], nil