image.png

大致原因：和eth1地址对ip ha vip 对应的port的属性以及安全组设置有关系

port的某些属性会影响sb 流表最后的出口

定位思路:

1. 地址对，负载均衡器的使用方式和pod ip有何异同
   从结果来看，地址对ip都是通的，所以地址对ip可以认为毫无问题

2. 地址对ip绑定fip的方式有何异同，是否存在编码，update不稳定的情况。

3. 在地址对ip绑定fip不通的情况下，fip绑定给主ip 是否一定可以通。

fip 绑定给 eth1 主ip 一定是可以通的，
那么把副ip对应的fip删除掉，再重建出来，再手动绑定上，是否可以解决问题？ 可以解决问题

fip解绑再绑定，无效
port重新创建，然后更新为地址对，再绑定fip，则fip 可通，所以其实还是地址对ip相关的问题。

有效解决方式:

1. 确认eth1 主ip对应的端口 安全组有设置，且没有限制
2. 确认地址对ip对应的port 安全组有设置，且没有限制
3. 确认地址对ip对应的port
   启用了管理员状态
   启用了端口安全
   设备ID
   设备所属者
   绑定主机都为空

小结：
安全组是充份条件，但是即使安全组没问题，fip也不一定能通，

image.png image.png

表现

删掉设备和设备所属者 马上就通了
只修改 启用管理员状态 和 端口安全都没用

感觉跟port的流表初始化有关系，启用管理员状态 决定了port创建时即配置流表转发

还是要跟踪流表看一下，到底安全组正确的情况下，哪一个条件才是关键不稳定因素。

image.png

二、 另一个不稳定因素

在集成|开启haporxy exporter监控之后，octavia health manager会自动执行 failover，原因就是因为多开放了一个端口，导致健康检查的逻辑失败

问题1.:

octavia-health-manager.log

Amphora 7be3d61c-8f75-44dd-ac94-c505cef8af82 health message reports 2 listeners when 1 expected

victoria-0.62 仅开启了8404 监控端口，仍然会触发该failover

测试2： 基于未改动的代码验证，基于haproxy2.3的镜像，然后添加8404的配置，重启虚拟机应用配置，仍然会执行failover，所以这个的确是多加了一个端口导致的。

测试3： 基于未改动的代码，不修改配置，仅重启虚拟机，观察是否会failover

修改安全组 后 再重启

结果： 不会触发failover