1

我的 kubelet 抱怨：

E1201 09:00:12.562610 28747 kubelet_network.go:365] 无法确保规则在过滤器链 KUBE-FIREWALL 中丢弃由 KUBE-MARK-DROP 标记的数据包：错误附加规则：退出状态 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 工作人员（我比较的不同机器）上的过滤器链。

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

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

KUBELET_VERSION=v1.4.6_coreos.0

症状是问题 worker 上的 kubernetes 没有安装任何 iptables 规则，例如 KUBE-NODEPORTS，因此该 worker 无法监听 NodePort 服务。我想是因为以上原因。

问题工作者运行主节点调度的 pod 没有问题。

问题工作人员上的 Pod 正在处理来自运行在不同（coreos）工作人员上的代理的请求。

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

如果有人想知道，我需要让 kubernetes 在 Debian 上工作（是的，说来话长）

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

4

2 回答 2

0

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

就我而言，我正在运行一个自定义内核 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 worker 并查看了它的lsmod. 然后将该列表与我的“问题”机器进行比较。

于 2016-12-10T01:40:42.333 回答
0

在使用 Rancher 的 k3d 1.3.1 运行 k8s 时，我在具有自定义内核配置的 gentoo 机器上遇到了这个问题。用所有健全的 iptables + xt_comment 重建内核为我解决了这个问题。

于 2019-09-03T11:15:18.273 回答