Question

我的小册子抱怨道：

E1201 09：00：12.562610 28747 kubelet_network.go:365]未能确保规则在过滤器链中丢弃由KUBE-MARK-DROP标记的数据包 KUBE-FIREWALL：错误附加规则：退出状态1：iptables：否链/目标/匹配该名称。

这通常发生在您忘记使用--net-host'rkt run'时，但我没有。

export RKT_OPTS =“ - volume var-log，kind = host，source = / var / log \
--mount volume = var-log，target = / var / log \ --volume dns，kind = host，source = / etc / resolv.conf \ --mount volume = dns，target = / etc / resolv.conf --net = host“

以下确认我的kube-proxy（由kubelet启动）与拥有iptables链的主机位于同一名称空间中：

root@i8:/etc# d exec -it 738 readlink /proc/self/ns/net
net:[4026531963]

root@i8:/etc# readlink /proc/self/ns/net
net:[4026531963]

root@i8:/etc# docker ps
CONTAINER ID        IMAGE                                      COMMAND                  CREATED             STATUS              PORTS                           NAMES
738ed14ec802        quay.io/coreos/hyperkube:v1.4.6_coreos.0   "/hyperkube proxy --m"   44 minutes ago      Up 44 minutes                                       k8s_kube-proxy.c445d412_kube-proxy-192.168.101.128_kube-system_438e3d01f328e73a199c6c0ed1f92053_10197c34

代理同样抱怨“没有链/目标/匹配该名称”。

我还验证了iptables链：

# Completed on Thu Dec  1 01:07:11 2016
# Generated by iptables-save v1.4.21 on Thu Dec  1 01:07:11 2016
*filter
:INPUT ACCEPT [4852:1419411]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5612:5965118]
:DOCKER - [0:0]
:DOCKER-ISOLATION - [0:0]
:KUBE-FIREWALL - [0:0]
:KUBE-SERVICES - [0:0]
-A INPUT -j KUBE-FIREWALL
-A FORWARD -j DOCKER-ISOLATION
-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 OUTPUT -j KUBE-SERVICES
-A OUTPUT -j KUBE-FIREWALL
-A DOCKER-ISOLATION -j RETURN
-A KUBE-FIREWALL -m mark --mark 0x8000/0x8000 -j DROP
COMMIT

这满足了错误消息（我认为）中的抱怨，并且匹配了无问题的coreos工作者（我与之比较的不同机器）上的过滤器链。

问题工作者是Debian Jessie运行docker 1.12.3和rkt 1.18.0

好工人和问题工作者都运行相同版本的iptables，1.4.21

KUBELET_VERSION = v1.4.6_coreos.0

症状是问题工作者的kubernetes没有安装任何iptables规则，比如KUBE-NODEPORTS，因此这个worker无法监听NodePort服务。我认为这是因为上述原因。

问题工作者在运行主节点计划的pod时没有问题。

问题工作者上的Pod正在从运行在不同（coreos）工作线程上的代理服务器上提交请求。

我正在使用法兰绒进行联网。

如果有人想知道，我需要让kubernetes在Debian上工作（是的，这是一个很长的故事）

我还能做些什么来隔离似乎没有看到主持人的iptables的kubelet？

Answer 1

经过多次故障隔离后，我找到了原因和解决方案。

就我而言，我正在运行自定义内核pkg（linux-image），它缺少与iptables相关的几个内核模块。因此，当kubelet试图附加包含注释的iptables规则时，它会出错，因为xt_comment没有被加载。

这些是我缺少的模块：ipt_REJECT，nf_conntrack_netlink，nf_reject_ipv4，sch_fq_codel（可能不需要），xt_comment，xt_mark，xt_recent，xt_statistic

为了获得我可能需要的完整模块列表，我登录了一个CoreOS kubernetes工作者并查看了它的lsmod。然后将该列表与我的问题进行比较＆＃34;机。

Answer 2

我在使用自定义内核配置的gentoo上遇到了这个问题，同时使用rancher的k3d 1.3.1运行k8。用所有合理的iptables + xt_comment重建内核为我解决了这个问题。

hyperkube代理，kubelet找不到iptables链，rkt run --net = host

2 个答案: