在容器编排中，如何设置容器的资源请求（Request）和限制（Limit），平衡性能与资源利用率，避免OOM（Out of Memory）或资源浪费，请举例说明。
答案
1) 【一句话结论】合理设置容器资源请求（Request）和限制（Limit），通过Request引导调度、Limit控制资源使用上限，平衡性能与资源利用率，避免因资源不足导致OOM或因资源过剩导致浪费。
2) 【原理/概念讲解】资源请求（Request）是容器启动时向Kubernetes调度器申请的CPU、内存等资源，调度器根据此信息为容器分配节点资源，确保容器能成功启动；资源限制（Limit）是容器运行时允许的最大资源使用量，若容器实际使用超过Limit，会被系统OOMKilled（Out of Memory Kill）。类比：Request像“餐厅点餐时说‘我要吃多少’，调度器根据点餐信息安排座位；Limit像‘餐厅规定每桌最多吃多少，超过就清空’，防止资源耗尽。两者结合，既保证容器能启动，又限制其最大使用，避免OOM或浪费。
3) 【对比与适用场景】
| 特性 | 资源请求（Request） | 资源限制（Limit） |
|---|---|---|
| 定义 | 容器启动时请求的资源 | 容器运行时允许的最大资源使用量 |
| 特性 | 影响调度分配，默认不限制使用 | 限制容器实际使用，超过被OOMKilled |
| 使用场景 | 确保容器能被调度，避免调度失败 | 防止资源耗尽，保障系统稳定性 |
| 注意点 | 不能超过节点可用资源，否则调度失败 | 不能低于Request，否则容器启动失败；不能超过节点可用资源 |
4) 【示例】以Kubernetes Pod为例，部署一个Nginx容器，设置资源请求和限制：
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx-container
image: nginx:1.21
resources:
requests:
cpu: "100m" # 请求100毫核CPU
memory: "128Mi" # 请求128MB内存
limits:
cpu: "500m" # 限制最大500毫核CPU
memory: "256Mi" # 限制最大256MB内存
解释：调度器会根据100m CPU和128Mi内存请求分配节点，容器运行时CPU不超过500m，内存不超过256Mi，既保证启动，又避免OOM或资源浪费。
5) 【面试口播版答案】面试官您好，关于容器编排中资源请求和限制的设置，核心是平衡调度与资源控制。资源请求（Request）是容器启动时向调度器申请的资源，比如CPU和内存，调度器会根据这个分配节点，确保容器能启动；资源限制（Limit）是容器运行时允许的最大资源使用量，超过会被OOMKilled。两者结合，比如一个Nginx容器，请求100m CPU和128Mi内存，限制500m CPU和256Mi内存，这样调度器会优先分配资源，容器运行时不会因为资源耗尽被杀，同时避免资源浪费。具体来说，Request引导调度，Limit限制使用，需要根据业务负载调整，比如高并发场景可能需要更高的Limit，低负载场景可以降低，确保性能和资源利用率平衡。
6) 【追问清单】
- 问题1：如果资源请求（Request）设置过低，会导致什么问题？
回答要点：调度器可能无法为容器分配资源，导致Pod调度失败，容器无法启动。 - 问题2：如何动态调整容器的资源限制？
回答要点：可通过Horizontal Pod Autoscaler（HPA）或垂直扩缩容（Vertical Pod Autoscaler）根据负载动态调整。 - 问题3：在多容器Pod中，如何协调不同容器的资源请求和限制？
回答要点：需合理分配节点资源，确保每个容器有足够的资源，避免资源争用导致性能下降或OOM。 - 问题4：资源请求和限制与QoS（Quality of Service）等级的关系？
回答要点：QoS分为Guaranteed（Request=Limit）、Burstable（Request<Limit），Guaranteed保证资源，Burstable允许临时超出Request但不超过Limit。 - 问题5：如何验证资源设置是否合理？
回答要点：通过压力测试（如JMeter）模拟高负载，结合监控工具（如Prometheus）观察资源使用情况，调整参数。
7) 【常见坑/雷区】
- 坑1：将资源请求（Request）和限制（Limit）设置相等，导致容器无法利用额外资源，资源利用率低。
- 坑2：资源请求（Request）超过节点可用资源，导致调度失败，容器无法部署。
- 坑3：资源限制（Limit）低于资源请求（Request），容器启动失败，无法运行。
- 坑4：忽略CPU和内存的关联性，比如内存限制过高但CPU限制过低，可能导致内存耗尽时CPU资源未被限制，引发OOM。
- 坑5：未考虑业务负载变化，静态设置资源参数，高负载时资源不足导致性能下降，低负载时资源浪费。