Мы запускаем наши приложения в кластере Kubernetes (1.11), установленном через KOps (это наш кластер DEV/QA, унаследованный от сотрудника, который больше не работает в компании).
В основном все работает нормально, но иногда после развертывания
некоторые из модулей выдают ошибки отказа в соединении. Мы узнали об этом, потому что Nginx жаловался на ошибку 502 из бэкэнда.
Иногда он снова будет работать автоматически, но снова начнет выдавать ошибки. Перезапуск модуля решит проблему.
Он будет работать нормально до следующего развертывания, а затем проблема повторится.
Мы сравнили системный журнал с другим кластером, но все выглядит одинаково.
Журналы TCPDUMPS IP-адреса POD
11:06:47.387766 IP 100.96.13.22.57778 > 100.96.12.137.http-alt: Flags [S], seq 1515889791, win 26883, параметры [mss 8961,sackOK,TS val 132113284 ecr 0,nop,wscale 9], длина 0
11:06:47.387775 IP 100.96.13.22.57778 > 100.96.12.137.http-alt: Flags [S], seq 1515889791, win 26883, параметры [mss 8961,sackOK,TS val 132113284 ecr 0,nop,wscale 9], длина 0
11:06:47.387777 IP 100.96.13.22.57778 > 100.96.12.137.http-alt: Flags [S], seq 1515889791, win 26883, параметры [mss 8961,sackOK,TS val 132113284 ecr 0,nop,wscale 9], длина 0
11:06:47.387781 IP 100.96.12.137.http-alt > 100.96.13.22.57778: флаги [R.], seq 0, ack 1515889792, win 0, длина 0
11:06:47.387781 IP 100.96.12.137.http-alt > 100.96.13.22.57778: флаги [R.], seq 0, ack 1, win 0, длина 0
11:06:47.387785 IP 100.96.12.137.http-alt > 100.96.13.22.57778: флаги [R.], seq 0, ack 1, win 0, длина 0
Как видно из журналов, модуль Ingress-nginx (100.96.13.22) пытается подключиться к модулю webapp (100.96.12.137), но подключение к модулям немедленно сбрасывается.
Наше расследование:
Узнав немного о том, как работает сеть kubernetes (сетевые мосты, пары VETH),
(https://medium.com/practo-engineering/networking-with-kubernetes-1-3db116ad3c98
https://stackoverflow.com/questions/37860936/find-out-what-network-interface-belongs-to-docker-container
https://www.digitalocean.com/community/tutorials/how-to-inspect-kubernetes-networking#finding-and-entering-pod-network-namespaces
)
В соответствии с этим интерфейс pods подключается через пару VETH к интерфейсу моста Nodes.
Любой трафик от пода или к нему проходит через этот мост (в нашем случае cbr0).
Исправление проблем:
Мы получили идентификатор контейнера затронутых модулей, запустив
докер пс
Получить идентификатор процесса пода
docker inspect --format '{{ .State.Pid }}' идентификатор контейнера
Получите подробную информацию о сети Pods
nsenter -t контейнер-pid -n IP-адрес
вывод:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
ссылка/петля 00:00:00:00:00:00 брд 00:00:00:00:00:00
инет 127.0.0.1/8 область хоста lo
valid_lft навсегда
inet6 :: 1/128 узел области видимости
valid_lft навсегда
3: eth0@if380852: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default
ссылка/эфир 0a:58:64:60:0d:27 brd ff:ff:ff:ff:ff:ff ссылка-netnsid 0
инет 100.96.13.39/24 область глобальная eth0
valid_lft навсегда
ссылка на область inet6 fe80::e4cd:81ff:fe96:2914/64
valid_lft навсегда
eth0@if380852Â — сетевой интерфейс модуля
380852Â — номер ссылки VETH
0а:58:64:60:0д:27Â — mac-адрес модуля
Получите информацию о паре VETH модуля
IP-адрес | группа 380852
вывод: 380852: vethd49cda8b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue master cbr0 state UP group default
Здесь vethd49cda8b — идентификатор VETH стручка
Теперь проверил детали моста
Получите таблицу Mac моста:
brctl showmacs cbr0 | грэп 0а:58:64:60:0д:27
вывод:27 0a:58:64:60:0d:27 нет 1.44
Здесь 27Â это ПОРТ интерфейса VETH
Проверены детали VETH порта.
brctl показывает stp cbr0 | греп "(27)"
вывод:
veth488082e8 (27)
Мы видим, что порт 27 принадлежит другому интерфейсу VETH. Ожидаемый результат должен быть таким:
VETH ID POD (ПОРТ в таблице мостов)
vethd49cda8b (27)
Позволяет получить фактический ПОРТ интерфейса VETH POD.
brctl показывает stp cbr0 | grep vethd49cda8b
вывод:
vethd49cda8b (52)
Мы видим, что трафик к модулям теряется из-за неправильного порта в таблице MAC-адресов моста.
В таблице MAC-адресов моста порт должен отображаться как 52 для MAC-адреса контейнера, но он показывает 27.
Но через некоторое время он автоматически показывает правильный порт, что решает нашу проблему с подключением.
Можно ли узнать, что обновляет таблицу мостов? и как избежать некорректных обновлений?
Как мы можем устранить неполадки дальше?
Кто-нибудь сталкивался с подобными проблемами.
Заранее спасибо, очень ценю любую помощь.
