K8S性能调优 – HDUO Lab

某次线上核心交易网关出现诡异的 P99 延迟抖动。现象极其反直觉：QPS 稳在 3000 左右，容器 CPU 使用率（Prometheus container_cpu_usage_seconds_total）常年盘旋在 30% – 40%，宿主机的 Load Average 不超过 2。但在业务监控上，平时 15ms 的接口，P99 经常毫无征兆地飙升到 150ms 甚至 300ms 以上。结论先行：这是最典型的 CFS 带宽控制（Bandwidth Control）机制与多线程并发模型错配引发的惨案。不要一看到 CPU 使用率低就去查网络和 IO，在 K8s 环境下，瞎配 CPU Limit 导致的频繁 Throttling，才是杀戮 P99 延迟的隐形凶手。

案发现场：被无视的 CPU 节流

排查过程中，业务开发坚持认为是底层物理机网络抖动，因为“我的 CPU 连一半都没跑到”。我没有废话，直接登入出问题的节点，找到对应 Pod 的 cgroup 路径，拉出 CFS 的统计数据：

# 找到容器对应的 cgroup 路径并查看 cpu.stat
$ cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podxxx.slice/docker-xxx.scope/cpu.stat
nr_periods 135028
nr_throttled 48291
throttled_time 4381948291000

数据极其刺眼：nr_periods 是经过的调度周期数，nr_throttled 是被限流的周期数。近 35% 的调度周期内该容器被 CFS 强制“冻结”了！累计限流时间（throttled_time）高达几千秒。

开发人员满脸疑惑：“CPU 限额（Limit）设了 2 核，平时只用不到 1 核，凭什么限流？”

这就是很多不理解内核调度器的开发者最容易踩的坑。K8s 中的 CPU Limit 底层是通过 CFS 的 cpu.cfs_period_us 和 cpu.cfs_quota_us 来实现的。默认情况下，cfs_period_us 为 100,000 微秒（100ms）。Limit 设为 2 核，意味着 cfs_quota_us 为 200,000 微秒。重点来了：配额是按线程在 CPU 上的运行时间累加计算的。

该业务是一个 Go 写的网关程序，且没有正确设置 GOMAXPROCS。宿主机是 64 核的物理机，Go 运行时默认全量探测，启动了 64 个 P（Processor）和一堆 M（系统线程）。当一波微突发流量到达时，几十个 Goroutine 被唤醒，几十个底层线程瞬间在几十个物理核上并发执行。假设有 64 个线程同时全速运行，消耗完 200,000 微秒的 CPU 额度需要多久？ 200,000 / 64 = 3,125 微秒，也就是 3.1 毫秒。

这意味着，在每一个 100ms 的调度周期里，应用在头 3.1ms 就把双核的额度挥霍一空，接下来的 96.9ms 内，CFS 调度器会冷酷无情地将该容器的所有线程全部挂起（Throttled）。如果在挂起期间有新的网络请求到达，只能乖乖在 Socket 缓冲区里躺着，等待下一个 100ms 周期的到来。这就完美解释了为什么业务 P99 经常暴增到 100ms、200ms 以上。

在 Prometheus 中计算均值时，3.1ms 的极度繁忙和 96.9ms 的绝对静止被抹平，你看到的 CPU 使用率就是风平浪静的 30%（即 2 个核的 30%）。用宏观的平均指标去衡量微秒级的内核调度，无异于刻舟求剑。

底层机制与修复策略

这种因为微突发（Micro-burst）引发的 CFS Throttling，在多线程/协程语言（Go、Java）中极为普遍。要彻底解决这个 P99 杀手，通常有以下几条路径：

1. 校准运行时并发度（必须做） 绝对不要让容器里的应用感知到宿主机的全局 CPU 数量。对于 Go 应用，强依赖 go.uber.org/automaxprocs 库，在 init() 阶段自动解析 cgroup 的 cpu.cfs_quota_us 并正确设置 GOMAXPROCS。对于 Java 8+，确保开启 -XX:+UseContainerSupport（默认开启）。把线程池规模压制在 Limit 范围内，避免“一哄而上”导致的配额瞬时秒光。

2. 放大 CPU Limit，改用 Request 保障（推荐） 在微服务架构下，过度细粒度的 CPU Limit 往往弊大于利。对于延迟敏感型在线业务，推荐的做法是：

