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 可降低风险。

0 赞

0 踩