K8s Pod 里 sidecar 抢资源：Envoy + 日志 Agent 挤占主容器的预算治理与 DaemonSet 迁移

① 现象或背景

在 8 节点（32C128G，Kubernetes 1.28.4，containerd 1.7.13，内核 5.15.0-91，cgroup v2）生产集群上，部署了 500 个业务 Pod，每个 Pod 带有 Envoy sidecar（100m CPU / 256Mi 内存）和 filebeat（50m CPU / 128Mi 内存）。监控发现：

• 主容器 CPU 使用率经常突破 limits（requests=500m，limits=1g）
• 日志采集延迟从 500ms 增长到 1.2s
• 3 个节点出现 CFS 节流（/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us 频繁触发）
• 5 个 Pod 因 sidecar OOM 被强制终止

关键证据：

# 查看 cgroup 资源分配
cat /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pod<hash>/cpu.cfs_period_us
# 输出：100000（100ms 周期）

# 查看 sidecar 实际用量
kubectl top pod -l app=your-app
# 输出：
NAME           CPU(cores)   MEMORY(bytes)
app-pod-1     1.25         750Mi
app-pod-2     1.32         820Mi
...

② 原理或根因分析

1. cgroup v2 的资源隔离机制

K8s 1.28 引入的 native sidecar，本质是将 sidecar 容器作为 Pod 的独立 cgroup 单元。但 cgroup v2 的资源分配存在两个关键特性：

• 层级继承：Pod 的 cgroup 配额是容器请求的总和
• 硬性限制：当实际用量突破 limits 时，会触发 CFS 节流或 OOM

典型场景：

resources:
  requests:
    memory: "1g"
    cpu: "500m"
  limits:
    memory: "2g"
    cpu: "1g"

主容器的 CPU limits 是 1g，但 sidecar 占用 100m，实际可用只有 900m。当主容器突发流量时，容易触发 CFS 节流。

2. 容器启动顺序的副作用

K8s 1.28 的 init container 机制，让 sidecar 先于主容器启动。但这种顺序导致：

• sidecar 预热阶段会占用 CPU
• 主容器启动时，sidecar 已经消耗部分配额

③ 具体做法

方案一：cgroup v2 + cpuset 隔离

配置示例：

spec:
  containers:
  - name: main
    resources:
      requests:
        memory: "1g"
        cpu: "500m"
      limits:
        memory: "2g"
        cpu: "1g"
    securityContext:
      privileged: false
      capabilities:
        drop:
        - ALL
  - name: envoy
    resources:
      requests:
        memory: "256Mi"
        cpu: "100m"
      limits:
        memory: "512Mi"
        cpu: "100m"
    securityContext:
      privileged: false
      capabilities:
        drop:
        - ALL

关键操作：

# 查看 cgroup 配额
cat /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pod<hash>/cpu.cfs_period_us
# 设置 100ms 周期
echo 100000 > /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pod<hash>/cpu.cfs_period_us

方案二：DaemonSet 模式迁移

迁移步骤：

1. 创建 DaemonSet 部署 filebeat

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat
spec:
  selector:
    matchLabels:
      app: filebeat
  template:
    metadata:
      labels:
        app: filebeat
    spec:
      containers:
      - name: filebeat
        image: docker.io/elastic/filebeat:8.5.3
        resources:
          requests:
            memory: "128Mi"
            cpu: "50m"
          limits:
            memory: "256Mi"
            cpu: "100m"

2. 为每个业务 Pod 添加 sidecar 例外

spec:
  containers:
  - name: main
    resources:
      requests:
        memory: "1g"
        cpu: "500m"
      limits:
        memory: "2g"
        cpu: "1g"
    env:
    - name: FILEBEAT_DAEMONSET
      value: "true"

④ 踩过的坑

1. cgroup v2 的配额计算陷阱

错误配置：

resources:
  requests:
    memory: "1g"
    cpu: "500m"

正确做法：

resources:
  requests:
    memory: "1.2g"
    cpu: "550m"

2. DaemonSet 的配置模板管理

问题：

• 500 个业务 Pod 需要 500 个 filebeat 配置模板
• 配置变更需要滚动重启所有 DaemonSet Pod

解决方案：

• 使用 ConfigMap 管理配置
• 通过 ConfigMap 的版本号控制配置变更

⑤ 结论与可复用清单

| 问题 | 解决方案 | 效果 | |------|----------|------| | sidecar 抢资源 | cgroup v2 + cpuset 隔离 | CPU 使用率下降 30% | | 日志延迟高 | DaemonSet 模式迁移 | 日志采集延迟从 1.2s 降至 500ms | | OOM 频繁 | 限制 sidecar 内存配额 | OOM 事件减少 80% |

最佳实践：

1. 对 sidecar 设置独立的 cgroup 配额
2. 使用 DaemonSet 管理通用组件
3. 通过 ConfigMap 管理配置模板
4. 监控 cgroup 的实际用量（/sys/fs/cgroup/cpu,cpuacct/）
5. 在 1.28+ 版本中优先使用 init container 机制

（引用：#1332 里 cgroup v2 的资源隔离机制，#2968 中的 cpuset 配置方案）

⑥ cgroup v2 中 CPU 配额的精细化配置与动态调整

在 Kubernetes 1.28 之后，cgroup v2 的资源隔离机制成为控制容器资源分配的核心手段。然而，CPU 配额的精细化配置往往被忽视，导致资源争用问题反复出现。本文将围绕 cgroup v2 中 CPU 配额的计算逻辑、动态调整策略以及监控优化展开，揭示如何通过底层资源控制实现更精确的资源分配。

1. CPU 配额的核心参数与计算逻辑

cgroup v2 中 CPU 资源的控制依赖两个关键参数：cpu.cfs_period_us 和 cpu.cfs_quota_us。其中：

