Kubernetes调度深度解析：节点与Pod亲和性策略

"本资源详细介绍了Kubernetes调度器中的调度亲和性，包括节点亲和性和Pod亲和性，以及不同类型的策略，如硬策略和软策略。文档中通过具体的Pod配置示例展示了如何设置这些亲和性规则。" 在Kubernetes集群中，调度器是负责将Pod分配到合适的Node上的核心组件。调度亲和性是调度器在分配Pod时考虑的一种策略，用于确保Pod被部署到具有特定属性或条件的Node上。这有助于优化集群资源的使用，提高服务的可用性和性能。 1. 节点亲和性(node affinity)： 节点亲和性允许我们定义Pod应该或者不应该运行在哪些Node上。它分为两种类型： - `requiredDuringSchedulingIgnoredDuringExecution`（硬策略）：这是强制性的，调度器必须找到满足这些规则的Node，否则Pod将不会被调度。例如，示例中配置了 `-key:kubernetes.io/hostname -operator:NotIn -values: [k8s-node02]`，表示Pod不能被调度到k8s-node02这个Node上。 - `preferredDuringSchedulingIgnoredDuringExecution`（软策略）：这是可选的，调度器会尽可能地遵循这些规则，但如果找不到满足条件的Node，仍然会调度Pod，只是可能不那么理想。示例中的`weight`参数用于指定优先级，数值越大，优先级越高。 2. Pod亲和性(pod affinity)： Pod亲和性允许我们定义Pod应该与其他哪些Pod部署在同一组Node上，以实现负载均衡或数据共享等目的。同样，Pod亲和性也包括硬策略和软策略，与节点亲和性类似，通过`podAffinity`和`podAntiAffinity`来设置。 3. 键值运算关系： 在设置亲和性规则时，我们可以使用不同的运算符来比较节点或Pod的标签(label)。例如： - `In`：标签值必须在给定的列表中。 - `NotIn`：标签值不能在给定的列表中。 - `Gt`：标签值必须大于指定的值。 - `Lt`：标签值必须小于指定的值。 - `Exists`：只要标签存在，不管其值是什么。 - `DoesNotExist`：标签不存在。 通过以上策略，Kubernetes用户可以根据实际需求灵活控制Pod的部署位置，确保服务按照预期的方式运行。在设计和配置Kubernetes应用时，充分理解并有效利用调度亲和性可以显著提升集群管理的效率和灵活性。