Hubble observe 默认看不到 HTTP/gRPC 请求详情，因 Cilium 默认关闭 L7 协议解码，仅显示 L3/L4 元数据；需启用 --enable-l7-proxy 等配置并验证三条件满足方可生效。
为什么 hubble observe 默认看不到 HTTP/gRPC 请求详情
因为 Cilium 默认关闭 L7 协议解码，hubble observe 只显示网络层（L3/L4）元数据，比如源/目的 IP、端口、状态，但不会解析 HTTP 方法、路径、gRPC service/method。这不是 bug，是设计选择：L7 解码有 CPU 开销，且需明确 opt-in。
关键开关在 Cilium DaemonSet 的启动参数和 Hubble Server 配置里，不是靠客户端命令开启的。
-
--enable-l7-proxy必须设为true（Cilium agent 启动参数） -
--l7-proxy-wait-bpf-program推荐保持默认true，避免 BPF 程序未就绪时丢流量 - Hubble Server 必须启用
--enable-k8s-event-handling（非必须但建议，否则缺失命名空间/Service 关联）
如何确认 L7 解码已实际生效
不能只看 Cilium ConfigMap 里写了 enable-l7-proxy: "true"——它只是配置项，真正起效要满足三个条件同时成立：
- Cilium agent 进程启动时，
ps aux | grep cilium-agent能看到--enable-l7-proxy=true -
cilium status --verbose输出中包含L7 proxy: OK -
hubble get flows --last 10 | jq '.[] | select(.l7 != null)'能返回非空结果（说明已有 L7 流量被解码）
常见失败点：升级 Cilium 后没重启 agent；或用了 Helm 安装但忘了加 --set l7Proxy.enabled=true；或集群启用了 eBPF Host Routing 模式但没配好 redirect 策略。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
hubble observe 查看 HTTP/gRPC 流量的正确姿势
直接跑 hubble observe 会混杂大量非 L7 流量，干扰判断。应该用过滤 + 字段投影：
- 查 HTTP：
hubble observe --type l7 --protocol http --output json | jq '.[0].l7.http' - 查 gRPC：
hubble observe --type l7 --protocol grpc --output json | jq '.[0].l7.grpc' - 想看原始请求头？加
--follow并注意l7.http.request.headers是数组，不是对象（格式为[["user-agent","curl/7.68.0"]]）
注意：--protocol 参数值必须小写且严格匹配（http 不是 HTTP），否则过滤失效；--type l7 是硬性前提，漏掉就看不到任何 L7 字段。
gRPC 可见性比 HTTP 更容易断链的原因
HTTP 解码依赖标准端口（80/443）或 ALPN 协商；gRPC 必须走 HTTP/2，且 Cilium 当前（v1.14+）仅支持 TLS 终止后的明文 HTTP/2 流量解码。这意味着：
- 如果 client → ingress → service 是 TLS 穿透（ingress 不终止 TLS），Cilium 看不到明文 HTTP/2 帧，
l7.grpc字段为空 - 若用
grpcurl直连 ClusterIP（无 TLS），且端口不是 80/443/8080/8443，默认不触发 L7 代理，需显式加--l7-protocol-port-mapping配置 -
l7.grpc.status_code只在 response 返回后才填充，request 流量里该字段不存在——别用它过滤 request
最稳妥的做法：让服务监听 443 或 8443，ingress 终止 TLS 后以明文 HTTP/2 转发到 backend，并确保 Cilium 的 --l7-protocol-port-mapping 包含对应端口映射。
