告别盲人摸象：用 eBPF 给 Kubernetes 集群做精细体检

作为一名 Kubernetes 运维老兵，你是不是经常遇到这样的困境？

• 容器 CPU 飙升，但 top 命令看过去，进程 CPU 使用率并不高，那 CPU 到底被谁吃掉了？
• 应用明明申请了 8G 内存，但总是 OOM，难道是内存泄漏了？可是用什么工具来定位泄漏点呢？
• Pod 间歇性抖动，是不是网络出了问题？用 tcpdump 抓包，数据量太大，根本没法分析。

这些问题是不是让你头大？传统的监控手段，例如 Prometheus，只能提供宏观的指标，对于这些疑难杂症，往往束手无策。难道我们就只能靠玄学来解决问题了吗？

当然不！今天，我就要向你介绍一种强大的武器：eBPF。它可以让你深入 Kubernetes 集群的内核，像医生一样，为你的集群做一次彻底的体检，揪出那些隐藏的性能瓶颈。

什么是 eBPF？

eBPF，全称是 extended Berkeley Packet Filter，最初是为网络数据包过滤而设计的。但后来，它被扩展到可以监控和跟踪内核中的各种事件。你可以把它想象成一个内核级别的“探针”，可以hook到内核的各种函数调用上，收集各种性能数据。

为什么 eBPF 如此强大？

• 高性能： eBPF 程序运行在内核态，避免了用户态和内核态之间频繁的切换，性能损耗极低。
• 安全： eBPF 程序在运行前会经过内核的验证，确保不会破坏系统的稳定性。
• 灵活： 你可以使用 C、Go 等语言编写 eBPF 程序，然后编译成字节码，加载到内核中运行。

eBPF 如何监控 Kubernetes 集群？

Kubernetes 本质上还是运行在 Linux 内核之上的，所以我们可以利用 eBPF 监控 Kubernetes 集群的各种资源使用情况。

1. CPU 使用率监控

传统的 top 命令只能看到进程级别的 CPU 使用率，但 eBPF 可以深入到内核函数，例如 schedule() 函数，它可以跟踪每个线程的运行时间，从而精确地知道 CPU 被谁占用。你可以利用 eBPF 跟踪以下信息：

• 哪个 Pod 的 CPU 使用率最高？
• 哪个 Container 的 CPU 使用率最高？
• 哪个线程的 CPU 使用率最高？
• CPU 都被用在哪些内核函数上？

通过这些信息，你可以快速定位 CPU 瓶颈，例如，发现某个 Pod 频繁调用某个内核函数，导致 CPU 使用率飙升。然后，你可以进一步分析这个 Pod 的代码，找出优化的方向。

案例：排查 CPU 占用率高的“凶手”

线上一个服务的 CPU 占用率持续偏高，通过 Prometheus 监控发现，所有 Pod 的 CPU 使用率都比较高，但具体哪个 Pod 占用最高，以及 Pod 内部哪个进程占用最高，无法得知。

使用 eBPF 工具，可以观测到每个 PID 对应的 CPU 耗时，从而快速锁定 CPU 占用率最高的 Pod 和进程。

# bpf_pidusage -d 1 -p $(pidof your_service)
PID   COMM             CPU(%) utime[s] stime[s]  rtime[s]  pages[MB]
1234  your_service       95.0   10.5      0.1        10.6       123

2. 内存使用率监控

内存泄漏是 Kubernetes 应用常见的 Bug 之一。传统的内存监控工具，例如 top、free 等，只能看到总体的内存使用情况，无法定位到具体的泄漏点。eBPF 可以 hook 到内存分配和释放函数，例如 kmalloc()、kfree() 等，跟踪内存的分配和释放情况。你可以利用 eBPF 跟踪以下信息：

• 哪个 Pod 的内存使用量最高？
• 哪个 Container 的内存使用量最高？
• 哪个线程分配的内存最多？
• 内存都分配在哪些内核函数上？

通过这些信息，你可以快速定位内存泄漏点，例如，发现某个 Pod 频繁分配内存，但很少释放，导致内存使用量持续增长。然后，你可以进一步分析这个 Pod 的代码，找出内存泄漏的原因。

案例：揪出内存泄漏的“真凶”

某个 Java 应用频繁发生 OOM，通过 jmap 分析 Heap Dump 发现，大量的对象无法被回收，怀疑存在内存泄漏。但是，jmap 只能看到 Java 堆内的对象，无法看到堆外的内存使用情况。

