背景：
在对应用程序进行性能测试时，我在扩展php-fpm容器的副本时得到了不一致的结果，我意识到在同一节点上安排了 3/4 个 Pod。
然后，我将反关联性规则配置为不在同一节点上调度 Pod。我很快意识到使用requiredDuringSchedulingIgnoredDuringExecution不是一种选择，因为我不能有 # 个副本> # 个节点，所以我配置了preferredDuringSchedulingIgnoredDuringExecution.
在大多数情况下，看起来我的 pod 在我的所有节点上均匀调度，但有时(通过滚动升级看到(，我在同一节点上看到 pod。我觉得目前设置为 100 的weight值正在发挥作用。
这是我正在使用的yaml(头盔(：
{{- if .Values.podAntiAffinity }}
{{- if .Values.podAntiAffinity.enabled }}
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
app: "{{ .Values.deploymentName }}"
topologyKey: "kubernetes.io/hostname"
{{- end }}
{{- end }}
问题：
我阅读文档的方式，weight数字将根据节点的繁忙程度(简化(添加到节点的计算分数中，但我不明白的是 1 与 100 的权重会有什么不同？
为什么 Pod 有时会使用此规则调度在同一节点上？是因为未调度 Pod 的节点的总分太低(因为它太忙(吗？
有没有办法查看 Pod 如何在特定节点上调度的日志/事件？我希望kubectl describe pod有这些细节，但似乎没有(除非在错误情况下(。
首选杜林调度被忽略不保证执行。
两种类型的节点亲和性，称为必需杜灵调度忽略了杜ring执行和首选杜林调度忽略了杜林执行。你可以将它们分别视为"硬"和"软"，从某种意义上说，前者指定了将 pod 调度到节点上必须满足的规则(就像 nodeSelector 一样，但使用更具表现力的语法(，而后者指定调度程序将尝试强制执行但不保证的首选项。
您设置的权重提供了优势，但还有其他参数(由用户和 kubernetes 设置(具有自己的权重。下面的示例应该可以更好地说明您设置的权重很重要的地方
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions:
- key: example.com/myLabel
operator: In
values:
- a
weight: 40
- preference:
matchExpressions:
- key: example.com/myLabel
operator: In
values:
- b
weight: 35