22-Kubernetes 资源模型
学习目标
- 深入理解 Kubernetes 资源模型 (requests/limits)
- 掌握 QoS 类别的划分和 OOM 优先级
- 了解 Kubelet 的 Cgroup 层级管理
- 掌握资源配额与 LimitRange 的使用
- 学习生产环境资源配置最佳实践
前置知识
- Kubernetes 基本概念
- Cgroup 资源控制
- OOM Killer 机制
一、资源模型概述
1.1 requests 与 limits
┌────────────────────────────────────────────────────────────────────────┐
│ Kubernetes 资源模型 │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ resources: │
│ requests: # 请求量 (调度保证) │
│ cpu: "500m" # 0.5 CPU 核心 │
│ memory: "256Mi" # 256 MB 内存 │
│ limits: # 限制量 (运行时强制) │
│ cpu: "1000m" # 1 CPU 核心 │
│ memory: "512Mi" # 512 MB 内存 │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ requests: 调度器用于决定 Pod 放在哪个节点 │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ - 节点 allocatable >= sum(pod requests) │ │ │
│ │ │ - 保证 Pod 能获得的最小资源 │ │ │
│ │ │ - 不创建 Cgroup 限制 (内存) │ │ │
│ │ │ - CPU requests → cpu.shares │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ limits: 容器运行时强制限制 │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ - 创建 Cgroup 限制 │ │ │
│ │ │ - 内存超限触发 OOM Kill │ │ │
│ │ │ - CPU 超限触发 Throttling │ │ │
│ │ │ - memory.limit = limits.memory │ │ │
│ │ │ - cpu.cfs_quota = limits.cpu × period │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
1.2 资源单位
┌────────────────────────────────────────────────────────────────────────┐
│ 资源单位说明 │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ CPU 单位： │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1 = 1 CPU 核心 = 1000m │ │
│ │ 500m = 0.5 CPU 核心 (millicores) │ │
│ │ 100m = 0.1 CPU 核心 │ │
│ │ │ │
│ │ 最小单位: 1m (0.001 核心) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 内存单位： │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 十进制单位 (SI): │ │
│ │ K (kilo) = 10^3 = 1,000 │ │
│ │ M (mega) = 10^6 = 1,000,000 │ │
│ │ G (giga) = 10^9 = 1,000,000,000 │ │
│ │ │ │
│ │ 二进制单位 (推荐): │ │
│ │ Ki (kibi) = 2^10 = 1,024 │ │
│ │ Mi (mebi) = 2^20 = 1,048,576 │ │
│ │ Gi (gibi) = 2^30 = 1,073,741,824 │ │
│ │ │ │
│ │ 示例: 256Mi = 256 × 1024 × 1024 = 268,435,456 bytes │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 注意: 256M ≠ 256Mi │
│ 256M = 256,000,000 bytes │
│ 256Mi = 268,435,456 bytes │
│ │
└────────────────────────────────────────────────────────────────────────┘
二、QoS 类别详解
2.1 三种 QoS 类别
┌────────────────────────────────────────────────────────────────────────┐
│ Kubernetes QoS Classes │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. Guaranteed (最高优先级) │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 条件: │ │
│ │ - Pod 中每个容器都设置了 CPU 和内存的 requests 和 limits │ │
│ │ - requests == limits (对于每个资源) │ │
│ │ │ │
│ │ 示例: │ │
│ │ resources: │ │
│ │ requests: │ │
│ │ cpu: "1" │ │
│ │ memory: "1Gi" │ │
│ │ limits: │ │
│ │ cpu: "1" # == requests │ │
│ │ memory: "1Gi" # == requests │ │
│ │ │ │
│ │ 特点: │ │
│ │ - 资源完全保证 │ │
│ │ - oom_score_adj = -997 │ │
│ │ - 最后被 OOM Kill │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 2. Burstable (中等优先级) │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 条件: │ │
│ │ - 不满足 Guaranteed 条件 │ │
│ │ - 至少一个容器设置了 requests 或 limits │ │
│ │ │ │
│ │ 示例: │ │
│ │ resources: │ │
│ │ requests: │ │
│ │ cpu: "500m" │ │
│ │ memory: "512Mi" │ │
│ │ limits: │ │
│ │ cpu: "1" # > requests │ │
│ │ memory: "1Gi" # > requests │ │
│ │ │ │
│ │ 特点: │ │
│ │ - 可以突发使用更多资源 │ │
│ │ - oom_score_adj = 2 ~ 999 (基于内存使用比例) │ │
│ │ - 内存使用越高，越可能被 OOM Kill │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 3. BestEffort (最低优先级) │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 条件: │ │
│ │ - Pod 中没有任何容器设置 requests 或 limits │ │
│ │ │ │
│ │ 示例: │ │
│ │ # 没有设置 resources │ │
│ │ containers: │ │
│ │ - name: app │ │
│ │ image: myapp │ │
│ │ # 没有 resources 字段 │ │
│ │ │ │
│ │ 特点: │ │
│ │ - 没有资源保证 │ │
│ │ - oom_score_adj = 1000 │ │
│ │ - 最先被 OOM Kill │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
2.2 OOM 优先级与 oom_score_adj
┌────────────────────────────────────────────────────────────────────────┐
│ QoS 与 OOM 优先级 │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ OOM Kill 顺序 (从先到后): │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. BestEffort Pods (oom_score_adj = 1000) │ │
│ │ ↓ │ │
│ │ 2. Burstable Pods (oom_score_adj = 2 ~ 999) │ │
│ │ - 内存使用比例越高，oom_score_adj 越高 │ │
│ │ - 计算公式: │ │
│ │ adj = 1000 - 1000 * (memory.request / memory.limit) │ │
│ │ ↓ │ │
│ │ 3. Guaranteed Pods (oom_score_adj = -997) │ │
│ │ - 几乎不会被 OOM Kill │ │
│ │ ↓ │ │
│ │ 4. 系统关键进程 (oom_score_adj = -999) │ │
│ │ - kubelet, docker 等 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Burstable oom_score_adj 计算示例: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Pod A: requests.memory=512Mi, limits.memory=1Gi │ │
│ │ adj = 1000 - 1000 × (512/1024) = 1000 - 500 = 500 │ │
│ │ │ │
│ │ Pod B: requests.memory=256Mi, limits.memory=1Gi │ │
│ │ adj = 1000 - 1000 × (256/1024) = 1000 - 250 = 750 │ │
│ │ │ │
│ │ Pod B 更可能被 OOM Kill (adj 更高) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
2.3 查看 Pod QoS 类别
# 查看 Pod 的 QoS 类别
$ kubectl get pod <pod-name> -o jsonpath='{.status.qosClass}'
Guaranteed
# 或使用 describe
$ kubectl describe pod <pod-name> | grep "QoS Class"
QoS Class: Guaranteed
# 查看所有 Pod 的 QoS
$ kubectl get pods -o custom-columns=NAME:.metadata.name,QOS:.status.qosClass
NAME QOS
nginx-abc123 Guaranteed
redis-def456 Burstable
job-ghi789 BestEffort
三、Kubelet Cgroup 管理
3.1 Cgroup 层级结构
┌────────────────────────────────────────────────────────────────────────┐
│ Kubelet Cgroup 层级 │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ /sys/fs/cgroup/ │
│ └── kubepods/ # Kubelet 管理的根 cgroup │
│ │ │
│ ├── burstable/ # Burstable QoS Pods │
│ │ ├── pod<uid>/ │
│ │ │ ├── <container-id-1>/ │
│ │ │ └── <container-id-2>/ │
│ │ └── pod<uid>/ │
│ │ │
│ ├── besteffort/ # BestEffort QoS Pods │
│ │ └── pod<uid>/ │
│ │ └── <container-id>/ │
│ │ │
│ └── pod<uid>/ # Guaranteed QoS Pods │
│ └── <container-id>/ # (直接在 kubepods 下) │
│ │
│ 层级说明: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ kubepods/ │ │
│ │ ├── Guaranteed Pods (直接子目录) │ │
│ │ ├── burstable/ (子 cgroup) │ │
│ │ │ └── Burstable Pods │ │
│ │ └── besteffort/ (子 cgroup) │ │
│ │ └── BestEffort Pods │ │
│ │ │ │
│ │ 资源分配优先级: Guaranteed > Burstable > BestEffort │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
3.2 Cgroup Driver
# Kubelet 配置 (/var/lib/kubelet/config.yaml)
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
# Cgroup Driver: cgroupfs 或 systemd
cgroupDriver: systemd # 推荐，与 systemd 集成更好
# Cgroup 根路径
cgroupRoot: / # 默认
# 资源预留
systemReserved:
cpu: "500m"
memory: "1Gi"
kubeReserved:
cpu: "500m"
memory: "1Gi"
# 驱逐阈值
evictionHard:
memory.available: "500Mi"
nodefs.available: "10%"
imagefs.available: "15%"
3.3 实战：查看容器 Cgroup
#!/bin/bash
# show_pod_cgroup.sh
POD_NAME="${1:-nginx}"
NAMESPACE="${2:-default}"
# 获取 Pod UID
POD_UID=$(kubectl get pod $POD_NAME -n $NAMESPACE -o jsonpath='{.metadata.uid}')
echo "Pod UID: $POD_UID"
# 获取 QoS 类别
QOS=$(kubectl get pod $POD_NAME -n $NAMESPACE -o jsonpath='{.status.qosClass}')
echo "QoS Class: $QOS"
# 确定 Cgroup 路径
case $QOS in
"Guaranteed")
CGROUP_PATH="/sys/fs/cgroup/memory/kubepods/pod${POD_UID}"
;;
"Burstable")
CGROUP_PATH="/sys/fs/cgroup/memory/kubepods/burstable/pod${POD_UID}"
;;
"BestEffort")
CGROUP_PATH="/sys/fs/cgroup/memory/kubepods/besteffort/pod${POD_UID}"
;;
esac
echo "Cgroup Path: $CGROUP_PATH"
echo
# 显示内存限制
if [ -d "$CGROUP_PATH" ]; then
echo "=== Memory Limits ==="
echo "Limit: $(cat $CGROUP_PATH/memory.limit_in_bytes 2>/dev/null || echo 'N/A')"
echo "Usage: $(cat $CGROUP_PATH/memory.usage_in_bytes 2>/dev/null || echo 'N/A')"
echo
echo "=== Memory Stats ==="
cat $CGROUP_PATH/memory.stat 2>/dev/null | head -10
else
echo "Cgroup path not found. Check if running on the node."
fi
四、资源配额与 LimitRange
4.1 ResourceQuota
# 命名空间级别的资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
namespace: production
spec:
hard:
# CPU 和内存总量
requests.cpu: "20" # 总 CPU 请求量
requests.memory: "40Gi" # 总内存请求量
limits.cpu: "40" # 总 CPU 限制量
limits.memory: "80Gi" # 总内存限制量
# Pod 和对象数量
pods: "50" # 最大 Pod 数
persistentvolumeclaims: "10" # 最大 PVC 数
services: "20" # 最大 Service 数
secrets: "100" # 最大 Secret 数
configmaps: "100" # 最大 ConfigMap 数
# 按 QoS 类别限制
count/pods: "50"
---
# 按优先级类的配额
apiVersion: v1
kind: ResourceQuota
metadata:
name: high-priority-quota
namespace: production
spec:
hard:
pods: "10"
scopeSelector:
matchExpressions:
- operator: In
scopeName: PriorityClass
values:
- high
4.2 LimitRange
# 命名空间默认资源限制
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: production
spec:
limits:
# Container 级别限制
- type: Container
default: # 默认 limits
cpu: "500m"
memory: "512Mi"
defaultRequest: # 默认 requests
cpu: "100m"
memory: "128Mi"
min: # 最小值
cpu: "50m"
memory: "64Mi"
max: # 最大值
cpu: "4"
memory: "8Gi"
maxLimitRequestRatio: # limits/requests 最大比例
cpu: "4"
memory: "4"
# Pod 级别限制
- type: Pod
max:
cpu: "8"
memory: "16Gi"
min:
cpu: "100m"
memory: "128Mi"
# PVC 级别限制
- type: PersistentVolumeClaim
min:
storage: "1Gi"
max:
storage: "100Gi"
4.3 查看配额使用情况
# 查看 ResourceQuota
$ kubectl describe resourcequota compute-quota -n production
Name: compute-quota
Namespace: production
Resource Used Hard
-------- ---- ----
limits.cpu 10 40
limits.memory 20Gi 80Gi
pods 25 50
requests.cpu 5 20
requests.memory 10Gi 40Gi
# 查看 LimitRange
$ kubectl describe limitrange default-limits -n production
Name: default-limits
Namespace: production
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container cpu 50m 4 100m 500m 4
Container memory 64Mi 8Gi 128Mi 512Mi 4
五、Kubelet 资源预留与驱逐
5.1 节点资源分配
┌────────────────────────────────────────────────────────────────────────┐
│ 节点资源分配模型 │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ Node Capacity (节点总容量) │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ Kube Reserved │ │ │
│ │ │ kubelet, kube-proxy 等 K8s 组件 │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ System Reserved │ │ │
│ │ │ sshd, journald, systemd 等系统进程 │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ Eviction Threshold │ │ │
│ │ │ 预留给驱逐阈值的缓冲空间 │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ Allocatable │ │ │
│ │ │ 可分配给 Pod 的资源 │ │ │
│ │ │ = Capacity - Kube Reserved - System Reserved │ │ │
│ │ │ - Eviction Threshold │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 示例计算 (16 核 64GB 节点): │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Capacity: 16 CPU, 64 Gi │ │
│ │ Kube Reserved: 0.5 CPU, 1 Gi │ │
│ │ System Reserved: 0.5 CPU, 1 Gi │ │
│ │ Eviction: - 0.5 Gi │ │
│ │ ────────────────────────────── │ │
│ │ Allocatable: 15 CPU, 61.5 Gi │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
5.2 驱逐配置
# Kubelet 配置
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
# 硬驱逐阈值 (立即驱逐)
evictionHard:
memory.available: "500Mi"
nodefs.available: "10%"
nodefs.inodesFree: "5%"
imagefs.available: "15%"
# 软驱逐阈值 (延迟驱逐)
evictionSoft:
memory.available: "1Gi"
nodefs.available: "15%"
# 软驱逐宽限期
evictionSoftGracePeriod:
memory.available: "1m30s"
nodefs.available: "2m"
# 驱逐检查间隔
evictionPressureTransitionPeriod: "5m"
# 最小回收量
evictionMinimumReclaim:
memory.available: "500Mi"
nodefs.available: "1Gi"
5.3 驱逐优先级
┌────────────────────────────────────────────────────────────────────────┐
│ Pod 驱逐优先级 │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ 驱逐顺序 (从先到后): │
│ │
│ 1. 使用资源超过 requests 最多的 BestEffort Pods │
│ ↓ │
│ 2. 使用资源超过 requests 的 Burstable Pods │
│ ↓ │
│ 3. 使用资源低于 requests 的 Burstable Pods (按使用比例) │
│ ↓ │
│ 4. Guaranteed Pods (通常不会被驱逐) │
│ │
│ 实际驱逐决策因素: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. QoS Class (BestEffort < Burstable < Guaranteed) │ │
│ │ 2. 资源使用相对于 requests 的比例 │ │
│ │ 3. Pod Priority Class │ │
│ │ 4. 运行时间 (较新的 Pod 优先驱逐) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
六、生产环境最佳实践
6.1 资源配置建议
# 生产环境 Pod 配置示例
apiVersion: v1
kind: Pod
metadata:
name: production-app
spec:
containers:
- name: app
image: myapp:1.0
resources:
requests:
# 设置合理的 requests (调度保证)
cpu: "500m" # 根据实际 P90 使用量设置
memory: "512Mi" # 根据工作集大小设置
limits:
# limits 不要设置太高，避免资源争抢
cpu: "2" # 允许短期突发
memory: "1Gi" # 设置合理上限，防止内存泄漏
# 健康检查
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
# 优雅终止
terminationGracePeriodSeconds: 60
# 反亲和性，避免单点故障
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
app: myapp
topologyKey: kubernetes.io/hostname
6.2 常见问题与解决方案
┌────────────────────────────────────────────────────────────────────────┐
│ 常见资源问题 │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ 问题 1: OOMKilled │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 原因: │ │
│ │ - 内存限制设置过低 │ │
│ │ - 内存泄漏 │ │
│ │ - Page Cache 占用 │ │
│ │ │ │
│ │ 排查: │ │
│ │ kubectl describe pod <pod> | grep -A5 "Last State" │ │
│ │ kubectl logs <pod> --previous │ │
│ │ │ │
│ │ 解决: │ │
│ │ - 增加内存 limits │ │
│ │ - 优化应用内存使用 │ │
│ │ - 设置合理的 JVM 堆大小 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 问题 2: CPU Throttling │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 原因: │ │
│ │ - CPU limits 设置过低 │ │
│ │ - 应用有突发 CPU 需求 │ │
│ │ │ │
│ │ 排查: │ │
│ │ cat /sys/fs/cgroup/cpu/.../cpu.stat | grep throttled │ │
│ │ │ │
│ │ 解决: │ │
│ │ - 增加 CPU limits │ │
│ │ - 考虑不设置 CPU limits (只设置 requests) │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 问题 3: Pending Pod │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 原因: │ │
│ │ - 节点资源不足 │ │
│ │ - requests 设置过高 │ │
│ │ - 节点亲和性/污点限制 │ │
│ │ │ │
│ │ 排查: │ │
│ │ kubectl describe pod <pod> │ │
│ │ kubectl describe node <node> │ │
│ │ │ │
│ │ 解决: │ │
│ │ - 增加节点或扩容 │ │
│ │ - 降低 requests │ │
│ │ - 检查调度约束 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
6.3 监控指标
# 关键监控指标 (Prometheus)
# 容器内存使用
container_memory_usage_bytes{container!="POD"}
container_memory_working_set_bytes{container!="POD"}
# 容器内存限制
container_spec_memory_limit_bytes
# OOM 事件
container_oom_events_total
# CPU 使用
container_cpu_usage_seconds_total
rate(container_cpu_usage_seconds_total[5m])
# CPU Throttling
container_cpu_cfs_throttled_periods_total
container_cpu_cfs_periods_total
# Throttling 比例
rate(container_cpu_cfs_throttled_periods_total[5m]) /
rate(container_cpu_cfs_periods_total[5m])
# 节点资源使用
node_memory_MemAvailable_bytes
node_cpu_seconds_total
七、面试要点
7.1 高频问题
requests 和 limits 的区别？
- requests: 调度保证，用于节点选择
- limits: 运行时强制限制，创建 Cgroup
三种 QoS 类别是什么？
- Guaranteed: requests == limits
- Burstable: requests < limits
- BestEffort: 没有设置资源
OOM 时哪个 Pod 先被杀？
- BestEffort > Burstable > Guaranteed
- 同类别看 oom_score (内存使用比例)
CPU limits 和内存 limits 的区别？
- CPU 超限: 限流 (throttling)
- 内存超限: OOM Kill
7.2 进阶问题
应该设置 CPU limits 吗？
- 争议话题
- 不设置: 可以充分利用空闲 CPU
- 设置: 避免单个 Pod 影响其他 Pod
如何计算 requests？
- 监控实际使用量的 P90/P99
- 预留一定缓冲 (如 20%)
- 考虑启动峰值
Kubelet 的 Cgroup 驱动选择？
- systemd: 推荐，与系统集成好
- cgroupfs: 较老的默认选项
相关链接
- 20-OOM-Killer机制详解 - OOM 详细分析
- 21-Cgroup内存控制深度 - 容器内存限制
- 03-CGroup资源控制 - Cgroup 基础
下一步：让我们进入 AI Infra 专题，了解 GPU 容器化和调度！