Debian环境下Kubernetes资源调度策略
资源请求（requests）和限制（limits）是Kubernetes调度的核心基础，直接影响Pod的调度决策和集群稳定性。请求值定义Pod启动所需的最小资源，限制值定义Pod能使用的最大资源。配置原则包括：请求值基于应用P99峰值负载的80%设定（避免过度预留），限制值设置为请求值的2-3倍（应对突发负载）；CPU作为可压缩资源，可采用弹性策略，内存作为不可压缩资源需严格限制（防止OOM驱逐）。例如，一个Web应用的Pod配置可设置CPU请求为0.1核、内存请求为256MB，限制为0.5核、512MB。
通过自动扩缩容实现资源动态调整，应对负载波动。Horizontal Pod Autoscaler（HPA） 根据CPU、内存等资源指标自动调整Pod副本数量（如当CPU利用率超过70%时，扩容Pod至10个；低于30%时，缩容至2个）；Vertical Pod Autoscaler（VPA） 则微调Pod的资源请求，匹配实际使用需求（避免手动调整的误差）。两者结合可实现“横向扩展+纵向优化”的双重资源管理。
通过节点亲和性（nodeAffinity）和反亲和性（podAntiAffinity）实现Pod的精细化调度。节点亲和性将Pod调度到具有特定标签的节点（如将ML作业调度到带accelerator-type=nvidia-tesla-v100标签的GPU节点），提升资源利用率；Pod反亲和性避免同一应用的多个副本集中在同一节点（如将Web服务器和缓存服务分散到不同节点），提高应用的高可用性。亲和性规则分为“硬性要求”（requiredDuringSchedulingIgnoredDuringExecution）和“软性偏好”（preferredDuringSchedulingIgnoredDuringExecution），满足不同场景的需求。
通过污点与容忍度实现节点的“特殊用途”管理。节点可被打上污点（如kubectl taint nodes node1 key=value:NoSchedule），标记为不可调度（除非Pod设置了对应的容忍度）；Pod通过容忍度（tolerations）声明能容忍的污点，从而调度到特殊节点（如将数据库Pod调度到带dedicated=db污点的节点，避免被普通Pod占用）。这种策略适用于维护、专用节点等场景。
通过修改KubeSchedulerConfiguration配置文件，调整调度器的打分策略以优化资源分配。例如，启用NodeResourcesBalancedAllocation插件并提高其权重（如weight: 2），增强调度器对节点资源均衡性的考虑（避免资源碎片化）；或配置PodTopologySpread插件，将Pod均匀分布到不同节点或可用区，提升集群的整体利用率和容错性。
使用监控工具（如Prometheus+Grafana）实时监控集群资源使用情况（CPU、内存、磁盘IO等），识别资源瓶颈（如某节点CPU利用率长期超过80%）；结合监控数据调整资源请求、HPA阈值或调度策略（如增加节点资源、修改HPA的averageUtilization参数），实现动态优化。例如，若监控发现某节点的内存利用率持续偏高，可将部分Pod迁移至低负载节点，或扩容该节点的内存。