1. 课程导论：K8s环境下Go服务慢查询的典型场景与挑战

1.1 为什么K8s+Go组合会放大慢查询问题？

Kubernetes 与 Go 的组合已成为云原生微服务的事实标准，但这一组合在带来弹性与并发优势的同时，也引入了独特的慢查询定位难题。传统单机或虚拟机环境下的排查手段（如 pprof 本地分析、单一日志文件 grep）在 K8s 的动态拓扑中往往失效。

慢查询在 K8s 环境下的放大效应主要来自三个层面：

• 网络层：Service Mesh、CNI 插件、DNS 解析、Ingress 网关等中间件增加了额外的网络跳数和延迟抖动。
• 资源层：Pod 的 CPU 限流（CFS Quota）、内存限制、磁盘 IOPS 节流、网络带宽限制会直接导致 Go 运行时调度延迟和 GC 停顿。
• 调度层：Pod 频繁重启、节点资源争抢、NUMA 亲和性丢失、拓扑感知调度失效等场景，使得慢查询的根因从应用代码扩散到基础设施。

1.2 典型慢查询场景清单

根据生产环境故障复盘，以下 6 类场景占据了 K8s+Go 慢查询问题的 80% 以上：

1.3 核心挑战：从“黑盒”到“可观测”

在 K8s 环境下定位 Go 服务慢查询，面临以下四个核心挑战：

1. 拓扑动态性：Pod IP 频繁变化，传统 IP 维度的监控工具失效，必须依赖 Service 名称、Pod 标签、Trace ID 进行关联。
2. 观测数据碎片化：Metrics（Prometheus）、Tracing（OpenTelemetry）、Logging（Loki/ELK）三套数据源各自独立，缺乏统一的关联分析入口。
3. Go 运行时特殊性：Go 的 goroutine 调度、GC 触发、MPG 模型与 CFS 限流之间存在复杂的非线性交互，常规 CPU 利用率指标无法反映真实瓶颈。
4. 资源调整的副作用：盲目增加 CPU Request/Limit 可能触发节点过载，调整 Go GC 参数可能引发 STW 时间波动，资源调整策略需要闭环验证。

1.4 慢查询定位与资源调整的全景流程

下图展示了本课程的核心方法论：从告警触发到根因定位，再到资源调整与效果验证的闭环流程。

1.5 课程目标与学习路径

本课程旨在帮助学员建立一套可复用的 K8s+Go 慢查询定位与资源调整方法论。完成本课程后，你将能够：

• 独立搭建 K8s 环境下的全栈可观测性栈（Metrics + Tracing + Logging）。
• 熟练使用 Go pprof、trace、pprof 火焰图进行在线与离线性能分析。
• 掌握 K8s CPU Throttling、Memory OOM、网络延迟的根因定位技术。
• 制定基于实际负载特征的 Go 服务资源 Request/Limit 配置策略。
• 通过 HPA、VPA、Cluster Autoscaler 实现资源调整的自动化闭环。

1.6 课程章节地图

课程共 30 章，分为 5 个模块，建议按顺序学习：