使用 eBPF 工具，可以监控 kmalloc() 和 kfree() 函数，跟踪内存的分配和释放情况，从而发现泄漏点。

# ebpf_funclatency -f kmalloc -T
Tracing 'kmalloc'... Hit Ctrl-C to end.
^C
func             count     avg latency (us)   min latency (us)   max latency (us)   total [ms]
kmalloc          12345     12.3             1                  100                15.2

3. 磁盘 I/O 监控

磁盘 I/O 瓶颈也会影响 Kubernetes 应用的性能。传统的 I/O 监控工具，例如 iostat、iotop 等，只能看到总体的 I/O 使用情况，无法定位到具体的 I/O 来源。eBPF 可以 hook 到磁盘 I/O 函数，例如 read()、write() 等，跟踪 I/O 的读写情况。你可以利用 eBPF 跟踪以下信息：

• 哪个 Pod 的 I/O 读写量最高？
• 哪个 Container 的 I/O 读写量最高？
• 哪个线程的 I/O 读写量最高？
• I/O 都读写了哪些文件？

通过这些信息，你可以快速定位 I/O 瓶颈，例如，发现某个 Pod 频繁读写某个文件，导致 I/O 使用率飙升。然后，你可以进一步分析这个 Pod 的代码，找出 I/O 优化的方向。

案例：定位频繁读写磁盘的罪魁祸首

数据库服务器的磁盘 I/O 占用率持续偏高，导致数据库性能下降。使用 iotop 命令发现，是某个 MySQL 进程在频繁读写磁盘，但是，具体读写哪些文件，无法得知。

使用 eBPF 工具，可以监控 read() 和 write() 函数，跟踪 I/O 的读写情况，从而定位到频繁读写磁盘的文件。

# funccount 'p:vfs_read filename=%ax' -c 10
FUNC             COUNT
vfs_read         12345

4. 网络监控

网络问题是 Kubernetes 集群中最常见的问题之一。传统的网络监控工具，例如 tcpdump、wireshark 等，只能捕获网络数据包，但无法深入到内核协议栈，了解网络数据包的处理过程。eBPF 可以 hook 到网络协议栈的各个函数，例如 tcp_recvmsg()、tcp_sendmsg() 等，跟踪网络数据包的收发过程。你可以利用 eBPF 跟踪以下信息：

• 哪个 Pod 的网络流量最高？
• 哪个 Container 的网络流量最高？
• TCP 连接的延迟是多少？
• 网络数据包都经过了哪些内核函数？

通过这些信息，你可以快速定位网络问题，例如，发现某个 Pod 频繁发送大量数据包，导致网络拥塞。然后，你可以进一步分析这个 Pod 的代码，找出网络优化的方向。

案例：分析 TCP 连接延迟高的原因

某个服务的 TCP 连接延迟持续偏高，导致用户体验下降。使用 ping 命令发现，网络延迟并不高，怀疑是服务内部处理 TCP 连接的耗时过长。

使用 eBPF 工具，可以监控 tcp_recvmsg() 和 tcp_sendmsg() 函数，跟踪 TCP 数据包的收发过程，从而定位到耗时过长的环节。

# tcplife
PID   COMM       LADDR           LPORT RADDR           RPORT TX_KB RX_KB MS
1234  your_service 10.0.0.1        8080  10.0.0.2        12345 10    5     123

eBPF 工具推荐

• bcc: 一个用于创建 eBPF 程序的 Python 库，提供了丰富的工具和示例。
• bpftrace: 一种高级的 eBPF 跟踪语言，可以让你用简单的命令来监控内核事件。
• cilium: 一个基于 eBPF 的 Kubernetes 网络解决方案，提供了强大的网络策略和监控功能。
• falco: 一个基于 eBPF 的安全工具，可以监控 Kubernetes 集群的运行时行为，及时发现安全威胁。

总结

eBPF 是一种强大的技术，可以让你深入 Kubernetes 集群的内核，监控各种资源使用情况，定位性能瓶颈和安全问题。掌握 eBPF，你就可以像医生一样，为你的集群做一次彻底的体检，保障集群的稳定性和性能。

当然，学习 eBPF 也是有一定门槛的，需要你具备一定的 Linux 内核知识和编程能力。但只要你肯花时间学习，相信你一定可以掌握这项技术，成为一名 Kubernetes 运维专家。

希望这篇文章能够帮助你了解 eBPF，并开始尝试使用它来监控 Kubernetes 集群。如果你在学习过程中遇到任何问题，欢迎在评论区留言，我会尽力解答。让我们一起拥抱 eBPF，告别盲人摸象的时代！