网络组件已知问题与内核兼容性¶
本页汇总说明各个网络组件的已知问题，这些问题可能会对生产环境产生重大影响，并给出一些建议和方案。
kube-proxy¶
IPVS 模式¶
访问服务有 1s 延迟或者请求失败问题
-
现象：
- 通过 Service 访问服务有 1s 延迟
- 滚动更新业务，有部分请求失败
-
影响：
k8s 版本 kube-proxy 行为 现象 <=1.17 net.ipv4.vs.conn_reuse_mode=0 RealServer 无法被移除，当滚动更新业务，有部分请求失败。 >=1.19 net.ipv4.vs.conn_reuse_mode=0 (kernel > 4.1)
net.ipv4.vs.conn_reuse_mode=1 (kernel < 4.1)CentOS 7.6-7.9，默认内核版本低于 4.1，存在通过 Service 访问服务有 1s 延迟问题。
CentOS 8 默认内核 4.16 高于 4.1，存在 RealServer 无法被移除，当滚动更新业务，有部分请求失败。>=1.22 不修改 net.ipv4.vs.conn_reuse_mode 值（kernel > 5.6）
net.ipv4.vs.conn_reuse_mode=0 (kernel > 4.1)
net.ipv4.vs.conn_reuse_mode=1 (kernel < 4.1)CentOS 7.6-7.9，默认内核版本低于 4.1，存在通过 Service 访问服务有 1s 延迟问题。
CentOS 8 默认内核 4.16 高于 4.1，存在 RealServer 无法被移除，当滚动更新业务，有部分请求失败。
Ubuntu 22.04 默认内核版本 5.15，高于 5.9 内核，不存在该问题。 -
建议：对于低于 5.9 内核的系统，不推荐使用 IPVS 模式。
iptables 模式¶
-
现象：源端口 nat 以后不够随机，导致 1s 延时
-
影响：
内核 iptables 版本 现象 < 3.13 1.6.2 源端口 nat 以后不够随机，导致 1s 延时。 -
建议：参考系统发行版本，升级内核。
externalIPs 在 externalTrafficPolicy: Local 下不工作¶
-
影响：1.26.0 <= 受影响版本 < 1.30.0
-
建议：升级到 1.30.0
Service 的 endpoint 更新时新 endpoint 的规则等到很久以后才生效¶
-
影响：1.27.0 <= 受影响版本 < 1.30.0
-
建议：升级到 1.30.0
nftables 模式下 LoadBalancerSourceRanges 无法正常工作¶
-
建议：升级到 1.30.0
iptables nft 和 legacy 模式选择问题¶
-
影响：
版本 行为 影响 <v1.18 使用 iptables-legacy kube-proxy 可能不会工作 >=v1.18 自动计算，更优先选择 nft
Calico¶
offload VXLAN 导致访问延迟¶
- 影响：
| Calico 版本 | 行为 | 影响 |
|---|---|---|
| <v3.20 | 不处理 | 内核 < 5.7，Pod 与 Service 之间延迟 63s。 |
| >=v3.20 | 可以通过 FelixConfiguration 配置，默认自动关闭 VXLAN offload。 | 导致网卡性能低，只能跑到 1-2 Gbps/s。 |
| >= 3.28 | 在 5.7 内核自动打开 VXLAN offload， 解决之前的 ClusterIP 访问丢包问题，提高性能。 | 内核 < 5.7，导致网卡性能低，只能跑到 1-2 Gbps/s。 |
-
建议：低版本 Calico 存在访问延迟问题时，可以通过
ethtool --offload vxlan.calico rx off tx off规避。 高版本 Calico 默认自动关闭 VXLAN offload，对于网络性能有要求的客户可以升级内核到 5.7 解决。 -
参考：
- Felix Pull Request #2811
VXLAN 父设备改了但路由没更新¶
- 影响：
| Calico 版本 | 行为 | 影响 |
|---|---|---|
| <v3.28.0 | 不处理 | 路由表未更新为使用新的父网卡，即使重新启动 felix 后，也无法清理旧的路由。 |
| >=v3.28.0 | 当父设备发生更改时，VXLAN 管理器会重新创建路由表。 | 无 |
-
建议：更新到 v3.28。
集群 calico-kube-controllers 的缓存不同步，导致内存泄漏¶
- 建议：更新到 v3.26.0。
IPIP 模式下 Pod 跨节点网络不通¶
- 影响：
| Calico 版本 | 行为 | 影响 |
|---|---|---|
| <v3.28.0 | 不处理 | 由于 iptables --random-fully 和 checksum 校验和计算不兼容，在内核 < 5.7，Pod 跨节点网络可能不通。 |
| >=v3.28.0 | 默认禁用 checksum 计算 | 无 |
-
建议：更新到 v3.28.0+，较低版本可以使用
ethtool -K tunl0 tx off命令手动关闭。
iptables nft 和 legacy 模式选择问题¶
-
影响：
Calico 版本 行为 影响 <v3.26.0 仅支持需要手动指定，自动计算存在一定逻辑问题。 由于 iptables 模式选择错误，可能会导致 Service 网络异常。 >=v3.26.0 自动计算。 无 -
建议：更新到 v3.26.0+，较低版本需要手动指定
FELIX_IPTABLESBACKEND变量，可选值 NFT 或者 LEGACY。
Spiderpool¶
- 建议：如果您遇到了如下的问题，请尝试更新 Spiderpool 到更高的版本来解决。
v0.9 已知问题¶
SpiderCoordinator 同步 status 时出错，但状态仍为 running¶
-
分析：如果获取集群的 CIDR 信息失败，我们应该将其状态更新为 NotReady，这会阻止 Pod 的正常创建。否则，Pod 将使用不正确的 CIDR 运行，将造成网络连通问题。
Values.multus.multusCNI.uninstall 设置后不生效，导致 multus 资源没有正确删除¶
-
分析：Values.multus.multusCNI.uninstall 设置为 true 后，卸载 Spiderpool 后，发现仍存在 multus 相关资源，它们并没有如预期的一样被删除。
缺失 kubeadm-config 时无法从 kubeControllerManager Pod 获取 serviceCIDR¶
-
分析：有些场景没有使用 kubeadm 创建集群，可能没有 kubeadm-config configMap，将会尝试从 kubeControllerManager 中获取， 由于 bug 却无法从 kubeControllerManager Pod 获取 serviceCIDR，导致 SpiderCoordinator 的 status 更新失败。
从 v0.7.0 升级到 v0.9.0 时 SpiderCoordinator CRD 新增的 TxQueueLen 属性会导致 panic¶
-
分析：Spiderpool v0.9.0 为 SpiderCoordinator CRD 添加一个新属性
TxQueueLen，但在升级操作。没有默认值，将导致 panic。需使用它并将其视为默认值 0。
由于集群部署方式不同，导致 SpiderCoordinator 返回空的 serviceCIDR，从而无法创建 Pod¶
-
分析：由于集群部署方式的不同，集群 kube-controller-manager Pod 中记录 CIDR 的有两种类型：
Spec.Containers[0].CommandSpec.Containers[0].Args
比如 RKE2 集群是
Spec.Containers[0].Args而不是Spec.Containers[0].Command， 而在原本逻辑中 hardcodeSpec.Containers[0].Command，导致判断异常，返回空 serviceCIDR，而无法创建 Pod。
v0.8 已知问题¶
ifacer 无法使用 vlan 0 创建 bond¶
-
分析：使用 vlan 0 时，通过 ifacer 创建 bond 将失败。
禁用 multus 功能，仍创建了 multus CR 资源¶
-
现象：当安装时，禁用了 multus 功能，仍创建了 multus CR 资源，不符合预期。
SpiderCoordinator 无法检测 Pod 的 netns 中的网关连接¶
-
分析：当前 SpiderCoordinator 使用插件使用 errgroup 来并发检查网关可达性和 IP 冲突，提高检测速度。 由于每个操作系统线程可以有不同的网络命名空间，并且 Go 的线程调度是高度可变的，因此调用者不能保证设置任何特定的命名空间， 但是在 netns.Do 中启动 goroutine 时，Go 运行时无法保证代码一定会在指定的网络命名空间中执行， 因此需要修改了 Go 的 errgroup 方法：在启动 goroutine 时手动切换到目标网络命名空间，执行完毕后返回原网络命名空间，从而保证能够检查网关可达性和 IP 冲突。
当 kubevirt 固定 IP 功能关闭时 spiderpool-agent Pod crash¶
-
分析：当将 kubevirt 固定 IP 功能关闭时，spiderpool-agent Pod 将 crash，无法运行，影响整体 IPAM 功能。
SpiderIPPool 资源未继承 SpiderSubnet 的 gateway 和 route 属性¶
-
分析：如果先创建 SpiderSubnet 资源，然后再创建对应子网的 SpiderIPPool 资源，则 SpiderIPPool 会继承 SpiderSubnet 的 gateway、routes。 但是，如果您首先创建一个孤立的 SpiderIPPool，再创建对应的 SpiderSubnet 资源；那么 SpiderIPPool 资源将不会继承 SpiderSubnet 属性。
v0.7 已知问题¶
StatefulSet 类型的 Pod 重启后获取 IP 分配时，提示 IP 冲突¶
-
分析：由于 StatefulSet Pod 重新启动，此时 GC scanAll 会释放之前的 IP 地址，因为系统认为 Pod UID 与 IPPool 记录的 IP 地址不同，从而提示冲突。
Spiderpool 无法识别某些第三方控制器，导致 StatefulSet 的 Pod 无法使用固定 IP¶
-
现象：Spiderpool 无法识别如 RedisCluster 等第三方控制器，被它们控制的 StatefulSet 的 Pod 无法使用固定 IP。
-
分析：对于第三方控制器：RedisCluster -> StatefulSet -> Pod，如果 Spiderpool 为其设置 SpiderSubnet 自动池注释，Pod 将无法成功启动。
空的 spidermultusconfig.spec, 将导致 spiderpool-controller Pod crash¶
-
现象：使用空的
spidermultusconfig.spec创建 CR，webhook 校验成功，但没有相关的 network-attachment-definitions 生成，并且查看到 spiderpool-controller 出现了 panic。
Cilium 模式获取到错误的 overlayPodCIDR¶
-
现象：SpiderCoordinator auto 模式获取
podCIDRType类型错误，更新 SpiderCoordinator status 状态不符合预期；创建 Pod 可能导致出现网络问题。
Pod 与 IP 数 1:1 的场景，出现 IPAM 分配阻塞，导致一些 Pod 无法运行，对分配 IP 性能产生影响¶
-
分析：IPPool 具有 1000 个 IP 地址，并创建具有 1000 个副本的 Deployment，在分配到一定数量的 IP 地址后， 观察到分配性能下降明显，甚至无法继续分配 IP 地址，而一个 Pod 在没有 IP 地址的情况下无法正常启动。 实际 IPPool 资源中已经记录了 Pod 并分配了其 IP，但 SpiderEndpoint 对应的 Pod 却不存在。
禁用 IP GC 功能，spiderpool-controller 组件将由于 readiness 健康检查失败而无法正确启动¶
-
分析：禁用 IP GC 功能，spiderpool-controller 组件将由于 readiness 健康检查失败而无法正确启动。
IPPool.Spec.MultusName 指定 namespace/multusName 时 namespace 解析错误导致找不到关联的 multusName¶
-
现象：
IPPool.Spec.MultusName指定了 namespace/multusName，但由于解析 namespace 错误，导致无法找到关联的 multusName，亲和失败。 -
分析：指定了 Pod Annotation
v1.multus-cni.io/default-network: kube-system/ipvlan-eth0， 由于 Spiderpool 对 namespace 的错误解析，导致查询 network-attachment-definitions 时使用了错误的 namespace， 导致找不到对应的 network-attachment-definitions，从而无法成功创建 Pod。