Прокси-сервер hyperkube, kubelet не может найти цепочку iptables, rkt run --net=host
Мой кубелет жалуется:
E1201 09: 00: 12.562610 28747 kubelet_network.go: 365] Не удалось обеспечить правило для отбрасывания пакета, помеченного KUBE-MARK-DROP, в цепочке фильтров KUBE-FIREWALL: правило добавления ошибки: состояние выхода 1: iptables: нет цепочки / цели / совпадения под этим именем
Обычно это происходит, когда вы забыли запустить rkt с --net-host, но я этого не сделал.
export RKT_OPTS = "- том var-log, вид = хост, источник = / var / log \
--mount volume = var-log, target = / var / log \ --volume dns, kind = host, source = / etc / resolv.conf \ --mount volume = dns, target = / etc / resolv.conf - -сетью = хозяин"
Следующее подтверждает, что мой 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, и поэтому этот работник не может прослушивать службы NodePort. Я думаю, что это из-за вышеизложенного.
У проблемного работника нет проблем с запуском модулей, запланированных главным узлом.
Модули проблемного работника обслуживают запросы в порядке от прокси-сервера, работающего на другом (coreos) работнике.
Я использую фланель для общения.
Если кому-то интересно, мне нужно, чтобы kubernetes работал над Debian (да, это длинная история)
Что еще я могу сделать, чтобы изолировать то, что кажется kubelet, не видя iptables хоста?
1 ответ
У меня была эта проблема на коробке gentoo с настраиваемой конфигурацией ядра при запуске k8s с использованием k3d 1.3.1. Пересборка ядра со всеми вменяемыми iptables + xt_comment решила эту проблему для меня.
После значительной изоляции отказов я нашел причину и решение.
В моем случае я использую пользовательское ядро 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, Тогда просто сравнил этот список с моей "проблемной" машиной.