Мой кубелет жалуется:
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, kind = host, source = / var / log \
--mount volume = var-log, target = / var / log \ --volume dns, kind = host, источник = / 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 с запущенным докером 1.12.3 и rkt 1.18.0.
И хороший, и проблемный исполнитель используют одну и ту же версию iptables, 1.4.21.
KUBELET_VERSION = v1.4.6_coreos.0
Симптомом является то, что kubernetes на проблемном рабочем сервере не устанавливает никаких правил iptables, таких как KUBE-NODEPORTS, и поэтому этот рабочий не может прослушивать службы NodePort. Думаю, это из-за вышеизложенного.
У проблемного воркера нет проблем с запуском модулей, которые планирует главный узел.
Модули проблемного воркера обслуживают запросы OK от прокси, запущенного на другом (coreos) воркере.
Я использую фланель для работы в сети.
Если кому-то интересно, мне нужно заставить кубернеты работать над Debian (да, это долгая история)
Что еще я могу сделать, чтобы изолировать то, что кажется kubelet не видит iptables хоста?
