云资源调度怎么不卡？QoS保障其实就藏在这些配置里

上周帮朋友远程调一台云上视频转码服务，明明开了8核16G，结果一跑高并发任务就花屏、延迟飙升。查日志发现不是CPU打满，而是网络带宽被后台监控和日志采集悄悄占了70%——这根本不是资源不够，是调度没管住‘闲不住’的进程。

调度不是分蛋糕，是管好谁先吃、吃多少

很多人以为云调度就是把VM或容器往空闲机器上一扔。其实真正在后台干活的是调度器（比如Kubernetes的kube-scheduler、YARN的ResourceManager），它得实时看三件事：节点剩余CPU/内存、网络IO水位、还有你写的QoS策略。

举个实际例子：你在阿里云ACK集群里部署一个Web服务，同时又跑一个离线日志分析Job。如果都不设限制，那个日志Job可能半夜把磁盘IO打满，导致白天用户点按钮要等3秒。这时候就得靠QoS分级：

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
  - name: nginx
    image: nginx:alpine
    resources:
      requests:
        memory: "256Mi"
        cpu: "250m"
      limits:
        memory: "512Mi"
        cpu: "500m"
  # 这个Pod会被标记为Guaranteed QoS等级

而日志Job可以设成Burstable：

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "1Gi"

K8s会优先保证Guaranteed Pod的资源不被抢占，Burstable的则可能被临时限频或驱逐——就像会议室里，重要客户会谈有固定时段和独立空调，实习生培训可以灵活调教室，但不能抢了主会场的投影仪。

别只盯CPU，网络和磁盘才是隐形瓶颈

某次我们压测一个微服务API，监控显示CPU才40%，响应却从200ms飙到2s。最后发现是同节点上另一个服务在疯狂刷/var/log，把本地SSD的IOPS打到98%，连带影响了数据库连接池建连速度。

解决办法很简单：在云平台控制台给关键服务绑定专属EBS卷，或者用io.weight（cgroup v2）限制非核心进程的磁盘带宽：

echo "100" > /sys/fs/cgroup/my-batch/io.weight

同样，对延迟敏感的服务（比如实时风控接口），建议直接开启云厂商的“增强型网络”或绑定弹性网卡，绕过宿主机vSwitch的排队机制。

小技巧：三步快速验QoS是否生效

1. 查Pod当前QoS等级：
kubectl get pod web-server -o jsonpath='{.status.qosClass}'
返回Guaranteed才算到位；

2. 看节点实际资源分配：
kubectl describe node | grep -A 10 Allocated
确认requests总和没超节点Capacity；

3. 模拟争抢：起一个stress-ng --vm 2 --vm-bytes 1G的Pod，观察目标服务P95延迟是否突增——如果波动＜10%，说明QoS兜住了。

云不是无限资源池，调度和QoS也不是运维黑盒。把资源当水电来管：关键服务接专线（Guaranteed），普通任务走峰谷电价（BestEffort），该限流时就装水表（limit），系统自然稳得住。