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 -n 观察；为团队设定对象数量上限，避免无节制创建 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 的连锁反应。

以上就是关于“Kubernetes在Linux上的资源管理技巧”的相关介绍，筋斗云是国内较早的云主机应用的服务商，拥有10余年行业经验，提供丰富的云服务器、租用服务器等相关产品服务。云服务器资源弹性伸缩，主机vCPU、内存性能强悍、超高I/O速度、故障秒级恢复；电子化备案，提交快速，专业团队7×24小时服务支持！

简单好用、高性价比云服务器租用链接：https://www.jindouyun.cn/product/cvm