必须检查宿主机内核是否支持cilium所需ebpf特性，包括btf存在性（ls /sys/kernel/btf/vmlinux）、bpf_jit_enable值为1、关键config_bpf等选项启用，否则cilium-agent将因“btf not found”或权限拒绝而启动失败。

确认宿主机内核是否支持Cilium所需eBPF特性

不满足内核要求是Cilium启动失败最常见的原因，cilium-agent日志里反复出现 "BTF not found" 或 "failed to load program: permission denied" 基本都卡在这步。

• 检查 BTF 是否可用：ls /sys/kernel/btf/vmlinux —— 必须存在，否则 Cilium 无法做 CO-RE 适配
• 验证 eBPF 系统调用权限：cat /proc/sys/net/core/bpf_jit_enable 应为 1（多数现代发行版默认开启）
• 确保内核配置启用关键选项：CONFIG_BPF=y、CONFIG_BPF_SYSCALL=y、CONFIG_CGROUP_BPF=y、CONFIG_NET_CLS_BPF=m、CONFIG_NET_ACT_BPF=m
• Ubuntu 20.10+ / RHEL 8.2+ / Debian 11+ 默认满足；若用自定义内核或旧版 CentOS 7，需手动编译并启用上述选项

在Kubernetes集群中部署Cilium而非kube-proxy

Cilium 要真正替代 iptables 链式转发、发挥 XDP 和 eBPF 短路优势，必须彻底移除 kube-proxy，否则两者规则冲突，流量路径混乱，策略行为不可预测。

Linux installer

先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

• 安装前先禁用 kube-proxy：kubectl delete ds -n kube-system kube-proxy，再清理其残留的 iptables 规则：iptables -F && iptables -t nat -F
• 使用官方 Helm chart 安装时，显式关闭 kube-proxy 集成：--set kubeProxyReplacement=strict
• 确保 hostServices.enabled=false（除非你明确需要 hostport 支持），避免与传统 netfilter 行为混用
• 部署后验证：cilium status --verbose 中 KubeProxyReplacement 字段应为 Strict，且 Cluster health 显示所有节点为 OK

为Go微服务Pod配置NetworkPolicy实现L7细粒度控制

Cilium 的核心价值不在 L3/L4 网络连通性，而在于对 Go 服务 HTTP/gRPC 流量的原生协议解析能力——这依赖于 eBPF 在 socket 层直接 hook 应用程序套接字，无需 sidecar。

• 确保你的 Go 服务监听地址绑定到 0.0.0.0（非 127.0.0.1），否则 eBPF socket filter 无法捕获流量
• NetworkPolicy 必须启用 policyTypes: [Ingress, Egress] 并指定 rule.protocol: TCP，否则 Cilium 不会启用 L7 解析引擎
• HTTP 策略示例中，path: "/healthz" 是精确匹配，不是正则；如需模糊匹配，必须用 headers + fieldRef 组合，例如：key: "X-Service-Version", operator: "Equal", value: "v2"
• gRPC 策略依赖 io.cilium/grpc 注解或自动服务发现，若 Go 服务未暴露 grpc.reflection.v1.ServerReflection，Cilium 可能无法识别方法名，建议显式在 Pod annotation 中声明：cilium.io/ingress-l7-rules: '{"http":[{"method":"POST","path":"/helloworld.Greeter/SayHello"}]}'

排查Go服务eBPF监控数据缺失或延迟的常见断点

eBPF 程序本身不会丢数据，但用户态采集链路容易因资源限制或配置疏漏导致指标“看起来没上报”。

• 检查 Cilium 的 monitor-aggregation 级别：默认 medium 会聚合事件，高频小请求可能被合并；调试阶段设为 none：--set monitorAggregation=none
• Hubble 服务端口（默认 :4244）必须可被客户端访问，且客户端证书需由 Cilium CA 签发；hubble observe 报 "connection refused" 多因 Service 没暴露或 NetworkPolicy 拦截了 hubble-relay
• Go 应用若使用 net/http 标准库，Cilium 能自动识别；但若用了 fasthttp 或自定义 TLS 封装，需确认是否触发了 sock_ops 和 connect4 hook，否则连接建立阶段就无法追踪
• 注意 Cilium 的 eBPF map 大小限制：bpf-map-events 默认仅 65536 条，高并发场景下可能被覆盖；可通过 --set bpf.mapEvents=131072 扩容，但会增加内存占用

Cilium 的复杂性不在安装命令本身，而在于它把整个网络栈的控制权从用户态（iptables）移交给了内核态（eBPF）。一旦某个环节仍残留旧机制（比如忘记关 kube-proxy、或 Go 服务绑错地址），eBPF 程序就会安静地绕过它——既不报错，也不生效。调试时永远优先确认 Hook 点是否真实挂载成功，而不是盯着应用日志找线索。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！