云网络

最近发现默认的 ubuntu 22.04 5.15.0-46-generic 内核测试发现没有最新的 5.15.0-161-generic kube-ovn 的 geneve 隧道网络稳定。 所以升级

pip install PySocks 这里可以详细解释一下原理： 1️⃣ 默认情况 get_url 在 Ansible 中底层调用的是 Python 的 urllib 或 requests 模块：

环境信息 InfiniBand/RoCE tools： ib_send_bw ib_send_lat ib_write_bw ib_write_lat ib_read_bw ib_read_lat i

ip link add name ipoib0 link ib0 type ipoib ip addr add 192.168.100.251/24 dev ipoib0 ip link set ip

mlx6 mlx5 switch from IB to ETH mlxconfig -d mlx5_0 set LINK_TYPE_P1=2 mlxconfig -d mlx5_1 set LINK_

问题： 如果这些 calico 的旧的 iptables 规则一直残留，是否会对 kube-ovn 的 pod 造成网络影响？ 环境信息 比如： 是否会导致如下问题： NAT 规则冲突 PREROUT

你的输出说明了一个非常典型的云厂商虚拟机 eBPF 支持状况： ✅ 已确认：你的 VM 完全支持 eBPF（包括 JIT、cgroup-bpf、LSM BPF），并且已经有多个 BPF 程序挂载运行

非常精准的问题 👍 我们可以把这个拆成三个部分来解释清楚： 🧩 结论先讲 场景 是否受 mode: dsr + dsrDispatch: geneve 影响 说明 负载均衡（LB）流量 ✅ 会影响 决

```bash root@k8s-work2:/var/lib/cni# tree | grep f6be5afd350deb1127371691e8782832293a47aed81a4022e8a

✅ 是的，完全正确。 在 默认（非 eBPF）模式 下，Calico 的 NetworkPolicy 实现是基于 iptables 的。 下面是更深入一点的解释： 🧩 Calico 的两种数据路径模式

Address_Set.addresses 在 NB/SB 两份 schema 里都声明为 {"type":{"key":"string","min":0,"max":"unlimited"}}（参见

下面把 OVN 中 Port_Group 与 Address_Set 的关系、语义差异、能否单独使用，以及在策略路由（routing-policy / PBR）中的可用性做一个详细、技术向的汇总与建议

非常好的问题，这里你已经抓到了关键差异。总结如下👇 🔍 现象总结 在 aarch64 + iptables (legacy) 的控制节点 k8s-ctrl 上执行脚本 不会断 SSH。 在 x86_6

问题 Calico 在 IP-in-IP / VXLAN 模式下的数据平面行为。 逐步拆解： 🧩 你的路由表说明了什么 这代表： Pod 的默认网关是 169.254.1.1（Calico 内部虚拟网

这个其实是 Cilium overlay 封装层选型（VXLAN vs GENEVE）里一个很有代表性的对比。下面我们从 功能丰富度 和 性能 两个维度系统分析下，基于目前（Cilium v1.15～

LS_CT_SKIP_DST_LPORT_IPS 出现在 kube-ovn-controller 的启动参数 中，是 控制器逻辑层面影响 OVN NB 配置和流表生成逻辑 的配置项。 下面我来结合 k

非常好的问题，这个参数其实是 OVN-Kubernetes（或 Kube-OVN）中针对 DNAT（Destination NAT）场景下的一个行为控制开关。 我们来从功能、原理和对应的流表行为三个层

非常好的问题 👏——eth0、ens33、enp4s0、eno1 这些名字确实让人一开始很困惑，其实它们的区别来自于 Linux 的“可预测网络接口命名规则（Predictable Network I

Cilium 文档写道： 这里的“依赖”并不严格意味着你 必须在 Helm values 中显式开启 socketLB.enabled=true。更准确的理解是： kubeProxyReplaceme

下面我整理一版 Cilium + VXLAN/EVPN Fabric 实现“租户对应 VNI／VPC 隔离”的方案思路，包括背景、关键组件、流程、优缺点、落地注意事项。你可据此判断当前是否适合你场景，