我经常发现自己尝试启动一个新的 Pod，但却收到一条错误消息，提示没有可用的节点。例如：
0/9 nodes are available: 1 node(s) had no available volume zone, 8 node(s) didn't match node selector.
每次收到这些消息时我都会感到很困惑。我该如何调试呢？
答案1
一开始我的建议是看看Kubernetes 调度器组件：
主服务器上的组件，监视未分配节点的新创建的 pod，并选择一个节点供它们运行。[-] 调度决策考虑的因素包括单独和集体的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据局部性、工作负载间干扰和截止日期。
调度程序会监视未分配节点的新创建的 Pod。对于调度程序发现的每个 Pod，调度程序都会负责为该 Pod 找到最佳运行节点。对于每个新创建的 Pod 或其他未调度的 Pod，kube-scheduler 都会为它们选择一个最佳运行节点。但是，Pod 中的每个容器对资源的要求不同，每个 Pod 的要求也不同。因此，需要根据特定的调度要求筛选现有节点。
根据文件：
在集群中，满足 Pod 调度要求的节点称为可行节点。如果没有合适的节点，则 Pod 将保持未调度状态，直到调度程序能够将其放置。
kube-scheduler 通过两步操作为 pod 选择节点。标准 kube-scheduler 基于默认策略：
- 过滤
- 评分
通过研究这两项政策，你可以找到更多关于决策制定的信息。例如：
for scoring at the stage CalculateAntiAffinityPriorityMap This policy helps implement pod anti-affinity.
您可以在下面找到基于影响力的快速评论Kubernetes 调度器决策
- 节点名称：通过将节点的主机名添加到 Pod 定义的 .spec.nodeName 参数，可以强制此 Pod 在该特定节点上运行。调度程序使用的任何选择算法都将被忽略。此方法是最不推荐的。
- 节点选择器：通过在节点上放置有意义的标签，Pod 可以使用 nodeSelector 参数指定一个或多个键值标签映射，这些映射必须存在于目标节点上才能被选中运行该 Pod。这种方法更值得推荐，因为它增加了很大的灵活性并建立了松散耦合的节点-Pod 关系。
- 节点亲和性：此方法在选择应考虑哪个节点来调度特定 Pod 时增加了更多灵活性。使用节点亲和性，Pod 可能严格要求在具有特定标签的节点上进行调度。它还可以通过影响调度程序赋予它们更多权重来表达对特定节点的某种程度的偏好。
- Pod 亲和性反亲和性：当 Pod 与同一节点上的其他 Pod 共存（或非共存）至关重要时，您可以使用此方法。Pod 亲和性允许 Pod 要求将其部署在具有特定标签的 Pod 的节点上。同样，Pod 可能会强制调度程序不将其放置在具有特定标签的 Pod 的节点上。
- 污点和容忍度：在此方法中，您不是决定将 Pod 调度到哪些节点，而是决定哪些节点不应接受任何 Pod 或仅应接受选定的 Pod。通过污染节点，您可以指示调度程序不要考虑将此节点用于任何 Pod 放置，除非 Pod 容忍污染。容忍度由键、值和污染的影响组成。使用运算符，您可以决定整个污染是否必须与容忍度匹配才能成功放置 Pod，或者只有一部分数据必须匹配。
按照k8s 文档：
1。节点名称是节点选择约束的最简单形式，但由于其局限性，通常不使用它。使用 nodeName 选择节点的一些限制是：
- 如果命名的节点不存在，则 pod 将不会运行，并且在某些情况下可能会被自动删除。
- 如果命名节点没有资源来容纳 pod，pod 将失败，其原因将表明原因，例如 OutOfmemory 或 OutOfcpu。云环境中的节点名称并不总是可预测或稳定的。
2。 这亲和性/反亲和性功能极大地扩展了您可以表达的约束类型。关键增强功能包括：- 语言更具表现力（不仅仅是“完全匹配的 AND”）- 您可以指示规则是“软”/“偏好”而不是硬性要求，因此如果调度程序无法满足它，pod 仍将被调度- 您可以限制在节点（或其他拓扑域）上运行的其他 pod 上的标签，而不是节点本身上的标签，这允许关于哪些 pod 可以和不能共置的规则
亲和力特征包含两种类型的亲和力，节点亲和性和pod 间亲和性/反亲和性. 节点亲和性类似于现有的 nodeSelector（但具有上面列出的前两个优点），
目前有两种类型的 pod 亲和性和反亲和性，称为调度期间必需执行期间忽略和调度期间优先，执行期间忽略表示“硬性”要求与“软性”要求。
希望这有帮助。
其他资源：