在新凯来为某大型企业部署的Kubernetes集群中，如何配置资源限制和请求/限制（QoS）以保障关键业务应用的稳定性？请说明具体配置参数和调整策略。
答案
1) 【一句话结论】：通过为关键业务Pod配置资源请求（requests）等于限制（limits，即Guaranteed QoS类），结合合理调整请求/限制值，确保资源隔离与优先保障，避免资源争抢导致应用不稳定。
2) 【原理/概念讲解】：老师口吻，解释资源请求和限制的作用。资源请求（requests）是Pod向调度器承诺的最低资源需求，调度器会优先选择有足够资源分配的节点；资源限制（limits）是容器能使用的最大资源，容器不会超过此值，防止资源耗尽导致OOM。QoS类（Quality of Service）根据请求与限制的关系分为三类：Guaranteed（请求=限制，调度优先，资源稳定）、Burstable（请求<限制，调度优先，超出部分按比例分配）、BestEffort（请求远小于限制，调度优先级低，资源不足时被驱逐）。类比：请求是“承诺”要多少资源，限制是“上限”，QoS类是资源分配的优先级，就像学校分配宿舍，Guaranteed类学生（承诺住满整个房间）优先分配，Burstable类（承诺住部分）次之，BestEffort类（承诺住小部分）最后。
3) 【对比与适用场景】：
| QoS类 | 定义（请求与限制关系） | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Guaranteed | requests = limits | 调度优先，资源稳定，不会被驱逐 | 关键业务（如支付、核心服务） | 需要预留足够资源，避免资源浪费 |
| Burstable | requests < limits | 调度优先，超出请求部分按比例分配 | 中等业务（如日志收集、缓存） | 资源不足时可能被短暂驱逐 |
| BestEffort | requests << limits | 调度优先级低，资源不足时被驱逐 | 非关键业务（如测试、临时任务） | 需要容忍资源不足，避免影响核心业务 |
4) 【示例】：关键业务Pod的YAML示例，请求和限制匹配，体现Guaranteed类。
apiVersion: v1
kind: Pod
metadata:
name: critical-payment-pod
spec:
containers:
- name: payment-app
image: newkailai/critical-payment:1.0
resources:
requests:
cpu: "500m" # 0.5核，最低需求
memory: "512Mi"
limits:
cpu: "1" # 1核上限，防止OOM
memory: "1Gi"
# QoS类隐式为Guaranteed（requests=limits）
5) 【面试口播版答案】：面试官您好，针对Kubernetes中资源限制和QoS配置保障关键业务稳定性的问题，核心是通过合理设置Pod的requests（请求）和limits（限制），结合QoS类（Guaranteed、Burstable、BestEffort）来隔离资源。对于关键业务，我们通常设置requests等于limits（即Guaranteed类），这样调度器会优先调度，且容器资源不会超过限制，避免资源争抢导致OOM。比如，一个关键业务Pod的CPU请求设为500m，内存512Mi，限制CPU为1核，内存1Gi，既满足业务需求，又防止资源过度消耗。调整策略上，先通过压测确定业务最小资源需求，然后限制略高于请求，确保资源安全。对于非关键业务，则设置请求远小于限制，降低调度优先级，避免资源抢占。总结来说，通过资源请求和限制的精准配置，结合QoS类，可以有效保障关键业务应用的稳定性。
6) 【追问清单】：
- 问题1：如何动态调整资源限制？
回答要点：通过更新Pod的YAML文件，修改resources字段，然后kubectl apply，或者使用HPA（Horizontal Pod Autoscaler）结合资源指标动态调整。 - 问题2：QoS类是否可以显式设置？
回答要点：在Kubernetes中，QoS类是通过请求与限制的关系隐式定义的，但某些版本（如1.22+）支持显式设置qosClass字段，例如qosClass: "Guaranteed"。 - 问题3：如果多个Pod竞争资源，如何避免资源饥饿？
回答要点：通过设置合理的资源请求（确保每个Pod有最低资源），并限制资源上限，同时结合资源配额（Resource Quotas）限制命名空间内总资源，避免资源过度分配。 - 问题4：如何监控资源使用情况？
回答要点：使用Prometheus + Node Exporter监控节点资源，以及Kubernetes的Metrics Server，通过Pod的requests/limits使用率指标，及时发现资源异常。 - 问题5：在大型集群中，如何统一管理资源配额？
回答要点：使用Resource Quotas和Limit Ranges，在命名空间级别设置总资源配额，同时为每个Pod设置合理的请求/限制，确保资源分配的统一性。
7) 【常见坑/雷区】：
- 坑1：请求和限制设置过松（如请求远小于限制），导致容器OOM，业务崩溃。
雷区：未根据业务负载测试最小资源需求，盲目设置宽松限制。 - 坑2：请求和限制设置过紧（如请求接近限制），导致业务卡顿，响应慢。
雷区：未考虑业务峰值负载，资源不足时无法扩展。 - 坑3：忽略QoS类的作用，只关注请求/限制数值，导致关键业务调度优先级低。
雷区：未理解QoS类对资源分配的影响，仅通过数值判断，忽略调度逻辑。 - 坑4：资源单位理解错误（如将m（milli）误认为M（mega）），导致资源配置错误。
雷区：未熟悉Kubernetes资源单位的缩写（如m=1/1000，Mi=2^20字节）。 - 坑5：未考虑容器运行时的资源限制（如Docker的cgroup设置），导致实际资源使用与配置不符。
雷区：假设容器运行时完全遵循Kubernetes的请求/限制，忽略实际运行时的资源控制。