возможно ли подключить узел Kubernetes, используя публичный IP-адрес через разные зоны?

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

root@iZhp33cq6mvrjo8mzatgrmZ:~# kubeadm join 12.207.125.168:6443 --token nolo8x.fts42fpu3xdf6mks --discovery-token-ca-cert-hash sha256:ddd4f6797de24ad654731ddddd6a7a1e50af6b74fab3883cb9f75f

[preflight] Выполнение предварительных проверок
        [WARNING Hostname]: имя хоста "izhp33cq6mvrjo8mzatgrmz" не удалось достать
        [WARNING Hostname]: имя хоста "izhp33cq6mvrjo8mzatgrmz": поиск izhp33cq6mvrjo8mzatgrmz на 100.100.2.136:53: нет такого хоста
[preflight] Чтение конфигурации из кластера...
[preflight] FYI: Вы можете просмотреть этот конфигурационный файл с помощью 'kubectl -n kube-system get cm kubeadm-config -o yaml'
ошибка выполнения фазы preflight: невозможно получить ConfigMap kubeadm-config: не удалось получить конфигурационную карту: Получить "https://172.31.227.20:6443/api/v1/namespaces/kube-system/configmaps/kubeadm-config?timeout=10s": net/http: запрос отменен во время ожидания соединения (Client.Timeout

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

Возможность подключения узла Kubernetes через публичный IP адрес в разных дата-центрах

Введение в проблему

При попытке подключить новый облачный сервер из другого дата-центра к основной кластеру Kubernetes, у вас возникла проблема с ошибкой, указывающей на недоступность необходимых ресурсов кластера. Эта ситуация довольно распространена и связана с несколькими ключевыми аспектами настройки Kubernetes в распределённых системах.

Анализ действия

Используемая вами команда для присоединения к кластеру:

kubeadm join 12.207.125.168:6443 --token nolo8x.fts42fpu3xdf6mks --discovery-token-ca-cert-hash sha256:ddd4f6797de24ad654731ddddd6a7a1e50af6b74fab3883cb9f75f

Сообщение об ошибке указывает на следующие проблемы:

1. Доступность узла:

   • Сообщение [WARNING Hostname]: hostname "izhp33cq6mvrjo8mzatgrmz" could not be reached говорит о том, что узел не может разрешить своё собственное имя. Это может быть связано с неправильной настройкой DNS или отсутствием записи для этого имени.

2. Доступ к API-серверу:

   • Ошибка error execution phase preflight: unable to fetch the kubeadm-config ConfigMap указывает на то, что новый узел не может подключиться к API-серверу кластера по адресу 172.31.227.20, который, как вы отметили, находится в другом дата-центре.

Подходы к решению

1. Использование публичного IP адреса

В таких случаях часто рекомендуется использовать публичный IP адрес для вашего API-сервера, чтобы любой узел в различных дата-центрах мог к нему подключиться. Вы можете сделать следующее:

• Измените IP-адрес API-сервера:

  • Убедитесь, что ваш основной кластер настроен так, чтобы API-сервер использовал публичный IP адрес в качестве advertise address (рекламируемый адрес). Это можно сделать через конфигурацию kube-apiserver.

• Настройка сетевой доступности:

  • Убедитесь, что ваш публичный IP адрес доступен, и у него открыты все необходимые порты (в данном случае 6443 для API-сервера).

2. Настройка etcd

Подключение к etcd тоже требует внимания:

• Прямое подключение etcd:

  • Если ваш новый узел должен взаимодействовать с etcd напрямую, убедитесь, что etcd доступен через публичный IP адрес. Это означает, что конфигурация etcd также должна быть изменена для использования публичного IP адреса, если это необходимо.

• Сетевые правила:

  • Проверьте правила брандмауэра и сети, чтобы убедиться, что соединение разрешается с вашего нового дата-центра.

3. Тестирование подключений

После внесения изменений важно проверить возможность подключения:

• Используйте утилиты вроде curl или telnet, чтобы проверить доступность вашего API-сервера по публичному IP. Например:

curl -k https://12.207.125.168:6443/version

Заключение

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

Будьте внимательны при внесении изменений в настройки безопасности и конфиденциальности данных, особенно при использовании публичных IP адресов. Следуйте лучшим практикам и убедитесь, что ваша стратегия отвечает требованиям безопасности и устойчивости кластера.