CentOS K8s资源限制设置方法

CentOS 上 Kubernetes 资源限制设置方法

一 核心概念与单位

• 在 Pod/容器 上通过 requests（请求）与 limits（上限）控制资源：调度器依据 requests 选择节点，kubelet/内核依据 limits 强制执行。CPU 超限会被限流，内存超限会触发 OOM Killer 终止容器。仅设置 limits 而未设置 requests 时（且无准入默认），requests 会被复制为与 limits 相同。CPU 以核为单位，可用小数或毫核（如 500m），内存以字节为单位，常用 Mi/Gi。从 v1.34 起（默认启用），可在 Pod 级设置资源边界（PodLevelResources），便于多容器共享与预算控制。内存为介质的 emptyDir 计入容器内存用量，未设 sizeLimit 时上限受限于 Pod 内存限制。

二 Pod 与容器级配置

• 基本示例（Deployment 内单容器）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        resources:
          requests:
            cpu: "250m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"

• 扩展资源（如 NVIDIA GPU）

apiVersion: v1
kind: Pod
metadata:
  name: gpu-demo
spec:
  containers:
  - name: cuda
    image: nvidia/cuda:12.2-base
    resources:
      limits:
        nvidia.com/gpu: 1

• 说明
  • 建议对关键容器同时设置 requests/limits，避免无请求导致调度不稳或无上限导致节点资源被挤占。
  • 使用 GPU 需集群具备相应设备插件与驱动支持。

三 命名空间级管控

• ResourceQuota：限制命名空间内资源总量与对象数量

apiVersion: v1
kind: ResourceQuota
metadata:
  name: ns-quota
  namespace: default
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"

• LimitRange：为容器设置默认请求/上限与最小/最大边界

apiVersion: v1
kind: LimitRange
metadata:
  name: ns-limit-range
  namespace: default
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "250m"
      memory: "256Mi"
    min:
      cpu: "100m"
      memory: "64Mi"
    max:
      cpu: "2"
      memory: "2Gi"

• 作用
  • Quota 防止单命名空间资源“超卖”；LimitRange 解决“未指定资源”的默认与越界问题。

四 服务质量 QoS 与驱逐优先级

• QoS 等级
  • Guaranteed：所有容器均设置 cpu/memory 的 requests=limits，节点资源紧张时最不易被驱逐。
  • Burstable：至少有一个容器设置了 requests 或 limits（且不完全相等）。
  • BestEffort：未设置任何 requests/limits，资源紧张时最先被驱逐。
• OOM 评分倾向
  • Guaranteed：oom_score_adj ≈ -998（最不易被杀）
  • BestEffort：oom_score_adj = 1000（最易被杀）
  • Burstable：oom_score_adj 介于 2~999，request 越大保护越强
• 实践建议
  • 对稳定性要求高的核心服务尽量配置为 Guaranteed。

五 验证与常见问题

• 验证配置
  • 查看 Pod 资源字段：kubectl get pod < pod> -o yaml | grep -A5 resources
  • 事件与状态：kubectl describe pod < pod> （关注 Events、Last State.Reason 等）
  • 资源用量：kubectl top pod < pod> --containers
• 常见问题与要点
  • 只设 limits 不配 requests 时，requests 会被设为与 limits 相同；调度只看 requests，超限运行看 limits。
  • CPU 超限会被限流但不会因超限被杀；内存超限可能触发 OOM 并重启容器。
  • 使用内存为介质的 emptyDir 会计入容器内存占用，未设 sizeLimit 时上限受 Pod 内存限制影响。
  • 节点资源紧张时，未设资源或 BestEffort 的 Pod 更易被驱逐；合理设置 requests/limits 与 QoS 可降低风险。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！