Kubernetes资源浪费的现实与根因
Kubernetes集群的资源浪费是DevOps和SRE团队必须直面的问题。生产集群的平均CPU利用率通常只有15%-25%，内存利用率30%-40%，大量资源被过量request预留却从未使用。根因很清晰：开发团队习惯性设置远超实际需求的requests值以避免OOMKill，而Kubernetes默认调度器严格按照requests做调度决策，结果就是节点上放着大量”预留不用”的资源。解决这个问题，需要从LimitRange约束、ResourceQuota配额、VPA自动调优到FinOps成本治理的完整链路。
LimitRange约束：防止资源申请失控
LimitRange在Namespace级别设置资源申请的上下限，阻止开发团队提交过大的request/limit。这是资源治理的第一道防线。
# LimitRange配置示例
apiVersion: v1
kind: LimitRange
metadata:
name: resource-limits
namespace: production
spec:
limits:
- type: Container
default:
cpu: "2"
memory: "4Gi"
defaultRequest:
cpu: "100m"
memory: "128Mi"
max:
cpu: "8"
memory: "16Gi"
min:
cpu: "50m"
memory: "64Mi"
maxLimitRequestRatio:
cpu: "4"
memory: "3"关键配置解读：
– default：未指定limit时的默认值
– defaultRequest：未指定request时的默认值
– max：单个容器资源上限，超过则拒绝创建
– maxLimitRequestRatio：limit与request的比值上限，防止limit远大于request导致QoS降级
ResourceQuota配额：Namespace维度的预算控制
LimitRange约束单个容器，ResourceQuota约束整个Namespace的总资源量，相当于给团队设一个资源预算。
# ResourceQuota配置示例
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-quota
namespace: production
spec:
hard:
requests.cpu: "64"
requests.memory: "128Gi"
limits.cpu: "128"
limits.memory: "256Gi"
pods: "200"
persistentvolumeclaims: "50"
# 按资源类型分别统计
count/deployments.apps: "20"
count/services: "30"配额超限后的表现：新Pod创建请求返回403 Forbidden，kubectl describe quota可以看到使用量和限额的对比。建议给每个业务团队分配独立Namespace和配额，避免互相挤占。
VPA自动调优：让request跟随实际负载
手动设置request值不现实——几百个微服务，每个服务的资源需求随版本迭代变化。Vertical Pod Autoscaler（VPA）通过监控实际资源使用量，自动推荐或更新Pod的request/limit值。
# VPA配置示例
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: app-vpa
namespace: production
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: order-service
updatePolicy:
minReplicas: 2
updateMode: "Auto" # 自动更新request值
resourcePolicy:
containerPolicies:
- containerName: '*'
minAllowed:
cpu: "100m"
memory: "128Mi"
maxAllowed:
cpu: "4"
memory: "8Gi"
controlledResources:
- cpu
- memoryVPA的updateMode有三种模式：
– Off：只推荐不更新，适合观察阶段
– Auto：自动更新，需要Pod重建
– Recreate：保证更新时先创建新Pod再删除旧Pod
注意：VPA Auto模式会重启Pod来更新资源值。对于无法容忍短暂中断的服务，建议先用Off模式收集推荐值，再通过CI/CD流水线更新Deployment YAML。
降本路径：从资源优化到FinOps实践
Kubernetes成本优化不是单一技术问题，而是一套组织+工具+流程的治理体系。
第一步：识别浪费
使用kube-resource-report或Kubecost扫描集群资源使用情况：
# 安装Kubecost
kubectl apply -f https://raw.githubusercontent.com/kubecost/cost-analyzer-helm-chart/master/cost-analyzer.yaml
# 或使用开源的kube-resource-report
pip install kube-resource-report
kube-resource-report --output-dir /tmp/reportKubecost会标记出request远大于实际使用的”浪费”资源，按Namespace、Label、Pod维度展示成本分布。
第二步：收紧request
根据VPA推荐值或监控数据，逐步下调request值。下调幅度建议：CPU request设为P95使用量的1.2倍，Memory request设为P99使用量的1.1倍。内存不能太紧，否则OOMKill频繁。
第三步：Spot实例混部
云上Kubernetes集群混部Spot实例和按需实例。无状态服务（Web、API）调度到Spot实例，有状态服务（数据库、缓存）保留在按需实例。Kubernetes的nodeSelector和affinity实现调度约束：
# Spot实例调度配置
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 50
preference:
matchExpressions:
- key: node.kubernetes.io/instance-type
operator: In
values: ["spot"]
# Spot被回收时的优雅迁移
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: order-serviceSpot实例价格通常是按需实例的30%-50%，但随时可能被回收。配合PodDisruptionBudget和graceful shutdown，确保Spot实例被回收时服务不受影响。
监控告警体系与成本可视化
FinOps的核心是让成本数据可见、可归因、可优化。
# Prometheus + Grafana成本监控指标
# 按Namespace统计资源成本
sum by (namespace) (
container_resource_requests_cpu_cores * on(namespace) group_left()
label_replace(kube_pod_labels, "team", "$1", "label_team", "(.+)")
) * cpu_unit_cost
# 资源浪费率
(
sum(container_resource_requests_cpu_cores) -
sum(rate(container_cpu_usage_seconds_total[7d]))
) / sum(container_resource_requests_cpu_cores)告警规则示例：
# 资源浪费告警
groups:
- name: cost-alerts
rules:
- alert: HighResourceWaste
expr: >
(sum by (namespace) (container_resource_requests_cpu_cores)
- sum by (namespace) (rate(container_cpu_usage_seconds_total[7d])))
/ sum by (namespace) (container_resource_requests_cpu_cores) > 0.7
for: 7d
labels:
severity: warning
annotations:
summary: "Namespace {{ $labels.namespace }} CPU浪费率超过70%"CI/CD流水线集成资源校验
在CI/CD流水线中加入资源声明校验，从源头阻止不合理的资源申请：
# .gitlab-ci.yml 资源校验阶段
validate_resources:
stage: validate
script:
- |
# 检查request是否超过LimitRange上限
CPU_REQUEST=$(yq '.spec.template.spec.containers[].resources.requests.cpu' deploy.yaml)
MEM_REQUEST=$(yq '.spec.template.spec.containers[].resources.requests.memory' deploy.yaml)
if [ "$CPU_REQUEST" > "8" ]; then
echo "CPU request exceeds limit: $CPU_REQUEST"
exit 1
fi
# 检查limit/request比值
CPU_LIMIT=$(yq '.spec.template.spec.containers[].resources.limits.cpu' deploy.yaml)
RATIO=$(echo "scale=1; $CPU_LIMIT / $CPU_REQUEST" | bc)
if [ $(echo "$RATIO > 4" | bc) -eq 1 ]; then
echo "CPU limit/request ratio too high: $RATIO"
exit 1
fi把资源校验作为流水线的前置门禁，不符合规范的部署请求直接拦截。配合OPA Gatekeeper可以更优雅地实现这个校验：
# OPA Gatekeeper约束模板
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
name: k8sresourceratios
spec:
crd:
spec:
names:
kind: K8sResourceRatios
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8sresourceratios
violation[{"msg": msg}] {
container := input.review.object.spec.template.spec.containers[_]
ratio := to_number(container.resources.limits.cpu) / to_number(container.resources.requests.cpu)
ratio > 4
msg := sprintf("Container %v CPU limit/request ratio %.1f exceeds 4", [container.name, ratio])
}混沌工程验证降本效果
降本调整后，需要验证服务的稳定性是否受影响。Chaos Mesh可以在Kubernetes中注入故障，测试资源收紧后的服务韧性：
# 内存压力注入测试
apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
name: memory-stress-test
namespace: chaos-testing
spec:
mode: one
selector:
namespaces: ["production"]
labelSelectors:
app: "order-service"
stressors:
memory:
workers: 1
size: "80%" # 占用容器limit的80%内存
duration: "5m"如果服务在内存压力下频繁OOMKill，说明request值收得太紧，需要回调。
从LimitRange到FinOps，Kubernetes资源治理的路径是：约束入口（LimitRange + ResourceQuota）→ 动态调优（VPA）→ 成本可视化（Kubecost）→ 流程保障（CI/CD校验 + OPA）→ 验证韧性（混沌工程）。每一步都不能跳过，否则要么浪费资源，要么牺牲稳定性。
原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/kubernetes-zi-yuan-pei-e-zhi-li-shi-zhan-cong-limitrange-2/
