故障背景：
租户告知生产环境的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销毁，规则无法回收。
