公众号原文:https://mp.weixin.qq.com/s/Ue0tZXHryXo5jEYjsP2-Ig
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 的情况另外找时间整理。
上一篇:Kubernetes集群Node间歇性NotReady,查到最后竟然是这个原因
关注返回作者微信,直接加,不闲扯
(除非特殊情况,不帮忙解决问题)
image