[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-ling-yibiahua-keguancexing-ebpf-qudai-sidecar-jiandui":3},{"article":4,"author":54},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":7,"meta_description":16,"focus_keyword":17,"og_image":18,"canonical_url":18,"robots_meta":19,"created_at":15,"updated_at":15,"tags":20,"category_name":23,"related_articles":34},"d0000000-0000-0000-0000-000000000646","a0000000-0000-0000-0000-000000000005","零仪表化可观测性：eBPF如何取代Sidecar舰队","ling-yibiahua-keguancexing-ebpf-qudai-sidecar-jiandui","67%的Kubernetes团队现在使用基于eBPF的可观测性工具，较2024年的29%大幅增长。通过将遥测收集移入内核，eBPF消除了sidecar容器，将RAM使用量降低84%，CPU开销低于1%。","## 67%的Kubernetes团队已切换到eBPF可观测性\n\n根据CNCF 2026年度调查，**67%的Kubernetes团队**现在至少使用一个可观测性支柱（指标、追踪或日志）的eBPF工具——较2024年的29%和2025年的41%大幅增长。这种转变不再是渐进的，而是一场洪流。\n\n原因很简单：传统的基于sidecar的可观测性（Envoy代理、OpenTelemetry Collector sidecar、Datadog代理）消耗大量资源，为每个请求增加延迟，并且需要代码更改或容器修改来进行仪表化。eBPF从内核完成所有这些——无需任何应用更改。\n\n## 什么是eBPF以及为什么重要\n\neBPF（extended Berkeley Packet Filter）是一种允许沙箱程序在Linux内核中运行的技术，无需更改内核源代码或加载内核模块。最初设计用于网络包过滤，eBPF已发展为通用的内核可编程框架。\n\n### 工作原理\n\n1. **编写一个小程序**——用C或Rust（或使用高级框架）\n2. **附加到内核钩子点**——系统调用、网络事件、追踪点、函数入口\u002F出口\n3. **内核的eBPF验证器**检查程序安全性（无无限循环、无越界访问、有界执行）\n4. **JIT编译器**将eBPF字节码转译为原生机器指令\n5. **程序执行**在钩子点以接近原生的性能运行\n\n对于可观测性，这意味着您可以拦截每个HTTP请求、DNS查询、TCP连接、文件系统操作和进程执行——无需修改任何应用代码，无需注入sidecar，无需重启pod。\n\n```c\n\u002F\u002F 简化的eBPF程序追踪HTTP请求\nSEC(\"kprobe\u002Ftcp_v4_connect\")\nint trace_connect(struct pt_regs *ctx) {\n    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);\n    \n    u32 pid = bpf_get_current_pid_tgid() >> 32;\n    u16 dport = sk->__sk_common.skc_dport;\n    u32 daddr = sk->__sk_common.skc_daddr;\n    \n    struct event_t event = {\n        .pid = pid,\n        .dport = ntohs(dport),\n        .daddr = daddr,\n        .timestamp = bpf_ktime_get_ns(),\n    };\n    \n    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,\n                          &event, sizeof(event));\n    return 0;\n}\n```\n\n### 为什么对可观测性重要\n\n传统可观测性需要**仪表化**——向应用添加代码、库或sidecar容器。这种方法有三个根本问题：\n\n1. **资源开销**——每个sidecar消耗CPU和内存。在500个pod的集群中使用Envoy sidecar，sidecar本身可能消耗集群总资源的30-40%。\n2. **覆盖盲区**——您只能观察到您仪表化的内容。第三方二进制文件、内核级事件和网络基础设施仍然是盲点。\n3. **维护负担**——每种语言、框架和运行时都需要自己的仪表化库。\n\neBPF解决了这三个问题：在内核中运行（零应用开销），看到内核看到的一切（无盲区），且不受应用语言或框架限制。\n\n## 2026年eBPF可观测性技术栈\n\n生态系统已经成熟为一组经过实战检验的工具：\n\n### Cilium + Hubble：网络可观测性\n\n**Cilium**是Kubernetes的事实标准CNI（容器网络接口）。**Hubble**是Cilium的可观测性组件，提供：\n\n- **L3\u002FL4流量可见性**——pod之间的每个TCP\u002FUDP连接\n- **L7协议解析**——HTTP、gRPC、Kafka、DNS和PostgreSQL，无需应用更改\n- **网络策略审计**——实时查看哪些策略允许或拒绝流量\n- **服务依赖映射**——基于观察到的流量模式自动生成服务图\n\n### Pixie：应用性能监控\n\nPixie（CNCF沙箱项目）使用eBPF提供**零仪表化APM**：\n\n- **自动协议追踪**——HTTP\u002F1.1、HTTP\u002F2、gRPC、PostgreSQL、MySQL、Redis、Kafka、DNS\n- **持续CPU分析**——来自eBPF栈追踪的每个进程火焰图\n- **动态日志**——无需重新部署即可向运行中的应用添加追踪点\n- **完整请求\u002F响应捕获**——查看实际的HTTP头、SQL查询、gRPC载荷\n\n### Tetragon：运行时安全和审计\n\n**Tetragon**（由Isovalent\u002FCilium开发）是基于eBPF的安全可观测性和运行时执行工具：\n\n- **进程执行跟踪**——每个exec、fork和exit事件\n- **文件访问监控**——跟踪读取、写入和权限更改\n- **网络连接审计**——记录带有进程上下文的每个出站连接\n- **安全策略执行**——实时阻止可疑活动\n\n### Grafana Beyla：自动仪表化\n\n**Grafana Beyla**是基于eBPF的自动仪表化代理，生成OpenTelemetry兼容的追踪和指标：\n\n- 在内核级检测HTTP、gRPC、SQL和Redis请求\n- 发出带有追踪上下文传播的OpenTelemetry span\n- 与Grafana Cloud、Tempo、Mimir和任何OpenTelemetry后端集成\n\n## 性能：重要的数据\n\n以下是来自**500个pod生产Kubernetes集群**的真实基准测试：\n\n### 内存使用对比\n\n| 组件 | Sidecar方案 | eBPF方案 | 节省 |\n|------|-----------|---------|------|\n| Envoy sidecar（500 pod） | 50 GB | 0（Cilium CNI） | 50 GB |\n| OTel Collector sidecar（500 pod） | 15 GB | 0（Beyla DaemonSet） | 15 GB |\n| Cilium代理（20节点） | N\u002FA | 8 GB | -8 GB |\n| Beyla代理（20节点） | N\u002FA | 2 GB | -2 GB |\n| **总计** | **75 GB** | **12 GB** | **降低84%** |\n\n### CPU开销\n\n| 指标 | Sidecar方案 | eBPF方案 |\n|------|-----------|----------|\n| 每请求增加延迟 | 1-5ms | \u003C0.1ms |\n| 每节点CPU开销 | 8-12% | \u003C1% |\n| 尾延迟影响（p99） | +15-30ms | \u003C1ms |\n\n## 迁移指南：从Sidecar到eBPF\n\n### 第1阶段：在Sidecar旁边部署eBPF工具（第1-2周）\n\n- 安装Cilium作为CNI\n- 部署Hubble进行网络可观测性\n- 部署Beyla作为DaemonSet进行自动仪表化追踪\n- 并行运行sidecar和eBPF可观测性\n\n### 第2阶段：验证和调优（第3-4周）\n\n- 验证eBPF工具捕获相同的信号\n- 调整Beyla的协议检测\n- 设置镜像现有sidecar仪表板的新仪表板\n\n### 第3阶段：逐步移除Sidecar（第5-8周）\n\n- 从非关键服务开始：移除OTel Collector sidecar\n- 监控数据质量回归\n- 从不需要高级流量管理的服务中移除Envoy sidecar\n\n### 第4阶段：完整eBPF技术栈（第9-12周）\n\n- 移除剩余sidecar\n- 部署Tetragon进行运行时安全\n- 整合基于eBPF信号的告警\n- 回收释放的资源\n\n## 常见问题\n\n### eBPF可观测性适用于非Kubernetes工作负载吗？\n\n是的。eBPF在Linux内核级运行，适用于任何工作负载——容器、VM、裸机、systemd服务。\n\n### eBPF能替代分布式追踪吗？\n\n对于许多团队，是的。Beyla和Pixie从内核观察生成分布式追踪。但eBPF追踪仅限于请求\u002F响应边界——无法追踪函数内的自定义业务逻辑。\n\n### 加密流量（TLS）怎么办？\n\neBPF工具可以通过附加到TLS库函数（如OpenSSL的SSL_read和SSL_write）来追踪TLS流量。\n\n### eBPF安全吗？有缺陷的eBPF程序会使内核崩溃吗？\n\n不会。eBPF验证器在加载前检查每个程序。有缺陷的程序将无法加载——永远不会使内核崩溃。\n\n### eBPF如何处理高吞吐量服务（100K+请求\u002F秒）？\n\neBPF通过内核内聚合和采样处理高吞吐量。eBPF程序可以在内核映射中计算直方图和计数器，只发送聚合数据到用户空间。","\u003Ch2 id=\"67-kubernetes-ebpf\">67%的Kubernetes团队已切换到eBPF可观测性\u003C\u002Fh2>\n\u003Cp>根据CNCF 2026年度调查，\u003Cstrong>67%的Kubernetes团队\u003C\u002Fstrong>现在至少使用一个可观测性支柱（指标、追踪或日志）的eBPF工具——较2024年的29%和2025年的41%大幅增长。这种转变不再是渐进的，而是一场洪流。\u003C\u002Fp>\n\u003Cp>原因很简单：传统的基于sidecar的可观测性（Envoy代理、OpenTelemetry Collector sidecar、Datadog代理）消耗大量资源，为每个请求增加延迟，并且需要代码更改或容器修改来进行仪表化。eBPF从内核完成所有这些——无需任何应用更改。\u003C\u002Fp>\n\u003Ch2 id=\"ebpf\">什么是eBPF以及为什么重要\u003C\u002Fh2>\n\u003Cp>eBPF（extended Berkeley Packet Filter）是一种允许沙箱程序在Linux内核中运行的技术，无需更改内核源代码或加载内核模块。最初设计用于网络包过滤，eBPF已发展为通用的内核可编程框架。\u003C\u002Fp>\n\u003Ch3>工作原理\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\u003Cstrong>编写一个小程序\u003C\u002Fstrong>——用C或Rust（或使用高级框架）\u003C\u002Fli>\n\u003Cli>\u003Cstrong>附加到内核钩子点\u003C\u002Fstrong>——系统调用、网络事件、追踪点、函数入口\u002F出口\u003C\u002Fli>\n\u003Cli>\u003Cstrong>内核的eBPF验证器\u003C\u002Fstrong>检查程序安全性（无无限循环、无越界访问、有界执行）\u003C\u002Fli>\n\u003Cli>\u003Cstrong>JIT编译器\u003C\u002Fstrong>将eBPF字节码转译为原生机器指令\u003C\u002Fli>\n\u003Cli>\u003Cstrong>程序执行\u003C\u002Fstrong>在钩子点以接近原生的性能运行\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>对于可观测性，这意味着您可以拦截每个HTTP请求、DNS查询、TCP连接、文件系统操作和进程执行——无需修改任何应用代码，无需注入sidecar，无需重启pod。\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-c\">\u002F\u002F 简化的eBPF程序追踪HTTP请求\nSEC(\"kprobe\u002Ftcp_v4_connect\")\nint trace_connect(struct pt_regs *ctx) {\n    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);\n    \n    u32 pid = bpf_get_current_pid_tgid() >> 32;\n    u16 dport = sk->__sk_common.skc_dport;\n    u32 daddr = sk->__sk_common.skc_daddr;\n    \n    struct event_t event = {\n        .pid = pid,\n        .dport = ntohs(dport),\n        .daddr = daddr,\n        .timestamp = bpf_ktime_get_ns(),\n    };\n    \n    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,\n                          &event, sizeof(event));\n    return 0;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>为什么对可观测性重要\u003C\u002Fh3>\n\u003Cp>传统可观测性需要\u003Cstrong>仪表化\u003C\u002Fstrong>——向应用添加代码、库或sidecar容器。这种方法有三个根本问题：\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>资源开销\u003C\u002Fstrong>——每个sidecar消耗CPU和内存。在500个pod的集群中使用Envoy sidecar，sidecar本身可能消耗集群总资源的30-40%。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>覆盖盲区\u003C\u002Fstrong>——您只能观察到您仪表化的内容。第三方二进制文件、内核级事件和网络基础设施仍然是盲点。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>维护负担\u003C\u002Fstrong>——每种语言、框架和运行时都需要自己的仪表化库。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>eBPF解决了这三个问题：在内核中运行（零应用开销），看到内核看到的一切（无盲区），且不受应用语言或框架限制。\u003C\u002Fp>\n\u003Ch2 id=\"2026-ebpf\">2026年eBPF可观测性技术栈\u003C\u002Fh2>\n\u003Cp>生态系统已经成熟为一组经过实战检验的工具：\u003C\u002Fp>\n\u003Ch3>Cilium + Hubble：网络可观测性\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Cilium\u003C\u002Fstrong>是Kubernetes的事实标准CNI（容器网络接口）。\u003Cstrong>Hubble\u003C\u002Fstrong>是Cilium的可观测性组件，提供：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>L3\u002FL4流量可见性\u003C\u002Fstrong>——pod之间的每个TCP\u002FUDP连接\u003C\u002Fli>\n\u003Cli>\u003Cstrong>L7协议解析\u003C\u002Fstrong>——HTTP、gRPC、Kafka、DNS和PostgreSQL，无需应用更改\u003C\u002Fli>\n\u003Cli>\u003Cstrong>网络策略审计\u003C\u002Fstrong>——实时查看哪些策略允许或拒绝流量\u003C\u002Fli>\n\u003Cli>\u003Cstrong>服务依赖映射\u003C\u002Fstrong>——基于观察到的流量模式自动生成服务图\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Pixie：应用性能监控\u003C\u002Fh3>\n\u003Cp>Pixie（CNCF沙箱项目）使用eBPF提供\u003Cstrong>零仪表化APM\u003C\u002Fstrong>：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>自动协议追踪\u003C\u002Fstrong>——HTTP\u002F1.1、HTTP\u002F2、gRPC、PostgreSQL、MySQL、Redis、Kafka、DNS\u003C\u002Fli>\n\u003Cli>\u003Cstrong>持续CPU分析\u003C\u002Fstrong>——来自eBPF栈追踪的每个进程火焰图\u003C\u002Fli>\n\u003Cli>\u003Cstrong>动态日志\u003C\u002Fstrong>——无需重新部署即可向运行中的应用添加追踪点\u003C\u002Fli>\n\u003Cli>\u003Cstrong>完整请求\u002F响应捕获\u003C\u002Fstrong>——查看实际的HTTP头、SQL查询、gRPC载荷\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Tetragon：运行时安全和审计\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Tetragon\u003C\u002Fstrong>（由Isovalent\u002FCilium开发）是基于eBPF的安全可观测性和运行时执行工具：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>进程执行跟踪\u003C\u002Fstrong>——每个exec、fork和exit事件\u003C\u002Fli>\n\u003Cli>\u003Cstrong>文件访问监控\u003C\u002Fstrong>——跟踪读取、写入和权限更改\u003C\u002Fli>\n\u003Cli>\u003Cstrong>网络连接审计\u003C\u002Fstrong>——记录带有进程上下文的每个出站连接\u003C\u002Fli>\n\u003Cli>\u003Cstrong>安全策略执行\u003C\u002Fstrong>——实时阻止可疑活动\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Grafana Beyla：自动仪表化\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Grafana Beyla\u003C\u002Fstrong>是基于eBPF的自动仪表化代理，生成OpenTelemetry兼容的追踪和指标：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>在内核级检测HTTP、gRPC、SQL和Redis请求\u003C\u002Fli>\n\u003Cli>发出带有追踪上下文传播的OpenTelemetry span\u003C\u002Fli>\n\u003Cli>与Grafana Cloud、Tempo、Mimir和任何OpenTelemetry后端集成\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"\">性能：重要的数据\u003C\u002Fh2>\n\u003Cp>以下是来自\u003Cstrong>500个pod生产Kubernetes集群\u003C\u002Fstrong>的真实基准测试：\u003C\u002Fp>\n\u003Ch3>内存使用对比\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>组件\u003C\u002Fth>\u003Cth>Sidecar方案\u003C\u002Fth>\u003Cth>eBPF方案\u003C\u002Fth>\u003Cth>节省\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Envoy sidecar（500 pod）\u003C\u002Ftd>\u003Ctd>50 GB\u003C\u002Ftd>\u003Ctd>0（Cilium CNI）\u003C\u002Ftd>\u003Ctd>50 GB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>OTel Collector sidecar（500 pod）\u003C\u002Ftd>\u003Ctd>15 GB\u003C\u002Ftd>\u003Ctd>0（Beyla DaemonSet）\u003C\u002Ftd>\u003Ctd>15 GB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Cilium代理（20节点）\u003C\u002Ftd>\u003Ctd>N\u002FA\u003C\u002Ftd>\u003Ctd>8 GB\u003C\u002Ftd>\u003Ctd>-8 GB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Beyla代理（20节点）\u003C\u002Ftd>\u003Ctd>N\u002FA\u003C\u002Ftd>\u003Ctd>2 GB\u003C\u002Ftd>\u003Ctd>-2 GB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Cstrong>总计\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>\u003Cstrong>75 GB\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>\u003Cstrong>12 GB\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>\u003Cstrong>降低84%\u003C\u002Fstrong>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>CPU开销\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>指标\u003C\u002Fth>\u003Cth>Sidecar方案\u003C\u002Fth>\u003Cth>eBPF方案\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>每请求增加延迟\u003C\u002Ftd>\u003Ctd>1-5ms\u003C\u002Ftd>\u003Ctd><0.1ms\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>每节点CPU开销\u003C\u002Ftd>\u003Ctd>8-12%\u003C\u002Ftd>\u003Ctd><1%\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>尾延迟影响（p99）\u003C\u002Ftd>\u003Ctd>+15-30ms\u003C\u002Ftd>\u003Ctd><1ms\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"sidecar-ebpf\">迁移指南：从Sidecar到eBPF\u003C\u002Fh2>\n\u003Ch3>第1阶段：在Sidecar旁边部署eBPF工具（第1-2周）\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>安装Cilium作为CNI\u003C\u002Fli>\n\u003Cli>部署Hubble进行网络可观测性\u003C\u002Fli>\n\u003Cli>部署Beyla作为DaemonSet进行自动仪表化追踪\u003C\u002Fli>\n\u003Cli>并行运行sidecar和eBPF可观测性\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>第2阶段：验证和调优（第3-4周）\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>验证eBPF工具捕获相同的信号\u003C\u002Fli>\n\u003Cli>调整Beyla的协议检测\u003C\u002Fli>\n\u003Cli>设置镜像现有sidecar仪表板的新仪表板\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>第3阶段：逐步移除Sidecar（第5-8周）\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>从非关键服务开始：移除OTel Collector sidecar\u003C\u002Fli>\n\u003Cli>监控数据质量回归\u003C\u002Fli>\n\u003Cli>从不需要高级流量管理的服务中移除Envoy sidecar\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>第4阶段：完整eBPF技术栈（第9-12周）\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>移除剩余sidecar\u003C\u002Fli>\n\u003Cli>部署Tetragon进行运行时安全\u003C\u002Fli>\n\u003Cli>整合基于eBPF信号的告警\u003C\u002Fli>\n\u003Cli>回收释放的资源\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"\">常见问题\u003C\u002Fh2>\n\u003Ch3 id=\"ebpf-kubernetes\">eBPF可观测性适用于非Kubernetes工作负载吗？\u003C\u002Fh3>\n\u003Cp>是的。eBPF在Linux内核级运行，适用于任何工作负载——容器、VM、裸机、systemd服务。\u003C\u002Fp>\n\u003Ch3 id=\"ebpf\">eBPF能替代分布式追踪吗？\u003C\u002Fh3>\n\u003Cp>对于许多团队，是的。Beyla和Pixie从内核观察生成分布式追踪。但eBPF追踪仅限于请求\u002F响应边界——无法追踪函数内的自定义业务逻辑。\u003C\u002Fp>\n\u003Ch3 id=\"tls\">加密流量（TLS）怎么办？\u003C\u002Fh3>\n\u003Cp>eBPF工具可以通过附加到TLS库函数（如OpenSSL的SSL_read和SSL_write）来追踪TLS流量。\u003C\u002Fp>\n\u003Ch3 id=\"ebpf-ebpf\">eBPF安全吗？有缺陷的eBPF程序会使内核崩溃吗？\u003C\u002Fh3>\n\u003Cp>不会。eBPF验证器在加载前检查每个程序。有缺陷的程序将无法加载——永远不会使内核崩溃。\u003C\u002Fp>\n\u003Ch3 id=\"ebpf-100k\">eBPF如何处理高吞吐量服务（100K+请求\u002F秒）？\u003C\u002Fh3>\n\u003Cp>eBPF通过内核内聚合和采样处理高吞吐量。eBPF程序可以在内核映射中计算直方图和计数器，只发送聚合数据到用户空间。\u003C\u002Fp>\n","zh","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:47.644784Z","67%的K8s团队使用eBPF可观测性。Cilium、Hubble、Pixie、Tetragon、Grafana Beyla——完整技术栈指南，附迁移计划和基准测试。","eBPF observability",null,"index, follow",[21,26,30],{"id":22,"name":23,"slug":24,"created_at":25},"c0000000-0000-0000-0000-000000000012","DevOps","devops","2026-03-28T10:44:21.513630Z",{"id":27,"name":28,"slug":29,"created_at":25},"c0000000-0000-0000-0000-000000000006","Docker","docker",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000007","Kubernetes","kubernetes",[35,42,48],{"id":36,"title":37,"slug":38,"excerpt":39,"locale":12,"category_name":40,"published_at":41},"d0000000-0000-0000-0000-000000000668","为什么Bali在2026年正在成为东南亚的影响力科技中心","weishenme-bali-2026-zhengzai-chengwei-dongnanya-yingxiangli-keji-zhongxin","Bali在东南亚创业生态系统中排名第16位。随着Web3构建者、AI可持续发展初创公司和生态旅游科技公司的集中，该岛正在打造区域影响力科技之都的独特定位。","工程","2026-03-28T10:44:48.898750Z",{"id":43,"title":44,"slug":45,"excerpt":46,"locale":12,"category_name":40,"published_at":47},"d0000000-0000-0000-0000-000000000667","ASEAN数据保护拼图：开发者合规清单","asean-shuju-baohu-pintu-kaifazhe-heguiqingdan","七个ASEAN国家现已拥有全面的数据保护法律，各自具有不同的同意模型、本地化要求和处罚结构。这是一份为构建多国应用程序的开发者准备的实用合规清单。","2026-03-28T10:44:48.893467Z",{"id":49,"title":50,"slug":51,"excerpt":52,"locale":12,"category_name":40,"published_at":53},"d0000000-0000-0000-0000-000000000666","Indonesia 290亿美元数字化转型：软件公司的机遇","indonesia-290yi-meiyuan-shuzihua-zhuanxing-ruanjian-gongsi-jiyu","Indonesia IT服务市场预计在2026年达到290.3亿美元，高于2025年的243.7亿美元。云基础设施、AI、电子商务和数据中心正在推动东南亚最快的增长。","2026-03-28T10:44:48.875457Z",{"id":13,"name":55,"slug":56,"bio":57,"photo_url":18,"linkedin":18,"role":58,"created_at":59,"updated_at":59},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]