Kubernetes在Linux上的资源管理技巧 - 问答

Kubernetes 在 Linux 上的资源管理技巧

一核心机制与 Linux 内核关系

为容器设置 requests 与 limits 是最基础且必须掌握的能力：requests 用于调度器选择节点，limits 由 kubelet + cgroups + 内核 强制执行。CPU 超限会被内核通过 CPU 节流限制；内存超限会触发 OOM Killer 终止容器。若只设置 limits 而未设置 requests，且集群无准入默认，Kubernetes 会将 limits 的值同时作为 requests。Linux 节点上可通过 cgroups 观察与验证资源约束是否生效。另需注意 hugepages-* 资源不可超售，这与 memory/cpu 不同。

二 Pod 与容器资源配置要点

为每个容器显式声明 resources.requests 与 resources.limits，避免“未设置即无约束”的风险；对 CPU 与内存使用不同单位与后缀：CPU 用毫核（m），内存用 Mi/Gi。示例：

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
  - name: app
    image: nginx:1.25
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"

理解 QoS 分类 对稳定性的影响：
- Guaranteed（requests == limits）：关键业务优先保障；
- Burstable（requests < limits）：允许突发，适合多数在线服务；
- BestEffort（未设置）：低优先级，不建议生产使用。
特殊资源与调度：如需 GPU，在容器中请求如 nvidia.com/gpu: 1，并通过节点标签与 nodeSelector 将 Pod 调度到具备相应 GPU 的节点。示例：

spec:
  containers:
  - name: gpu-app
    image: nvidia/cuda:12.2-base
    resources:
      requests:
        nvidia.com/gpu: "1"
      limits:
        nvidia.com/gpu: "1"
  nodeSelector:
    nvidia.com/gpu.product: nvidia-a100

避免常见误区：仅设 limits 导致 requests 被动等于 limits；内存过小易 OOMKilled；CPU 过小导致长期节流影响延迟。

三命名空间与多租户边界

使用 ResourceQuota 限制命名空间的总量边界（CPU/Memory 的 requests 与 limits、以及对象数量如 Pods、Services、PVCs、Secrets、ConfigMaps 等），防止团队/环境之间资源争抢。示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

使用 LimitRange 为“未显式配置”的容器设置默认值与边界（default、defaultRequest、min、max），统一规范与防止滥用。示例：

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: dev
spec:
  limits:
  - type: Container
    default:
      requests.cpu: "200m"
      requests.memory: "128Mi"
    defaultRequest:
      requests.cpu: "100m"
      requests.memory: "64Mi"
    max:
      requests.cpu: "1"
      requests.memory: "512Mi"
    min:
      requests.cpu: "50m"
      requests.memory: "32Mi"

运营要点：创建命名空间后尽快绑定配额与限制范围；配额使用量可用 kubectl describe resourcequota <name> -n <ns> 观察；为团队设定对象数量上限，避免无节制创建 ConfigMap/Secret/PVC 等。

四调度与拓扑感知优化

基础调度：用 nodeSelector 定向到特定节点；用 nodeAffinity / podAffinity / podAntiAffinity 表达更复杂的调度策略（如关键服务分散在不同节点/机架）。
拓扑与性能：启用 CPU Manager 做 NUMA 拓扑感知分配，减少跨 NUMA 访问带来的性能抖动；结合 podTopologySpread 插件均衡分布关键服务的副本，提升可用性与资源利用。
动态资源：关注 DRA（Dynamic Resource Allocation） 等演进能力，用于在运行时更灵活地分配设备类资源（如加速器），提升集群利用率与调度弹性。

五监控自动伸缩与节点级保障

可观测性：部署 Metrics Server 后，用 kubectl top nodes/pods 快速查看资源使用；结合 Prometheus + Grafana 搭建可视化与告警，定位 CPU 节流、内存压力、OOMKilled 等根因。
弹性扩缩：基于 CPU/内存或自定义指标使用 HPA 自动扩缩副本数；对“长期低估/高估”的 workloads，结合 VPA 调整 requests/limits；在云环境配合 Cluster Autoscaler 自动增减节点，提升整体资源效率与成本效益。
节点稳定性：为系统组件与内核预留资源，避免与业务争抢。示例 kubelet 参数：
- --system-reserved=cpu=500m,memory=1Gi
- --kube-reserved=cpu=200m,memory=512Mi
Java 应用提示：为 JVM 堆预留与容器 limits 的“安全余量”，并结合监控与 HPA/VPA 持续校准 requests/limits，避免 Full GC 与 OOM 的连锁反应。

0 赞

0 踩