Почему мои сетевые подключения отклоняются, и команда ping между серверами не работает?

Вопрос или проблема

kubectl version
Client Version: v1.29.14
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.14
Cloud being used: bare-metal
Installation method:
Host OS: AlmaLinux 8
CNI and version: Flannel ver: 0.26.4
CRI and version: cri-dockerd ver: 0.3.16

[root@worker-1 ~]# kubectl get nodes -o wide
E0308 19:38:31.027307   59324 memcache.go:265] couldn't get current server API group list: Get "https://198.58.126.88:6443/api?timeout=32s": dial tcp 198.58.126.88:6443: connect: connection refused
E0308 19:38:32.051145   59324 memcache.go:265] couldn't get current server API group list: Get "https://198.58.126.88:6443/api?timeout=32s": dial tcp 198.58.126.88:6443: connect: connection refused
E0308 19:38:33.075350   59324 memcache.go:265] couldn't get current server API group list: Get "https://198.58.126.88:6443/api?timeout=32s": dial tcp 198.58.126.88:6443: connect: connection refused
E0308 19:38:34.099160   59324 memcache.go:265] couldn't get current server API group list: Get "https://198.58.126.88:6443/api?timeout=32s": dial tcp 198.58.126.88:6443: connect: connection refused
E0308 19:38:35.123011   59324 memcache.go:265] couldn't get current server API group list: Get "https://198.58.126.88:6443/api?timeout=32s": dial tcp 198.58.126.88:6443: connect: connection refused
Подключение к серверу 198.58.126.88:6443 было отклонено - правильно ли указан хост или порт?

[root@worker-1 ~]# ping 198.58.126.88
PING 198.58.126.88 (198.58.126.88) 56(84) bytes of data.
From 198.58.126.88 icmp_seq=1 Destination Port Unreachable
From 198.58.126.88 icmp_seq=2 Destination Port Unreachable
From 198.58.126.88 icmp_seq=3 Destination Port Unreachable

Ответ или решение

Отказ в подключениям в сети и невозможность выполнения команды ‘ping’ между серверами может быть вызвана несколькими факторами, связанными с сетевой конфигурацией, конфигурацией кластера, а также настройками безопасности. В данном случае, учитывая предоставленные данные, можно выделить несколько вероятных причин:

Теория

1. Фаерволл и сетевые правила:
   Если до выполнения команды kubeadm join пинг между нодами работал, но после выполнения этой команды перестал, возможно, причина в изменениях, которые повлияли на сетевые правила, например, конфигурация брандмауэра.

2. Ошибка в конфигурации кластера:
   Проблемы могут возникать из-за неправильной конфигурации Kubernetes, особенно если CNI-плагин неправильно настроен или был некорректно установлен.

3. Конфликт IP-адресов:
   Конфликты IP-адресов могут блокировать сетевой трафик между нодами. При добавлении новой рабочей ноды в кластер возможно возникновение таких конфликтов.

4. Аварийное состояние или сбой в службах:
   Диагностируемая проблема с отказом соединения может быть следствием сбоя в работе основных служб кластера, таких как kubelet, api-server или инфра-сеть.

Пример

Исходя из указанного лога ошибок, доступ к серверу API Kubernetes отказывается с ошибкой соединения connection refused, а также пинг заканчивается сообщением Destination Port Unreachable, указывающие на наличие проблем на уровне IP-маршрутизации или сетевых фильтров.

Применение

1. Проверка конфигурации фаерволла:
   Проверьте текущую конфигурацию файерволла на обеих нодах. Убедитесь в этом, выполнив команды, как iptables -L или firewalld, в зависимости от используемого вами решения. Убедитесь, что порт 6443 на сервере открыт для входящих соединений.

2. Проверка службы kubelet и служб сети:
   На обеих нодах выполните systemctl status kubelet и systemctl status flanneld для проверки состояния соответствующих служб. Если они не работают, попытайтесь перезапустить их с помощью systemctl restart.

3. Проверьте логи и статусы pod’ов в кластере:
   kubectl get pods -A и kubectl logs <pod-name> -n kube-system могут дать понимание о сбоях в подах сетевого уровня, таких как flannel, которые ответственны за связь между нодами.

4. Проверка конфигурации сети:
   Настройте и проверьте конфигурацию CNI. Убедитесь, что Flannel правильно сконфигурирован и все необходимые конфигурационные файлы присутствуют и действительны.

5. Коллизия IP-адресов:
   Проверьте конфигурацию IP-адресации на всех интерфейсах нод. Если они настроены статически, убедитесь, что нет конфликтующих IP-адресов.

6. Трассировка и диагностика трафика:
   Используйте такие инструменты, как traceroute и tcpdump, чтобы отследить сеть на наличие неверно маршрутизированного трафика или блокировок.

Решение сетевых проблем в кластере Kubernetes, особенно на bare-metal, может требовать углубленного анализа и понимания сетевой инфраструктуры, конфигураций и взаимодействий сервисов Kubernetes. Каждый шаг здесь требует аккуратного выполнения и уточнения, чтобы учесть все возможные аспекты.