TLDR：Ubuntu22.04 openvswitch网络环境下使用Octavia组件原生的Amphora提供负载均衡即服务
本以为其他组件也会像几个基础组件那样顺风顺水地部署下来，还暗自庆幸似乎也没那么复杂，第一个扩展服务选择了Octavia，用来解决内部子网对外提供服务的需求，没想到就遭遇了滑铁卢，花了扎扎实实两个白天+夜晚才解决。很少有事情能让我在休息时间也兴致勃勃想要去尝试解决。
除了作为集群的南北向入口的L7代理外，LB还经常用来做L4代理内部子网端口，除了国内的公有云会单独提供NAT网关服务里会包括DNAT功能，国外主流的云平台似乎都是通过LB来暴露的。当然你也可以给内部网络的实例分配一个弹性ip然后自行部署一个反向代理去代理其他内部网络的实例。或者粗暴地给每个实例分配一个弹性ip，我的外部网络的ip也只是物理网络的私有ip而已，所以也不在乎浪不浪费。不过毕竟我们的目标是做一个多租户自助服务的私有云，那么干就太不优雅了。
问题
amphora网络可达性
官方文档的第7步要求我们创建一个veth对并且加入octavia管理网络所在的bridge。由于之前部署的neutron所用ml2插件时openstack network mapping的网络设备是openvswitch的bridge，所以不存在文档中所写的BRNAME=brq$(echo $NETID|cut -c 1-11)的bridge。这个看起来似乎是linux bridge网络模式下openstack的network会创建的对应bridge设备。
让我们试着忽略这个部分继续部署下去。
在配置完octavia.conf后尝试创建loadbalancer时，状态会一直卡在pending create，查看日志发现octavia worker连接不上agent的9443端口。
于是就被这个问题困扰了好久。而且糟糕的是网上octavia的相关文章很少，中文互联网就更别提了。不过这篇博客把Octavia的工作流程讲解得非常不错。
这张图很好地说明了octavia的网络架构，事实上octavia如官方文档所说，可以被部署在单独的物理机上、虚拟机或者容器内，但是要保证octavia worker能到达amphora。
让我们瞧瞧官方部署文档里的命令实际上做了些什么。
OCTAVIA_MGMT_SUBNET=172.16.0.0/12
OCTAVIA_MGMT_SUBNET_START=172.16.0.100
OCTAVIA_MGMT_SUBNET_END=172.16.31.254
OCTAVIA_MGMT_PORT_IP=172.16.0.2
openstack network create lb-mgmt-net
openstack subnet create --subnet-range $OCTAVIA_MGMT_SUBNET --allocation-pool \
start=$OCTAVIA_MGMT_SUBNET_START,end=$OCTAVIA_MGMT_SUBNET_END \
--network lb-mgmt-net lb-mgmt-subnet
SUBNET_ID=$(openstack subnet show lb-mgmt-subnet -f value -c id)
PORT_FIXED_IP="--fixed-ip subnet=$SUBNET_ID,ip-address=$OCTAVIA_MGMT_PORT_IP"
MGMT_PORT_ID=$(openstack port create --security-group \
lb-health-mgr-sec-grp --device-owner Octavia:health-mgr \
--host=$(hostname) -c id -f value --network lb-mgmt-net \
$PORT_FIXED_IP octavia-health-manager-listen-port)
MGMT_PORT_MAC=$(openstack port show -c mac_address -f value \
$MGMT_PORT_ID)
sudo ip link add o-hm0 type veth peer name o-bhm0
NETID=$(openstack network show lb-mgmt-net -c id -f value)
BRNAME=brq$(echo $NETID|cut -c 1-11)
sudo brctl addif $BRNAME o-bhm0
sudo ip link set o-bhm0 up
sudo ip link set dev o-hm0 address $MGMT_PORT_MAC
sudo iptables -I INPUT -i o-hm0 -p udp --dport 5555 -j ACCEPT
sudo dhclient -v o-hm0 -cf /etc/dhcp/octavia
1、创建了管理网络lb-mgmt-net以及相关子网和健康管理接口octavia-health-manager-listen-port。
2、创建了一个veth对，o-bhm0加入lb-mgmt-net网络，peer到主机的o-hm0接口。
3、修改o-hm0接口MAC地址为octavia-health-manager-listen-port接口虚拟mac，允许lb-mgmt-net网络的dhcp服务器为o-hm0接口分配IP地址。
目的无非是使运行在宿主机上的octavia-worker进程能够访问到处在lb-mgmt-net网络下的amphora实例，来管理下发配置。
那么我们只要实现同样的功能即可，但是网上还是没能找到openvswitch环境下的配置案例。不过这篇文章给我提供了很好的思路，在我创建了一个和octavia-health-manager-listen-port接口同样tagid的接口加入br-int并且分配ip地址之后，宿主机确实可以和amphora通讯了，loadbalancer状态也成功变成了active。但是似乎在我创建的loadbalancer subnet为lb-mgmt-net之外的网络子网时，宿主机cpu占用会飙升，创建的listener不通并且无法给loadbalancer分配弹性ip。具体原因还没有弄清楚，linux网络相关知识还是欠缺。
最终还是学着官方文档的做法，只是用ovs-vsctl将o-bhm0和加入lb-mgmt-net的网络。
ip link add o-hm0 type veth peer name o-bhm0
ovs-vsctl add-port br-int o-bhm0 tag=3
ip link set o-bhm0 up
ip link set dev o-hm0 address fa:16:3e:d5:ac:75
dhclient -v o-hm0 -cf /etc/dhcp/octavia
同样解决好重启时的启动脚本，但是openvswitch bridge中lb-mgmt-net所在的接口tag会变，不过处理起来也不复杂了。
删除pending create状态的lb
过程中未正常配置的情况下创建的loadbalancer由于处于pending create所以无法删除，需要先删掉关联的amphora，而删除amphora时会因为loadbalancer状态是pending create导致无法删除。
这时候可以改数据库里amphora的状态，然后删除。
use octavia;
UPDATE load_balancer SET provisioning_status='ERROR' WHERE id='xxxxxxxx';
DELETE FROM amphora WHERE id = 'xxxxxxxx';
amphora镜像
如果懒得自己构建amphora镜像，可以用预构建好的。
https://github.com/osism/openstack-octavia-amphora-image
记得选择适合你环境正确的版本。
dashboard
如果想要horizon里能看到loadbalancer菜单，需要单独安装.
后记
排查Octavia报错的过程可能是我探索openstack中最绝望的事情，资料的缺乏就像面对未知，甚至过程中考虑过换用A10、F5之类第三方的LB提供程序去对接Octavia。不过归根结底还是自己的知识储备不够深，平静下来理顺文档示例配置的逻辑就好解决了。
LBaaS的说法还是挺有趣的，接下来继续部署DBaaS、DNSaaS、MQaaS。