云网络

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 性能极致、方案极为精简为目标

什么是 xDS？——Envoy 动态配置核心体系解析 xDS 是 Envoy 代理中动态配置管理体系的核心统称，全称为 “* Discovery Service”（“x” 代表各类可动态发现的资源类型

Envoy 核心信息总结 本文围绕 Envoy 展开介绍，明确其定位、设计理念，并详细阐述核心功能，以展现其在现代服务架构中的价值。 一、Envoy 定位与核心设计理念 1. 定位 Envoy 是一款

Cilium主要包括以下几个独立的关键服务组成部分： Cilium Agent（守护进程） Cilium CLI 客户端 Cilium Operator Cilium CNI插件 以及内置的 Cili

1. OVS ACL 流表的本质 在 OVS 里，ACL 规则通常是通过 ovs-ofctl add-flow 或 OpenFlow 控制器下发的 流表项 来实现的。 这些流表项存放在 OVS 的 流

LocalDNS 绕过了 IPv6 Service 的 NAT 转发，直接与 CoreDNS Pod 建立连接，避免了 IPv6 NAT 支持差、性能低、连接不稳定的问题。 图 1：未使用 Local