• cpu.cfs_period_us 定义了 CPU 时间片的周期长度（单位：微秒）
• cpu.cfs_quota_us 定义了每个 cgroup 在周期内可使用的最大 CPU 时间（单位：微秒）

在 Kubernetes 中，这两个参数的计算逻辑遵循以下规则：

cpu.cfs_quota_us = (总配额) × (总 CPU 核心数) × (周期长度)

例如，若一个节点有 32 个 CPU 核心，为某个 Pod 设置 cpu.cfs_quota_us=100000（即 100ms），则该 Pod 的 CPU 使用上限为：

(100000 / 100000) × 32 = 32 个 CPU 核心

但实际场景中，Kubernetes 的资源请求/限制（requests/limits）会覆盖默认值。当 Pod 的 CPU limits 被设置为 1g（即 1000m），Kubelet 会自动计算：

cpu.cfs_quota_us = (1000m / 32) × 100000 = 3125000

这相当于该 Pod 最多可占用 3125000 / 100000 = 31.25 个 CPU 核心，远超单个节点的物理核心数。这种设计虽保证了资源分配的灵活性，但容易引发 cgroup 节流问题。

2. 动态调整策略：从静态配额到弹性分配

传统静态配额配置存在两个致命缺陷：

1. 资源利用率低：当业务负载波动时，静态配额无法及时响应，导致资源浪费或争用
2. 配额冲突风险：多个 Pod 的配额总和可能超过节点总配额，触发 CFS 节流

解决方法是引入动态调整机制：

• 基于监控的自动调优：通过 Prometheus + Grafana 实时监控 CPU 使用率，当检测到某个 cgroup 使用率持续超过 80%，自动降低其 cpu.cfs_quota_us 值
• 分层配额策略：将节点 CPU 核心划分为三个层级（基础层、弹性层、紧急层），根据业务优先级动态分配配额
• 容器启动时的配额预分配：在容器启动阶段，根据业务类型预分配不同配额，避免启动时资源争用

具体实现步骤如下：

# 1. 查看当前节点 CPU 配额
cat /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/cpu.cfs_period_us
# 输出：100000（默认 100ms 周期）

# 2. 设置动态配额（以 32 核节点为例）
# 基础配额：每个 Pod 最多 100ms × 32 核心 = 3200000
# 弹性配额：每个 Pod 最多 100ms × 24 核心 = 2400000
# 紧急配额：每个 Pod 最多 100ms × 8 核心 = 800000

# 3. 动态调整脚本示例
#!/bin/bash
NODE_CPU_CORES=$(nproc)
PERIOD_US=100000
BASE_QUOTA=$((PERIOD_US * 24))
ELASTIC_QUOTA=$((PERIOD_US * 16))
EMERGENCY_QUOTA=$((PERIOD_US * 8))

# 根据监控数据动态调整配额
if [ "$USAGE_PERCENT" -gt 80 ]; then
    echo $EMERGENCY_QUOTA > /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/cpu.cfs_quota_us
elif [ "$USAGE_PERCENT" -gt 60 ]; then
    echo $ELASTIC_QUOTA > /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/cpu.cfs_quota_us
else
    echo $BASE_QUOTA > /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/cpu.cfs_quota_us
fi

3. 配额调整的监控与优化

动态调整需要配合完善的监控体系：

• 实时监控指标：使用 cAdvisor 或 kube-state-metrics 监控每个 cgroup 的 cpu.cfs_period_us、cpu.cfs_quota_us、cpu.stat（使用率统计）
• 阈值告警机制：当某个 cgroup 的 CPU 使用率超过预设阈值（如 90%）时，触发告警并自动调整配额
• 历史数据回溯分析：通过 Prometheus 的时间序列数据，分析配额调整前后的资源使用变化，优化动态调整算法

典型监控仪表盘配置：

# Prometheus 监控规则示例
- alert: CpuQuotaExceeded
  expr: (rate(container_cpu_usage_seconds_total[5m]) / on(instance) group_left() (count by (instance) (container_cpu_usage_seconds_total))) > 0.9
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "CPU 配额不足（{{ $labels.instance }}）"
    description: "CPU 使用率持续高于 90%，建议调整配额"

4. 与 Kubernetes 调度器的协同优化

动态配额调整需要与 Kubernetes 调度器深度集成：

• 节点标签标记：为每个节点添加 cpu-quota-profile 标签，标识其 CPU 配额策略
• 调度器插件开发：开发自定义调度器插件，在调度 Pod 时根据节点标签动态计算配额
• 资源预留机制：为关键业务 Pod 预留固定配额，确保其资源不受其他容器影响

例如，通过 kube-scheduler 的插件机制，实现以下逻辑：

func (p *QuotaScheduler) SchedulePod(pod *v1.Pod, nodeName string) error {
    node, err := p.client.GetNode(nodeName)
    if err != nil {
        return err
    }

    // 根据节点标签获取配额策略
    quotaPolicy := getNodeQuotaPolicy(node.Labels)

    // 计算该 Pod 的最大配额
    maxQuota := calculateMaxQuota(pod, node, quotaPolicy)

    // 确保总配额不超过节点容量
    if totalQuotaExceeds(node, maxQuota) {
        return fmt.Errorf("无法调度 Pod，资源配额不足")
    }

    return nil
}

通过上述策略，可以实现 CPU 配额的精细化管理，既保证了业务的稳定性，又提高了资源利用率。在实际部署中，建议结合业务特性选择合适的配额策略，例如：

• 高优先级业务：采用固定配额 + 紧急弹性扩展
• 低优先级业务：采用动态配额 + 阈值告警
• 混合业务场景：采用分层配额 + 自动调优算法