image
上篇文章《Kubernetes 集群 Node 间歇性 NotReady，查到最后竟然是这个原因》里提到的问题遇到了新情况。之前用 iostat -x 观察到磁盘的 %util 一直稳定在 100，磁盘读写延迟有时候高达 20 秒，在有状况的机器上能够找到正在大量刷日志的进程。
最近发现一个新情况，有的 node 节点偶尔出现 %util 达到 100 的情况，持续时间不长，登录查看的时候偶尔能看到，同时磁盘的读写极少，让人有些困惑。
这个新情况出现频率不高，暂时没有调查思路，先强化这方面的监控，看后续能不能找到蛛丝马迹。另外上周得到一个意外信息，node 节点是 IaaS 上的虚拟机，如果虚拟机所在的物理机的 IO 过高，虚拟机的 IO 操作会被限制，和新情况可能有关系。
言归正传，这里记录一下 Ingress 使用过程中遇到的奇葩问题和调查结果。这里记录的问题现象和调查过程，有可能是我在不同的公司遇到的，可能是正式生产环境中的集群上发生的，也可能是随便捣鼓的小集群上发生的，这里的重点不是如何实践，而是问题现象和排查思路。
基于 haproxy 时遇到 503
很早之前使用基于 haproxy 的 ingress，比较频繁地遇到 503 响应码，业务方不停地喊，哎，503 啊，这种状态持续了比较长的时间，那种绵延不绝被刺激而又束手无策的状态，简直酸爽......
硬着头皮啃完全不熟悉的 haproxy 文档，一天天从早到晚地试验琢磨，好在终于有所发现。返回 503，表示 haproxy 没有找到当前请求的 Host 对应的配置规则，但是查看配置文件，配置文件中是有的，问题有些诡异。
不停地尝试复现，同时观察 haproxy 进程的状态，终于发现了端倪：因为端口复用，同时有多个 haproxy 进程在监听 80 端口，这些 haproxy 进程中，有一部分进程的内存中加载的是旧的配置，没有加载最新的配置文件。
当请求被分给那些内存中依然是旧配置的 haproxy 进程时，haproxy 会因为找不到对应的转发规则而返回 503。
这个问题很隐蔽，磁盘上的配置文件是全新的，内存是旧的，且只有部分 haproxy 进程的内存是旧的，检查配置文件不能发现问题。这些进程上面的连接全部断开后，haproxy 进程会主动退出，问题会消失。要在配置变化前用一个长连接卡住旧的 haproxy 进程，不让它退出，才能稳定复现问题。
为什么会出现这种情况，坦白讲，就和以前遇到的很多问题一样，没有查出所以然，也没有人关心认可这些事......但有效地解决方法找到了，只要在 haproxy 每次更新的时候，对所有的 haproxy 进程再发送一次信号就可以，用** -sf 指定所有已经存在的 haproxy 的进程号**，而不是只指定上一个 haproxy 进程。
下面的连接中详细记录了当时的调查过程，点击「阅读原文」可直接查看：
https://www.lijiaocn.com/%E9%97%AE%E9%A2%98/2017/09/19/haproxy-inter-not-found.html
估计已经没有多少人在用 haproxy 作为 ingress 了，但这个问题现象和原因还是挺有价值的。
前不久在朋友圈看到，haproxy 的最新版本有了重大变化，对用作 ingress 的场景有了更好地支持。这个变化是不是来的有些晚？未来似乎属于 nginx 和 envoy 。
时间关系，先记录这一个问题，502 和 504 的情况另外找时间整理。
