k8s线上集群的机器，重启iptables后，造成CI系统（drone）构建偶发失败，docker run容器无法访问外网问题排查记录

引子：

线上的k8s集群内部，每一台机器，都有2块网卡，一块儿em1（10网段），一个 em2（192网段）。然后，线上的机器，通过iptables限制为：访问192段的服务任意端口都是畅通的，而访问10段的服务端口，只有333端口可以连通。333端口，是线上机器的ssh端口。

线上集群的k8s，使用的calico网络。

线上有一个问题，就是容器访问当前宿主机192段IP的999端口不通，访问其他机器192段IP的9999端口畅通。

我们知道，当从容器访问宿主机的应用时，会重新进入iptables的INPUT链，而线上的iptables INPUT链如下：

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1    1477K 2519M cali-INPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:Cz_u1IQiXIMmKD4c */
2     272K   20M KUBE-SERVICES  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes service portals */
3     273K   20M KUBE-FIREWALL  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
4     263K   20M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
5        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
6      393 17292 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
7    11880 1019K ACCEPT     all  --  em2    *       0.0.0.0/0            0.0.0.0/0           
8        7   308 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:333
9     228 62052 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

意思是：

①：如果报文是途径em2网卡，访问任意其他网卡。则全部放行。（这就是为什么192段的访问全部放行）

②：如果报文是tcp，不管报文从哪个网卡出来，去往哪个网卡，只要目的端口是333，就放行。（这就是为什么10段的访问，只能访问333）

我们容器发出的报文，网卡是 cal 网卡（calico的网卡名称），所以，容器只能访问333。

错误操作：

要把9999端口放开，意味着，我要添加开放9999端口到INPUT链路中，为了让iptables再重启后依然生效，我将规则，添加到

/etc/sysconfig/iptables

在添加完成后其实并未生效，然后，有2种方式，用于让iptables生效：

①：手动添加规则，比如 iptables -t filter -I INPUT 9 -s 172.20.0.0/14 -p tcp -m tcp --dport 9999 -j ACCEPT

②：重启iptables（会自动加载 /etc/sysconfig/iptables内容）

我选择了后者，之所以选择后者，其实是因为，即便重启了iptables，加载了刚刚的规则，原来的k8s和calico的iptables会丢失，但是，k8s会重建自己的整套iptables规则的。

事实上，k8s确实也在我重启iptables后，重建了iptables，但问题来了。

引发的2个网络问题：

1、我们线上的CI系统，是基于drone，做的二次开发，改动了很多的东西，添加了很多特性，结果上面一系列操作之后，我发现，我们的CI系统中，个别镜像的构建（Dockerfile中的RUN操作，有网络相关操作时，比如yum）会失败。

2、线上的机器，执行 docker run，起来的容器，无法访问外网了。然而，k8s起来的pod里的容器，却可以访问外网。

镜像的构建，其实本质上，也是起容器来做事情，而且，你无法定制docker build操作时，使用的网络模式，只能是bridge模式。而 docker run 起来的容器，默认也是 bridge 模式。结合上面2个内容，基本上可以确定，此问题，和k8s无关，而是纯粹的docker的问题了。

排查：

①：一开始以为是k8s的iptables重建不完整，所以，多次用线上的机器的机器 nodeA（无人访问的一台），不断尝试清空iptables，等待k8s重建iptables，多次尝试无效。

②：stop docker -> stop kubelet -> clean iptables -> start docker -> start kubelet。这个操作的意义是，以为重启docker，重启k8s，docker 和 k8s 都会重建自己的 iptables。多次尝试无效。

③：使用现在的k8s安装工具：kubespray，重新安装 nodeA，并添加到k8s集群内。寄希望于安装工具重装docker和k8s，结果依然无效。

④：回归问题本身，问题一定出在iptables上。也是因为一开始重启了iptables导致此一系列问题。

解决过程：

既然问题出在iptables上，而我们要访问外网，那么，就得重iptables 报文转出入手。好在线上的机器，并没有都为了适配9999端口重启iptables，有3台 k8s 的 master 节点，并没有重启 iptables。

然后，对比有问题机器、没有问题机器的 FORWARD、POSTROUTING 的规则。发现，缺少DOCKER相关的规则，这些规则，本来是安装docker之后，由docker创建的。那么，解决此问题，就需要重建docker的iptables。

①：找一台干净的机器（只安装了docker，未启动容器，为安装k8s），然后从中提取docker相关的规则

②：将提取的规则，与出问题的机器的iptables默认规则融合。

③：执行 iptables-restore 恢复规则。

后续验证：

在问题机器上，docker run centos 容器，然后ping qq.com，链路畅通。有一个小问题，就是如果你先启动的容器执行 ping 外网操作。然后才再目的机器上执行 iptables-restore 的话，会发现，容器的 ping，有一个短暂的耗时，然后才会畅通，这是因为 iptables-restore 恢复规则后，有一个过程。

最后：

我整理一个相对标准的docker iptables规则备份，如果你也遇到了启动的docker容器，无法访问外网的问题，可以通过下面的内容，恢复规则

将下面的规则，保存到一个文件，比如 docker-iptables-backup

# Generated by iptables-save v1.4.21 on Thu Apr 30 20:48:42 2015
*nat
:PREROUTING ACCEPT [18:1080]
:INPUT ACCEPT [18:1080]
:OUTPUT ACCEPT [22:1550]
:POSTROUTING ACCEPT [22:1550]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.17.0.1/32 -d 172.17.0.1/32 -p tcp -m tcp --dport 80 -j MASQUERADE
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 3001 -j DNAT --to-destination 172.17.0.1:80
COMMIT
# Completed on Thu Apr 30 20:48:42 2015
# Generated by iptables-save v1.4.21 on Thu Apr 30 20:48:42 2015
*filter
:INPUT ACCEPT [495:53218]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [480:89217]
:DOCKER - [0:0]
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d 172.17.0.1/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 80 -j ACCEPT
COMMIT
# Completed on Thu Apr 30 20:48:42 2015

然后，执行恢复 iptables-restore docker-iptables-backup

注意：

①：如果你的docker在k8s集群内部，理论上来说，上面的操作会有清空iptables的能力，但是你不需要担心，因为k8s会自行修复本身的iptables，也就是说，k8s会重建自己的iptables。但是假如你的k8s没能完整重建，就需要手动恢复k8s的iptables。如果是calico网络，只需要删除当前节点的calico pod即可，删除之后，k8s会重启这个pod，自然也就会重建iptables了。同理，flannel网络也是一样的。

②：上面的规则，有一个关键，是 172.17.0.0 和 172.17.0.1，这是docker默认安装后的网段和docker0网卡的IP。如果你是默认安装的docker，上面的规则不需要改动，但如果你定制了docker0网卡的IP，记得修改一下上面的规则，适配你的环境。