你有没有遇到过这种情况：公司网站在促销活动时突然卡顿，后台一查发现服务器资源被某个服务占得死死的，其他应用只能排队干等？其实这就像高峰时段的电力供应，如果没做好调配，再充足的电量也撑不住突发需求。现在越来越多企业用容器平台跑应用，而资源调度就是那个看不见的‘电网调度员’。
资源不是越多越好，关键是怎么分
很多人觉得，只要服务器够多、内存够大，系统就不会崩。可现实是，就算你有 100 台机器，如果调度不合理，可能一半资源闲置，另一半却在超负荷运转。容器平台比如 Kubernetes，并不只是把应用打包运行就完事了，它真正的本事在于动态分配 CPU 和内存。比如一个订单服务在双十一流量暴增，调度器会自动给它多分点资源，等高峰期过了再收回来给别的服务用。
调度策略藏在配置里
Kubernetes 的调度不是靠猜，而是看规则。你可以告诉系统哪些节点适合跑计算密集型任务，哪些留给高内存应用。下面就是一个简单的 Pod 配置片段，用来指定资源请求和限制：
apiVersion: v1
kind: Pod
metadata:
name: my-app-pod
spec:
containers:
- name: app-container
image: myapp:v1
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"这里的 requests 是启动时最低保障，limits 是上限。就像你家用电，申请的是 10A 电表（request），但跳闸保护设在 15A（limit），避免短路烧坏线路。
亲和性与反亲和性：别让鸡蛋放在一个篮子里
有时候你希望两个服务尽量跑在同一台机器上，减少网络延迟，这就叫“亲和性”。比如日志收集器最好跟业务容器贴得近一点。反过来，为了防止单点故障，同一应用的多个副本应该分散在不同节点，这就是“反亲和性”。
举个例子，如果你有个备份任务每天凌晨跑，完全可以把它安排在白天空闲的机器上，既不抢资源，又把利用率拉满了。这种灵活调度，比买一堆新服务器划算多了。
压缩备份也能搭上顺风车
说到压缩备份，很多人还在定时跑脚本，半夜三更来一波资源洪峰。其实在容器平台里，可以把备份任务做成低优先级的 Job，只在系统空闲时运行。配合调度器的资源回收机制，既能完成任务，又不影响主业务。甚至可以把压缩过程拆成多个小步骤，由调度器穿插在其他任务间隙执行，真正做到‘零打扰’。
技术本身没有高低，关键看怎么用。把资源调度当成日常运维的一部分，就像调节家里的水电气开关一样自然，系统的稳定性和效率才会真正提上来。