合理配置Kubernetes资源请求与限制、设置命名空间级配额和默认策略，并结合监控调优，可有效保障应用稳定性和资源利用率。
在云原生环境中，合理管理应用的资源使用是保障系统稳定性、提升资源利用率的关键。Kubernetes 作为主流的云原生编排平台，提供了资源限制（Resource Limits）与资源请求（Resource Requests）以及资源配额（Resource Quotas）等机制，帮助开发者和运维人员有效控制容器化应用对 CPU、内存等资源的消耗。
资源请求与限制：定义 Pod 的资源使用边界
每个 Pod 都可以设置资源请求和限制，用于告知调度器如何分配节点资源，并在运行时约束容器行为。
- requests：表示容器启动时所需保证的最小资源量。Kubernetes 调度器依据此值选择合适的节点，确保有足够的资源供 Pod 运行。
- limits：表示容器可使用的最大资源上限。当容器尝试超出该限制时，可能会被限流（CPU）或终止（内存 OOMKilled）。
例如，以下 YAML 片段为容器设置了合理的资源边界：
resources:requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "256Mi"
建议避免将 limits 设置得过高，防止资源浪费；也不应过低，以免影响应用性能或频繁触发重启。
命名空间级资源配额：控制团队或项目的总体消耗
通过 ResourceQuota 对象，可以在命名空间级别限制资源总用量，适用于多团队共享集群的场景。
常见的 ResourceQuota 配置包括：
- 限制命名空间中所有 Pod 的 CPU 和内存总和
- 控制持久卷数量或总存储容量
- 限定特定类型对象（如 Pods、Services、ConfigMaps）的数量
示例配置：
apiVersion: v1kind: ResourceQuota
metadata:
name: dev-quota
namespace: development
spec:
hard:
requests.cpu: "2"
requests.memory: "4Gi"
limits.cpu: "4"
limits.memory: "8Gi"
pods: "20"
persistentvolumeclaims: "10"
这样可以防止某个项目无节制地占用集群资源，实现公平调度与成本控制。
限制范围：为命名空间设定默认资源策略
使用 LimitRange 可以为命名空间中的容器设置默认的 request 和 limit 值，并规定允许的最大/最小边界。
其主要作用包括：
- 自动为未指定资源的 Pod 补充默认值
- 防止用户提交极端资源配置（如内存 limit 为 1TiB）
- 设定 limit/request 比例，控制资源弹性
典型 LimitRange 示例：
apiVersion: v1kind: LimitRange
metadata:
name: default-limits
namespace: staging
spec:
limits:
- type: Container
default:
cpu: 100m
memory: 200Mi
defaultRequest:
cpu: 50m
memory: 100Mi
max:
cpu: 500m
memory: 1Gi
min:
cpu: 10m
memory: 16Mi
这有助于统一团队的资源配置标准，减少因配置不当引发的问题。
监控与调优：持续优化资源分配
仅设置资源参数还不够，需结合监控工具（如 Prometheus + Grafana）观察实际使用情况。
重点关注指标：
- 容器的实际 CPU 和内存使用率
- 是否频繁触发 OOMKilled 或 CPU throttling
- 资源 request 是否远低于 usage，造成调度效率低下
根据数据定期调整 requests/limits，做到“够用但不浪费”。也可引入 Vertical Pod Autoscaler（VPA）自动推荐并更新资源配置。
基本上就这些。合理使用资源请求、限制、配额和限制范围，再配合持续监控，才能在保障应用稳定的前提下最大化集群效率。这套机制不复杂，但在生产环境中极易被忽视，值得投入精力规范落地。
