冠军资讯
键盘上的咸鱼在云原生架构中，可观测性至关重要。服务网格 Istio 作为云原生应用流量管理的事实标准，在服务治理方面表现出色。然而，Istio 并非完美，尤其是在性能开销、侵入性和可观测性深度方面存在一些局限性。这时，eBPF (extended Berkeley Packet Filter) 作为一种革命性的内核技术，开始崭露头角，为我们提供了更强大的可观测性能力。本文将从对比 eBPF 和 Istio 开始，深入探讨 eBPF 的原理、应用以及在云原生环境中的价值。
Istio 的可观测性：Proxy 的视角
Istio 通过在每个 Pod 中注入 Sidecar Proxy（通常是 Envoy）来拦截所有流量。这些 Proxy 负责收集指标、日志和 Traces，从而提供服务之间的调用关系、性能瓶颈等信息。Istio 的可观测性主要依赖于以下几个方面：
- Metrics: Envoy Proxy 会暴露大量的性能指标，例如请求延迟、错误率、流量等。这些指标可以被 Prometheus 等监控系统收集和分析。
- Logs: Envoy Proxy 可以记录每个请求的详细日志，包括请求头、请求体、响应头、响应体等。这些日志可以被 Elasticsearch 等日志系统收集和分析。
- Traces: Istio 支持分布式追踪，可以将一个请求在多个服务之间的调用链完整地记录下来。通过 Jaeger 或 Zipkin 等追踪系统，我们可以可视化请求的调用路径和延迟分布。
尽管 Istio 的可观测性功能强大，但也存在一些问题：
- 性能开销： Sidecar Proxy 会增加额外的网络跳数和 CPU 开销，尤其是在高并发场景下，对性能的影响不可忽视。
- 侵入性： 需要修改应用部署配置，注入 Sidecar Proxy，增加了运维的复杂性。
- 可观测性深度： Envoy Proxy 只能观测到应用层面的信息，无法深入到内核层面，例如 TCP 连接状态、内核函数调用等。
案例： Istio 服务网格中， sidecar 带来的延迟增加
一个典型的场景是，在高并发的电商系统中，我们使用了 Istio 来管理服务之间的流量。然而，随着流量的增加，我们发现服务的响应延迟也随之增加。通过分析 Istio 的监控指标，我们发现 Sidecar Proxy 的 CPU 使用率很高，成为了性能瓶颈。虽然可以通过调整 Envoy Proxy 的配置来优化性能，但这需要深入了解 Envoy 的工作原理，并进行大量的测试。
eBPF 的可观测性：内核的视角
eBPF 是一种可以在 Linux 内核中安全运行用户自定义代码的技术。它允许我们在内核层面观测和分析系统行为，而无需修改内核代码或重新编译内核。eBPF 的可观测性优势在于：
- 高性能： eBPF 程序运行在内核中，可以直接访问内核数据，避免了用户态和内核态之间的切换，从而提高了性能。
- 非侵入性： eBPF 程序可以在不修改应用代码的情况下，观测和分析系统行为。我们不需要修改 Dockerfile 或者 Kubernetes 的 YAML 文件。
- 可观测性深度： eBPF 可以观测到内核层面的信息，例如 TCP 连接状态、内核函数调用、磁盘 I/O 等。这为我们提供了更全面的系统视图。
eBPF 工作原理简析
- 编写 eBPF 程序： 使用 C 语言编写 eBPF 程序，并使用 LLVM 编译成 eBPF 字节码。
- 加载 eBPF 程序： 使用 BPF 系统调用将 eBPF 字节码加载到内核中。
- 验证 eBPF 程序： 内核会对 eBPF 程序进行安全验证，确保程序不会崩溃或恶意修改内核数据。
- 运行 eBPF 程序： 内核会将 eBPF 程序附加到指定的事件或函数上，例如 TCP 连接事件、系统调用等。当事件发生时，eBPF 程序会被自动执行。
- 收集数据： eBPF 程序可以将收集到的数据存储到 BPF Maps 中。BPF Maps 是一种内核态的键值存储，用户态程序可以通过 BPF 系统调用读取 BPF Maps 中的数据。
eBPF 在可观测性方面的应用
- 网络监控： 可以使用 eBPF 观测 TCP 连接状态、网络流量、丢包率等。例如，可以使用
tcpdump命令抓包，或者使用bpftrace脚本分析网络性能。 - 性能分析： 可以使用 eBPF 跟踪内核函数调用、系统调用、磁盘 I/O 等。例如，可以使用
perf命令进行性能分析，或者使用bpftrace脚本分析应用程序的性能瓶颈。 - 安全监控： 可以使用 eBPF 监控系统调用，检测恶意行为。例如，可以使用
falco工具进行安全监控。
代码示例：使用 bpftrace 跟踪 TCP 连接
#!/usr/bin/env bpftrace
#include <linux/socket.h>
#include <netinet/in.h>
BEGIN {
printf("Tracing TCP connections...\n");
}
kprobe:tcp_v4_connect {
// 获取本地 IP 地址和端口
$sk = (struct sock *)arg0;
$inet_sock = (struct inet_sock *)$sk;
$sport = $inet_sock->inet_sport;
$saddr = $inet_sock->inet_saddr;
// 获取远端 IP 地址和端口
$dport = ((struct sockaddr_in *)arg1)->sin_port;
$daddr = ((struct sockaddr_in *)arg1)->sin_addr.s_addr;
// 打印连接信息
printf("[%s:%d] -> [%s:%d]\n", ntop($saddr), ntohs($sport), ntop($daddr), ntohs($dport));
}
这个脚本使用 bpftrace 跟踪 tcp_v4_connect 内核函数，并打印 TCP 连接的本地 IP 地址、端口和远端 IP 地址、端口。要运行这个脚本，需要安装 bpftrace 工具，并具有 root 权限。
eBPF 与 Istio 的结合：更强大的可观测性解决方案
eBPF 和 Istio 并不是互相替代的技术，而是可以相互补充的。我们可以将 eBPF 和 Istio 结合起来，构建更强大的可观测性解决方案。
- 使用 eBPF 增强 Istio 的可观测性： 我们可以使用 eBPF 收集 Istio Sidecar Proxy 无法观测到的内核信息，例如 TCP 连接状态、内核函数调用等。然后，将这些信息添加到 Istio 的 Metrics、Logs 或 Traces 中，从而增强 Istio 的可观测性深度。
- 使用 Istio 管理 eBPF 程序的部署： 我们可以使用 Istio 的流量管理功能来部署和管理 eBPF 程序。例如，我们可以使用 Istio 的流量路由规则将 eBPF 程序部署到指定的 Pod 上。
实战避坑经验总结
- 安全： 在使用 eBPF 时，一定要注意安全问题。eBPF 程序运行在内核中，如果存在漏洞，可能会导致系统崩溃或安全风险。因此，一定要对 eBPF 程序进行严格的安全验证。
- 性能： eBPF 程序虽然性能很高，但也需要注意性能优化。如果 eBPF 程序过于复杂或频繁地访问内核数据，可能会影响系统性能。因此，要尽量简化 eBPF 程序，并避免不必要的内核访问。
- 兼容性： eBPF 技术还在快速发展中，不同的内核版本对 eBPF 的支持程度不同。因此，在使用 eBPF 时，要注意内核版本的兼容性。
总结
eBPF 是一种强大的内核技术，可以为云原生应用提供更深入、更高效的可观测性。通过从对比 eBPF 和 Istio 开始的讨论，我们可以看到 eBPF 在解决 Istio 局限性方面的潜力。随着云原生技术的不断发展，eBPF 将会在可观测性领域发挥越来越重要的作用。我们可以期待看到更多基于 eBPF 的可观测性工具和解决方案出现，帮助我们更好地理解和管理云原生应用。
