如何判断cilium是否使用了iptalbes或者nftables

1.确认 Cilium 确实完全接管了转发

cilium status

在输出的 KubeProxyReplacement 一栏中： • 如果显示 Strict 或 True：说明 kube-proxy 已被完全替换，核心的 Service 流量（NodePort, ClusterIP, LoadBalancer）全部通过 eBPF 查找（BFT maps）进行 O(1) 级别的高效转发，不走 iptables 或 nftables。

2. 检查 Cilium 的配置参数（确定使用了iptables 还是 nftables？）

kubectl get cm cilium-config -n kube-system -o yaml | grep -E “routing-mode|bpf-masquerade|install-iptables” enable-bpf-masquerade: “true” routing-mode: native

#查看所有 Cilium 的配置， cilium config view | grep install clustermesh-mcs-api-install-crds true install-no-conntrack-iptables-rules true

install-no-conntrack-iptables-rules: true 这个参数表示发往或来自 K8s 容器的流量，linux不记录到系统的全局连接跟踪表里。

查看 iptable状态

[root@test-alma10-kvm88 ~]# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
CILIUM_PRE_nat  all  --  0.0.0.0/0            0.0.0.0/0            /* cilium-feeder: CILIUM_PRE_nat */

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
CILIUM_OUTPUT_nat  all  --  0.0.0.0/0            0.0.0.0/0            /* cilium-feeder: CILIUM_OUTPUT_nat */

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
CILIUM_POST_nat  all  --  0.0.0.0/0            0.0.0.0/0            /* cilium-feeder: CILIUM_POST_nat */

Chain CILIUM_OUTPUT_nat (1 references)
target     prot opt source               destination         

Chain CILIUM_POST_nat (1 references)
target     prot opt source               destination         

Chain CILIUM_PRE_nat (1 references)
target     prot opt source               destination         

Chain KUBE-KUBELET-CANARY (0 references)
target     prot opt source               destination         
[root@test-alma10-kvm88 ~]# iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N CILIUM_OUTPUT_nat
-N CILIUM_POST_nat
-N CILIUM_PRE_nat
-N KUBE-KUBELET-CANARY
-A PREROUTING -m comment --comment "cilium-feeder: CILIUM_PRE_nat" -j CILIUM_PRE_nat
-A OUTPUT -m comment --comment "cilium-feeder: CILIUM_OUTPUT_nat" -j CILIUM_OUTPUT_nat
-A POSTROUTING -m comment --comment "cilium-feeder: CILIUM_POST_nat" -j CILIUM_POST_nat

• 整个系统的 nat 表空空如也。没有成百上千条 KUBE-SVC-xxx 或 KUBE-SEP-xxx 规则。 • Cilium 虽然创建了 CILIUM_PRE_nat、CILIUM_POST_nat 和 CILIUM_OUTPUT_nat 这三个自定义链，但这些链里面一条具体的转换规则都没有（全是空的）。

Netkit网络包是这样流转的：

 [ Pod 里的网卡 ] 
       │  (通过 Netkit 技术，零拷贝，直接以极速弹射到宿主机内核)
       ▼
[ 宿主机内核 BPF 程序 ] ──> 【在这里直接通过 BPF 完成了 NAT 和路由修改！】
       │
       ├─> (可选：把连接状态同步给内核的 Conntrack 存个档，防冲突)
       │
       ▼
[ 物理网卡直接飞出去 ] ──> (完全绕过了 iptables 的 PREROUTING/POSTROUTING 规则链)

查看conntrack

#升级权限并使用 dnf 安装 conntrack-tools sudo dnf install -y conntrack-tools conntrack -L

ip link show 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp1s0: mtu 1500 xdp qdisc fq state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:bd:82:c8 brd ff:ff:ff:ff:ff:ff prog/xdp id 256 name cil_xdp_entry tag f583a1a18c438dfb jited altname enx525400bd82c8 3: cilium_net@cilium_host: mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 96:a6:aa:89:46:24 brd ff:ff:ff:ff:ff:ff 4: cilium_host@cilium_net: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether ee:30:db:e3:e8:47 brd ff:ff:ff:ff:ff:ff 6: lxc_health@if5: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff link-netnsid 0

说明： enp1s0网卡挂载了 XDP：网卡上直接挂载了名为 cil_xdp_entry 的 eBPF 程序。 00:00:00:00:00:00 的 MAC 地址是 Netkit 设备极其典型的特征（区别于传统 veth pair 两端都有独立 MAC 且有 ARP）

Kubernetes 最先进的网络全家桶：

1. 完全没有 kube-proxy：iptables -t nat 没有任何 K8s 转发链。
2. 纯 eBPF 查表转发：cilium-dbg map 里赫然躺着 58 条内核 Service 记录。
3. 网卡 XDP 硬件级加速：ip link 里物理网卡直接被 cil_xdp_entry 接管，包在进入协议栈前就被 eBPF 处理。
4. Netkit 弹射直连：没有了传统复杂的 veth 硬件开销。