Kubernetes 在 CentOS 上的资源调度优化指南
一 基础与系统层优化
- 关闭 Swap：Kubelet 默认不允许在启用 Swap 时正常工作，避免内存超卖导致调度失真。
- 内核网络与连接跟踪：提升系统可扩展性与稳定性，建议设置为：
- fs.file-max=1000000
- net.ipv4.neigh.default.gc_thresh1=1024；gc_thresh2=4096；gc_thresh3=8192
- net.netfilter.nf_conntrack_max=10485760
- net.core.netdev_max_backlog=10000
- 存储与 IO 调度：为 SSD/NVMe 选择 noop/deadline，为 SAS/HDD 选择 deadline，降低调度与合并写带来的抖动。
- 控制平面与数据面：为 etcd 使用 SSD、部署 3/5 节点 HA，并适当增大后端配额（如 –quota-backend-bytes）；kube-scheduler 可按集群规模调大并发参数（如节点数≥3000 时：–max-requests-inflight=3000、–max-mutating-requests-inflight=1000；节点数 1000–3000 时：–max-requests-inflight=1500、–max-mutating-requests-inflight=500），以提升大规模场景下的调度吞吐。
二 调度策略与拓扑感知
- 亲和与反亲和：用 nodeAffinity 将负载调度到具备特定标签（如 disktype=ssd）的节点；用 podAntiAffinity 将同一应用的副本分散到不同节点（topologyKey 常用 kubernetes.io/hostname），提升容灾与稳定性。
- 污点与容忍：为专用节点（如 GPU/高性能存储）打污点（如 key=value:NoSchedule），仅允许声明容忍的 Pod 调度，避免资源争用。
- 拓扑分布约束：通过 topologySpreadConstraints 按 zone/rack/host 均匀分布副本，控制最大不均衡度（maxSkew），增强可用性与资源利用的均衡性。
- 调度器扩展：基于 Scheduling Framework 启用或定制打分/过滤插件（如社区 Trimaran 等负载感知打分插件），让调度更贴近真实利用率与业务目标。
三 资源配置与配额治理
- Requests 与 Limits：为每个容器设置合理的 requests/limits，调度器依据 requests 选择节点，limits 用于运行时限制；示例：
- resources.requests: cpu=250m, memory=64Mi
- resources.limits: cpu=500m, memory=128Mi
- QoS 分类：
- Guaranteed（requests == limits）：关键业务，强稳定性优先；
- Burstable（requests < limits）：允许突发，通用应用；
- BestEffort（未设）：低优先级，不建议生产使用。
- 资源配额与默认限额：在命名空间级设置 ResourceQuota 限制总量，用 LimitRange 提供默认 requests/limits，避免“无限制”与资源滥用。
- 节点资源预留：通过 kubelet 为系统与 kube 组件预留资源，防止节点过载，例如：
- –system-reserved=cpu=500m,memory=1Gi
- –kube-reserved=cpu=200m,memory=512Mi。
四 弹性伸缩与调度器参数
- 弹性扩缩容：
- HPA（Horizontal Pod Autoscaler）：基于 CPU/内存/自定义指标 自动扩缩 Pod 数量；
- VPA（Vertical Pod Autoscaler）：自动建议或更新 requests/limits，减少人工反复调参；
- Cluster Autoscaler：当节点资源不足时自动扩容节点，配合调度策略实现“按需供给”。
- 调度器并发与策略：结合集群规模与 API 负载，适度提升 kube-scheduler 的 –max-requests-inflight 与 –max-mutating-requests-inflight；在大规模集群中，可按需启用/调优均衡类打分插件（如 NodeResourcesBalancedAllocation）以优化节点资源均衡。
五 监控 观测 与常见排障
- 监控与日志：部署 Prometheus + Grafana 观察节点与 Pod 的 CPU/内存/网络/磁盘 IO 与调度指标；使用 EFK/ELK 集中分析日志，快速定位 Pending/OOMKilled 等调度与资源问题。
- 常见症状与处置：
- Pod 长时间 Pending：检查节点资源是否不足、ResourceQuota 限制、亲和/污点规则是否阻断；
- 节点负载不均：使用 Descheduler 对已运行 Pod 做二次重调度，缓解热点与碎片；
- OOMKilled：适当提升内存 limits 或优化应用内存占用；
- 突发限流或吞吐下降：复核 requests/limits 与 QoS，结合 HPA/VPA 做动态调优。
