故障背景:
租户告知生产环境的sftp突然无法访问了,登录环境查看sftp服务运行都是正常的,访问sftp的hostport端口确实不通。
故障处理过程
既然访问不通那就先给服务做个全面检查,看看哪里出了问题,看下sftp日志,也没有啥关键报错,接下来查看了下sftp服务的svc端口,发现通过svc地址和端口是能正常访问的,通过pod IP去访问也是可以,这就很奇怪了,唯独用主机ip加hostport端口就访问不通。
尝试手段一: 跟租户沟通,看看能否重启服务试试,发现重启完服务,还是老样子,通过hostport访问依然不通。
尝试手段二: 登录到对应的sftp主机,查看sftp服务对应的iptables规则是否有啥限制或者生产的容器服务规则转发有问题,发现iptables的规则没有做啥拦截,唯一的拦截是对icmp协议的,基本不是这个问题,然后查看到iptables规则中关于sftp hostport端口转发到目的服务地址有问题,以前的pod生产转发规则还存在,那就是以前的pod删除后,iptables规则没有及时跟新删除,如下图所示有许多2022的hostport端口转发到sftp容器的22端口:
然后尝试重启Kube-proxy使其重新加载规则看看,重启完之后查看规则确实正常了,但是请求sftp的hostport端口仍然不通。
尝试手段三: 凡是再一再二,不再三,仔细分析下,通过业务主机和hostport访问,还会涉及走PREROUTING链,看下PREROUTING如下:
1)sudo iptables -t nat -nvL PREROUTING
2)sudo iptables -t nat -nvL CNI-HOSTPORT-DNAT
1)sudo iptables -t nat -nvL CNI-DN-5312d803d41f87c69f67f
查看对应2022端口号的nat规则
2)sudo iptables -t nat -nvL CNI-HOSTPORT-DNAT --line-numbers 查看对应规则的序号
3)sudo iptables -t nat -D CNI-HOSTPORT-DNAT 1 删除对应规则 ,注: 确定这条规则确实以前产生没用的。
具体操作步骤如下截图:
删完对应规则后,sftp的hostport访问正常。可能跟升级操作系统后防火墙出现问题导致pod销毁,规则无法回收。