组件：优预选策略
1. 预选策略 (Predicate)
预选策略是一组硬性条件，用于初步筛选节点。如果任何一个预选策略检查失败，该节点就会被立即排除，没有资格运行当前 Pod。这个过程是并行的。
核心算法/策略包括（但不限于）：
| 策略名称 | 功能描述 |
|---|---|
PodFitsResources | 检查节点剩余的 CPU 和内存资源是否满足 Pod 的requests配置。这是最基础的资源检查。 |
PodFitsHostPorts | 检查 Pod 声明的hostPort在节点上是否已经被占用。 |
HostName | 检查节点名称是否匹配 Pod 配置中的spec.nodeName（通常由用户直接指定，跳过调度）。 |
MatchNodeSelector | 检查节点的标签 (labels) 是否满足 Pod 配置的nodeSelector或nodeAffinity（节点亲和性）的要求。 |
NoVolumeZoneConflict | 在集群跨多个故障域（如 AWS 的 Availability Zone）时，检查 Pod 请求的持久卷 (PV) 是否与节点在同一区域，避免跨域挂卷。 |
CheckNodeMemoryPressure | 检查节点是否存在内存压力。如果存在，则不会将新的 Pod 调度到该节点（除非 Pod 有特定容忍设置）。 |
CheckNodePIDPressure | 检查节点上的进程 ID (PID) 资源是否不足。 |
CheckNodeDiskPressure | 检查节点是否存在磁盘空间压力（例如根分区可用空间不足）。 |
CheckNodeCondition | 检查节点状态是否正常，如Ready、OutOfDisk、NetworkUnavailable等。 |
PodToleratesNodeTaints | 检查 Pod 的tolerations（容忍）是否能够容忍（匹配）节点的taints（污点）。这是实现污点与容忍机制的核心。 |
工作流程：调度器会遍历所有节点，对每个节点并行执行所有配置的预选策略。只有通过所有策略的节点，才会被加入到“合格节点”列表，进入下一阶段（优选）。
2. 优选策略 (Priorities)
优选策略用于对通过预选的节点进行排序。每个策略都会给节点计算一个分数（通常为 0-10 分）， scheduler 会将所有策略的分数按权重加权求和，得到节点的最终得分，并选择得分最高的节点。如果有多个节点得分相同，则随机选择一个。
核心算法/策略包括（但不限于）：
| 策略名称 | 功能描述 | 目标 |
|---|---|---|
LeastRequested | 得分 = ((节点总容量 - Pod请求量 -节点已分配量) / 节点总容量) * 10 | 优先选择资源空闲率更高的节点，使集群负载更均衡。 |
BalancedResourceAllocation | 计算 CPU 和内存使用率的差值，差值越小得分越高。 | 优先选择 CPU 和内存使用率更均衡的节点，避免一个资源耗尽而另一个资源剩余很多。 |
ImageLocality | 根据节点上是否已存在 Pod 所需的容器镜像以及镜像的大小来评分。 | 优先选择已有所需镜像的节点，减少拉取镜像的时间。 |
NodeAffinity | 根据preferredDuringSchedulingIgnoredDuringExecution（偏好）规则进行评分。匹配的表达式越多，得分越高。 | 实现Pod 对节点的软性偏好。 |
TaintToleration | 根据 Pod 对节点污点的容忍程度进行评分。需要容忍的污点越多，得分越低。 | 优先选择需要容忍的污点更少的节点。 |
InterPodAffinity | 根据 Pod 间亲和性 (podAffinity/podAntiAffinity) 的preferred规则进行评分。 | 实现Pod 之间的软性亲和或反亲和。 |
SelectorSpread | 尽量将属于同一个 Service、StatefulSet 或 ReplicaSet 的 Pod分散到不同的节点、机架或可用区上运行。 | 提高应用的高可用性，避免单点故障。 |
工作流程：
对每个通过预选的节点，遍历所有优选策略。
每个策略为该节点打一个分（
score）。每个策略都有一个权重（
weight），最终得分是score * weight的加权和。选择总分最高的节点。如果多个节点分数相同，则随机选择。
总结与类比
你可以把这个过程想象成“招聘过程”：
预选 (Predicate)：就像简历筛选。
硬性条件：“本科以上学历”、“5年以上工作经验”、“必须掌握Go语言”。
不符合任何一条的候选人直接淘汰，不会进入面试。
优选 (Priorities)：就像面试打分。
面试官们（不同策略）从不同维度（技术能力、沟通能力、文化契合度）给候选人打分。
每个维度的权重可能不同（例如技术能力权重为 2，沟通能力权重为 1）。
最后将加权分相加，选择总分最高的候选人。
Kubernetes 调度器通过这个强大、灵活且可扩展的两阶段模型，能够智能地做出最合适的调度决策，满足复杂多样的部署需求。你也可以编写自己的调度器扩展（Scheduler Framework）来添加自定义的预选和优选策略。
K8S核心概念
| 概念 | 作用 |
|---|---|
| cluster | 集群，Cluster指的是由Kubernetes管理的一组节点和资源池。 由Master和多个Worker节点组成，Master用于集群管理和控制，而Worker节点用于运行应用程序和Pod。提供了一种可扩展的、弹性的平台，用于分布式应用程序和容器的部署和管理。 |
| node | 节点，是集群中的工作节点，用于运行Pod和容器。 是物理或虚拟机器，具有足够的资源（CPU、内存、存储）来运行容器化的应用。Kubernetes会自动将Pod调度到可用的节点上，以实现负载均衡和高可用性。 |
| Container | 容器， 容器是一种轻量级的虚拟化技术，用于隔离和运行应用程序及其依赖项。将应用程序与其运行时环境进行隔离，并提供了一个独立的运行空间，使得应用程序可以在不同的环境中移植和部署。 |
| Namespace | 命名空间， Namespace用于在Kubernetes集群中划分虚拟的资源隔离区域。 可用于组织和管理资源，以及为不同的团队、项目或环境提供逻辑分离。 在一个集群中，可以有多个命名空间，每个命名空间都有自己的一组资源和访问策略。 |
| Pod | 容器组，Kubernetes基本调度单位，可以包含一个或多个容器。这些容器共享相同的网络和存储资源，并运行在同一主机上。 提供了一个隔离的运行环境，为容器提供了共享的IP地址和端口空间。 通常，Pod用于运行关联的容器，例如共享相同的资源和上下文的应用程序。 |
| Service | 服务， Service定义了一组Pod的稳定网络终点，通过标签选择器与这些Pod进行关联。充当入口和负载均衡器，封装了一组Pod，并提供一个持久的访问地址（Cluster IP或Node IP）。 还支持内部服务发现和跨集群通信。 |
| ReplicaSet | 副本集，ReplicaSet用于定义Pod的副本数量和在集群中的运行策略，确保指定的Pod副本数始终运行，并根据需要进行自动扩展或收缩。当Pod由于故障或节点故障而终止时，ReplicaSet会自动重新启动新的Pod副本。 |
| Deployment | 部署，Deployment是一种用于声明化管理Pod和ReplicaSet的资源对象。可以定义Pod的期望状态，自动创建和更新ReplicaSet，并实现滚动升级和回滚策略，以确保无缝的应用程序更新。 |
| ConfigMap | 配置映射，ConfigMap是一种存储配置数据的资源对象，用于将配置参数传递给应用程序。可以存储环境变量、配置文件、命令行参数等。 可以与Pod或容器相关联，并在容器启动时注入相关的配置信息。 |
| Secrets | 密钥用于安全地存储和管理敏感信息，如密码、凭证等。 -Kuberentes中的Secret是一种资源对象，用于存储和传递加密的数据。 -密钥可以被挂载到容器中，用于应用程序的配置文件或认证凭证。 |
| DaemonSet | DaemonSet是Kubernetes中的一个重要概念，提供了一种简单且可靠的方式来在集群的所有节点上运行相同的Pod，适用于许多系统级任务和后台进程的部署场景。 <br>1.每个节点一个Pod副本：DaemonSet会在集群的每个节点上启动一个Pod副本，以确保每个节点都有该Pod的运行实例。<br>2. 系统级任务和守护进程：DaemonSet通常用于运行系统级任务和守护进程，例如日志收集器、监控代理和网络代理等。这些任务通常需要在每个节点上运行，并且要与节点的生命周期同步。 <br>3. 自动扩缩容：当有新节点加入集群或某个节点从集群中移除时，DaemonSet会自动检测节点的状态变化，并相应地启动或终止Pod副本。 <br>4. 节点亲和性规则：可以通过节点亲和性规则来选择在哪些节点上运行DaemonSet的Pod。这允许你将特定的任务或服务与特定类型的节点关联起来。 <br>5. 资源限制和调度约束：可为DaemonSet中的Pod指定资源限制和调度约束，以确保它们在节点上均匀分布并满足资源需求。 |
Kubetnetes 涉及的端口
| 角色 | 协议 | 方向 | 端口范围 | 组件 | 使用者 |
|---|---|---|---|---|---|
| master | TCP | 入站 | 6443 | kube-apiserver | 所有 |
| TCP | 入站 | 2379~2380 | etcd | kube-apiserver | |
| TCP | 入站 | 10250 | kubelet | kube-apiserver，自身 | |
| TCP | 入站 | 10259 | kube-scheduler | 自身 | |
| TCP | 入站 | 10257 | kube-controller-manager | 自身 | |
| node | TCP | 入站 | 10250 | kubelet | kube-apiserver |
| TCP | 入站 | 30000~32767 | Service NodePort | 自身 |
