前言
这个缺陷很奇怪，仅在使用我的公司自研的操作系统上部署时产生。但是这个由于 haproxy 的配置缺陷导致的问题确实存在，记录以供后续参考。
问题表现
在部署过程与部署完成后均出现 mysql 数据无法连接的问题。导致集群无法工作。
问题原因排查
进入 mysql 容器，通过命令行工具指定 host 登录 mysql 发现 mysqld 是正常工作的，但是 api 地址(经过 haproxy 代理的服务地址上) 3306 并未监听。
此时问题基本就定位到了 haproxy 上，查看日志，日志没有关于 3306 端口的错误（其实此刻3306端口根本没有被代理）。检查 haproxy 配置 /etc/kolla/haproxy/services.d/mariadb.cfg
# /etc/kolla/haproxy/services.d/mariadb.cfg
frontend mariadb_front
mode tcp
option clitcpka
timeout client 3600s
option tcplog
bind 10.50.124.236:3306
default_backend mariadb_back
backend mariadb_back
mode tcp
option srvtcpka
timeout server 3600s
option httpchk
server DAS-OS 10.50.124.235:3306 check port 4569 inter 2000 rise 2 fall 5
貌似一切都正常。
查看 haproxy 的控制台（1984 端口，账号密码写在/etc/kolla/haproxy/haproxy.cfg配置文件中）。我们发现了 mariadb_back 这个状态是错误的。？？？
猜测
这样问题就很奇怪了，对比该别的集群 haproxy 的配置完全一样，为什么这里会发生错误呢。并且 haproxy 的容器到 mariadb 的容器网络是畅通的，mariadb 的服务也是正常工作的。为何会检测不通过内，我手动测试是完全OK的。
抱着尝试的心态看了下 haproxy mariadb_back 的配置，有一项引起了我的注意 option httpchk。这是一个非 http 的服务为什么使用 http 这个状态检测方式呢，不应该是 tcp 什么的么？但是，但是 ！有经验的同学也会知道，当我们用 nc 或者 curl 访问 mysql 的 3306 端口是有一定的回显的（嗯大概是 http 1.0 那种毫无格式的回显）。于是我尝试着在 harproxy 的容器中 curl 访问 mariadb 的 3306 端口。嗯~~~，报错了 ---- 不支持 http 1.0 格式。具体的回显我忘记的，但是大概是这个意思。但是这个方式在其他的系统中是可以正常获得 mariadb 的回显的，唯独这里不行，由于时间紧急，这个问题我将会放到后续探究。
解决
确认了问题所在问题的解决就变得简单了。修改为 tcplog 重启后即可正常工作。