在现代应用部署中，越来越多企业选择容器化技术来运行服务。比如一个电商网站，在大促期间访问量猛增，后台需要快速扩容多个订单处理实例。这时候，光靠人工一个个启动容器显然不现实，得靠容器平台的资源调度能力自动完成。
资源调度是啥？
简单说，资源调度就是决定“哪个容器跑在哪台机器上”。平台会根据当前服务器的CPU、内存等使用情况，以及容器的需求，做出最优分配。就像快递调度中心安排货车送货，既要快，又不能超载。
常见的容器平台如Kubernetes（简称k8s），内置了强大的调度器。它会监听新创建的Pod（容器的封装单位），然后挑选最合适的节点（Node）去运行。这个过程不是随机的，而是基于一系列策略计算出来的。
调度策略怎么定？
举个例子，你有两个服务：一个是前端Web服务，需要高网络吞吐；另一个是数据分析任务，吃CPU。如果把它们都塞进同一台机器，可能互相抢资源，导致前端响应变慢。这时候可以通过设置资源请求（requests）和限制（limits）来避免冲突。
apiVersion: v1
kind: Pod
metadata:
name: web-server
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"上面这个YAML定义里，告诉调度器：这个Nginx容器至少需要64MB内存和0.25个CPU核心才能启动，最多只能用到128MB内存和0.5个CPU。调度器会找满足条件的节点，不会往只剩100MB内存的机器上塞。
亲和性与反亲和性：让容器懂“社交”
有时候你还希望控制容器之间的“距离”。比如数据库和它的缓存最好跑在同一台物理机上，减少网络延迟，这就是“亲和性”。而多个关键服务副本则要分散在不同机器，防止单点故障，这叫“反亲和性”。
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- redis-master
topologyKey: kubernetes.io/hostname这段配置确保同一个Redis主节点的多个Pod不会被调度到同一台主机上。相当于不让所有鸡蛋放在一个篮子里。
实际场景中的调度优化
某公司上线了一个AI推理服务，每个实例占用8GB显存。他们用的是混合节点集群，有些机器带GPU，有些没有。通过给GPU节点打标签，并在调度时指定nodeSelector，确保只有具备GPU的机器才会运行这些容器。
spec:
nodeSelector:
hardware-type: gpu-node
containers:
- name: ai-inference
image: ai-model:v1
resources:
limits:
nvidia.com/gpu: 1这样一来，普通CPU节点不会被误用，GPU资源也得到了专有保障，整体利用率提升明显。
资源调度不只是“放哪”的问题，更是保障稳定性、提升资源效率的关键环节。合理的配置能让系统在高负载下依然平稳运行，也能帮企业在云成本上省下不少开销。