Request 设为真实日常峰值使用量（保证调度水位和可压缩资源底线）。
Limit 留出极大的冗余，甚至干脆不设（Limit=0）。只要你的节点层面做了足够容量规划并配合 Load 驱逐策略，让容器利用空闲 CPU 应对瞬间并发，收益远大于严格 Limit 带来的稳定假象。

3. 启用内核 CFS Burst 特性（需要较新内核） 在 Linux 5.14 及以上内核（或者部分大厂自己 Backport 的 4.14/4.19 内核中），内核引入了 CFS Burst 特性（由华为工程师贡献）。它允许容器将过去没用完的 CPU 配额“攒”起来，放到未来应对突发流量。

# 查看是否支持 burst 特性
ls /sys/fs/cgroup/cpu/cpu.cfs_burst_us

如果集群支持且 Kubelet 开启了相应 Feature Gate，利用这个特性可以极大地缓解微突发引发的节流问题。

总结

永远不要迷信“CPU 没打满就不会卡”这种浅薄经验。在 CFS 调度器眼里，时间是以微秒为单位切割的。给多线程高并发应用套上严苛的 CPU Limit，等于给一辆法拉利装上了 10 升的油箱和 100 公里的限速器。

故障现场：消失的 Reconcile

排查过程中接到研发反馈，某集群（K8S 1.28）中的核心 Operator 在平稳运行一段时间后，新建的 Custom Resource (CR) 状态迟迟无法流转。检查 Pod 状态，CPU 和内存水位均在 20% 以下，Goroutine 数量稳定，没有出现常见的 OOM 或死锁。查看 Operator 日志，没有看到任何 Panic，仅仅是偶尔打印几条调用外部云平台 API 超时的 error 日志。

但拉出 Prometheus 监控一看，暴露出致命问题：

workqueue_depth（队列深度）处于极低水平（趋近于0）。
但 workqueue_queue_duration_seconds_bucket 的 P99 延迟高达 800 秒以上。
workqueue_retries_total 呈现缓慢上涨趋势。

这是一种典型的“队列逻辑阻塞”现象。Goroutine 没死，Informer 还在正常 Watch，但任务被死死卡在了 client-go 的延迟队列（DelayingQueue）里。

为什么默认 RateLimiter 会导致 Reconcile 假死？

在基于 controller-runtime（以 v0.16.3 为例）开发的 Operator 中，Reconcile 循环是业务逻辑的核心。开发者最常写的错误代码如下：

func (r *MyReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // 1. 获取 CR
    // 2. 调用外部依赖（例如某云厂商的 SLB API）
    err := r.callExternalAPI()
    if err != nil {
        // 🚨 灾难的开始：无脑返回 error
        return ctrl.Result{}, err 
    }
    return ctrl.Result{}, nil
}

当 Reconcile 返回 error 不为 nil 时，controller-runtime 的 worker 会调用 workqueue.AddRateLimited(item) 将该对象的 key 重新塞回队列。

那么，它多久会被重新处理？这就引出了底层 client-go 的默认限速器实现。controller-runtime 默认使用的 RateLimiter 是 workqueue.DefaultControllerRateLimiter()，其底层包含两个限速器：

// 截取自 client-go/util/workqueue/default_rate_limiters.go
func DefaultControllerRateLimiter() RateLimiter {
    return NewMaxOfRateLimiter(
        NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
        // 10 qps, 100 bucket size
        &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
    )
}

注意看 NewItemExponentialFailureRateLimiter 的参数：基础延迟 5ms，最大延迟 1000s（约 16.6 分钟）。如果你的外部 API 发生短暂的网络抖动或限流，导致连续报错：

第 1 次重试：5ms
第 5 次重试：80ms
第 10 次重试：2.56s
第 15 次重试：81s
第 18 次重试及以后：直接封顶 1000s

一旦达到 1000s，哪怕此时外部 API 已经恢复正常，你的 Operator 依然需要干等十多分钟才会再次调谐这个 CR。在用户视角看来，就是 Operator 彻底“假死”了。

Informer 的 Resync 机制能救场吗？

有人可能会想：Informer 不是有 Resync 机制吗？定期强制同步能不能打破这个僵局？

答案是：不能。

理解这个结论需要吃透 Informer 与 Workqueue 的联动机制：

Resync 的本质，是 Informer 将本地 Indexer（缓存）中的全量对象，重新放入 DeltaFIFO 队列中，打上 Sync 类型的标签。
EventHandler 监听到 Sync 事件后，会将其转换为 Reconcile 请求放入 Workqueue。
但是，Workqueue 的排重机制（Deduplication）规定：如果一个 Key 已经在 dirty 集合中（比如它正处于 RateLimiter 的延迟队列里倒计时），新的入队请求会被忽略或合并。

