云网络

MetalLB 网络插件兼容性 1. 一段话总结 总体而言，MetalLB 对 Kubernetes 集群中所选用的网络插件没有特殊偏好，只要该插件能提供 Kubernetes 期望的标准行为即可正常

Macvlan 可以通过 eBPF 结合 TC（Traffic Control，流量控制）实现 QoS（服务质量）管理，核心在于利用 TC 的钩子点挂载 eBPF 程序，对 Macvlan 接口的进出

Macvlan 网络模式下，可以通过 eBPF 的 XDP（eXpress Data Path）程序实现 DDoS 流量过滤（包括 drop 恶意流量） ，但需结合具体的网络架构和技术细节设计实现，核

在 K8S 中，Macvlan 通常比 Veth pair 性能更好，但不能绝对地说 Macvlan 一定在所有情况下都优于 Veth pair。 Macvlan 性能优势主要体现在以下方面： 绕过主

MetalLB 与云平台兼容性及替代方案 1. 一段话总结 总体而言，MetalLB主要适用于裸机集群，与大多数云服务提供商不兼容，仅对Equinix Metal、Hetzner、OVH等少数平台提供

1. 一段话总结 MetalLB 在 BGP 模式下，集群每个节点与网络路由器建立BGP对等会话，并通过该会话 advertise 外部集群服务的IP； 若路由器支持多路径(ECMP)，可基于等价路由

1. 一段话总结 MetalLB 的layer2 模式 通过让单个节点向本地网络宣告服务（模拟该节点网卡分配多个 IP），依托ARP（IPv4）/NDP（IPv6）  响应网络请求，具备通用性强、无需

kube-proxy 的 strictARP 默认配置及原因 kube-proxy 原生默认不启用 strictARP（即默认设为 false），主要原因与 Kubernetes 网络模型的兼容性、默

Linux 中模拟“交换机 + BGP”的开源软件 在 Linux 服务器中，可用于模拟交换机且支持 BGP 协议的开源软件主要有以下几种，它们既能模拟二层交换功能，又能通过集成路由协议栈实现 BGP

1. 环境 2. 网络 Cilium 是基于 eBPF 的容器网络解决方案（常用于 Kubernetes），其路由的核心作用是实现 Pod 网络、主机网络与外部网络之间的流量转发，并为 eBPF 程序

Cilium 的 eBPF 程序并非持久化保存在内核中；它们是动态加载进内核的。 当系统重启时，内核中的 eBPF 程序会丢失，必须在系统启动时重新加载。Cilium 依赖于在启动时重新初始化 eBP

k8s 集群信息 节点网络信息 node 上，访问本地 pod，都直接走 node 路由 大部分 iptables 规则都是 calico 的规则 1. CRD 数据配置一览 具体 CRD 应用详情

calico all in one 环境中的 localdns 相关的 iptables 规则 这些规则均围绕 “NodeLocal DNS Cache” （节点本地 DNS 缓存，IP 为 169.

calico 的 vxlan 为什么不能实现 vpc 的效果 ？ 我感觉都是基于 vxlan 的，至少底子是一致的。 只是 calico 只能做到二层，不能做三层，它本身的路由都是在宿主机上做的，不像

IPIP 与主流 VPC 协议（VXLAN/GRE）对比表 对比维度 IPIP VXLAN GRE 核心隔离标识 无专属标识，依赖外层IP区分隧道 有 VNI（1600万+），支持海量租户 有 GRE

问题现象 跟踪丢包位置 分析 iptables 与 NetworkPolicy 排查 从日志看，核心问题是 Pod 发送的 TCP SYN 包在节点的 iptables filter INPUT 链被

calico CRD 一览 calico CRD 功能一览 Calico 在 Kubernetes 中的网络资源定义 以下是每个资源的详细功能说明： **bgpconfigurations.crd.p

XGo 选择 C、Go、Python、JavaScript 和 Scratch 作为其支持的语言，实际上是有深刻考虑的： C：作为底层系统编程语言，C 的性能极高，能够贴近硬件，广泛用于系统、嵌入式和

Envoy、Katran 和 Cilium 这三种负载均衡(LB)方案，在实现原理、功能丰富度和性能等方面差异显著。Envoy 主打高阶 L7/L4 场景和治理能力，Katran 和 Cilium 则

Envoy 和 Katran 在负载均衡功能丰富度与性能方面有很大区别：Envoy 功能极其丰富，支持 L4 和 L7 多种协议和高级治理功能，而 Katran 以 L4 性能极致、方案极为精简为目标