换句话说，只要你的 CR 还在 1000s 的退避惩罚期内，即使 Informer 触发了 Resync，也无法强制它提前执行。更何况，controller-runtime 默认的 Resync 周期是 10 小时。

防御性编程：重写限速器与重试逻辑

要根治这个问题，必须从两个层面下手：替换默认 RateLimiter 和精细化处理 Reconcile 返回值。

1. 替换控制器的默认 RateLimiter

在 SetupWithManager 时，注入自定义的 RateLimiter，将最大退避时间限制在业务可接受的范围内（例如最大 30 秒）。

import (
    "golang.org/x/time/rate"
    "k8s.io/client-go/util/workqueue"
    ctrl "sigs.k8s.io/controller-runtime"
    "sigs.k8s.io/controller-runtime/pkg/controller"
    "time"
)

func (r *MyReconciler) SetupWithManager(mgr ctrl.Manager) error {
    // 自定义限速器：基础延迟 100ms，最大延迟 30s
    customRateLimiter := workqueue.NewMaxOfRateLimiter(
        workqueue.NewItemExponentialFailureRateLimiter(100*time.Millisecond, 30*time.Second),
        &workqueue.BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
    )

    return ctrl.NewControllerManagedBy(mgr).
        For(&appv1.MyCRD{}).
        WithOptions(controller.Options{
            RateLimiter: customRateLimiter, // 替换默认限速器
            MaxConcurrentReconciles: 5,     // 提升并发度
        }).
        Complete(r)
}

2. 精细化 Reconcile 的返回值设计

绝对不要一遇到错误就 return ctrl.Result{}, err。应当区分 系统级错误 与 预期内重试：

func (r *MyReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // ... 获取对象 ...

    err := r.callExternalAPI()
    if err != nil {
        if errors.Is(err, ErrTransientNetwork) || errors.Is(err, ErrAPILimit) {
            // 预期内的瞬态错误，不要返回 error 触发退避惩罚！
            // 使用 RequeueAfter 指定固定延迟重试
            log.Info("外部接口限流，5秒后重试")
            return ctrl.Result{RequeueAfter: 5 * time.Second}, nil
        }

        // 真正的致命错误（如 RBAC 权限不足、CRD 结构损坏），才返回 err
        return ctrl.Result{}, err
    }

    return ctrl.Result{}, nil
}

通过返回 ctrl.Result{RequeueAfter: 5 * time.Second}, nil，controller-runtime 会直接将该 Key 丢进延迟队列，5秒后准时出队，完全绕过 RateLimiter 的指数退避计数器。

常见问题 (FAQ)

Q1：`Reconcile` 中返回 `error` 和返回 `Requeue: true` 有什么本质区别？

返回 error != nil 会触发 RateLimiter 的计数器加 1，下一次重试时间呈指数级增长；而返回 ctrl.Result{Requeue: true}, nil 不会增加限速器的错误计数，它等同于被 RateLimiter 视为一次“成功”的处理，随后立即重新入队（仅受 BucketRateLimiter 的令牌桶限制），如果滥用极易造成 CPU 飙升。

Q2：如何通过 Prometheus 准确监控 Operator 的队列健康度？

强烈建议收集并配置以下告警规则（以 kube-state-metrics 或 controller-runtime 默认 metrics 接口为准）：

workqueue_depth{name=""} > 100 持续 5 分钟（判断队列积压）。
rate(workqueue_adds_total[5m]) 与 rate(workqueue_work_duration_seconds_count[5m]) 出现明显剪刀差（判断处理跟不上生产）。
workqueue_longest_running_processor_seconds > 60s （判断是否存在死锁或超长阻塞的单次 Reconcile）。

Q3：修改了 CRD 对象，但 Operator 迟迟没收到 Update 事件？

这种情况多半与 Informer 的机制无关，需排查是否被 Webhook 拦截，或者由于 API Server 负载过高导致 Watch 连接断开正在执行 Relist。如果 workqueue_depth 毫无波澜，说明事件根本没进队列，排查重点应转向 RBAC 权限（是否拥有 watch/list 权限）或 APIServer 的 audit log。

标签： K8S性能调优

深入 CFS 带宽控制陷阱排查：cfs_quota_us 截断引发的无故 Throttling 与容器 P99 抖动实战