Kubernetes на основе kubeadm. Получите «https://10.96.0.1:443/api?timeout=32s»: наберите TCP 10.96.0.1:443: подключитесь: нет маршрута к хосту
Я развернул кластер kubernetes v1.24.3 на базе kubeadm, который состоит из одного узла плоскости управления и трех рабочих узлов (все виртуальные машины Centos 7). Все они расположены «локально» на одном физическом узле.
В этой настройке я пытаюсь развернуть сетевое подключение CNI, но контейнеры поставщика CNI не работают на рабочих узлах, в журналах kubectl сообщается об ошибке: «Получить https://10.96.0.1:443/api?timeout=32s». «: наберите TCP 10.96.0.1:443: подключитесь: нет маршрута к хосту».
Модуль, развернутый на узле плоскости управления, работает без ошибок.
Такое поведение наблюдается при установке тигра-оператора Calico или сети Weave. Weave-net развертывает DaemonSet, модуль которого на узле плоскости управления работает успешно, но модули, развернутые на рабочих узлах, завершаются сбоем из-за описанной выше ошибки.
Для тигрового оператора Calico на одном из рабочих узлов развертывается один модуль, но это тоже не удается из-за ошибки, указанной выше.
Когда я подключаюсь по SSH к узлу плоскости управления и даю команду «nc -w 2 -v 10.96.0.1 443», я подключаюсь. Когда я пытаюсь ввести ту же команду на любом из рабочих узлов, соединение не устанавливается, и я получаю сообщение «Ncat: время ожидания соединения истекло».
Должен ли я вручную настроить маршрутизацию 10.96.0.1 на узлах плоскости управления с рабочих узлов, если да, то как мне это сделать? В моей настройке узел плоскости управления имеет IP-адрес 192.168.12.17, а один из рабочих узлов имеет IP-адрес 192.168.12.20.
1 ответ
Это сообщение об ошибке означает, что узлы не могут получить доступ к API Kubernetes внутри кластера. Это означает, что некоторый трафик между узлами и плоскостью управления где-то заблокирован.
Вероятно, это связано с конфигурациями сетевого интерфейса, конфигурацией kubeadm (относительно IP-адресов) и, наконец, конфигурациями брандмауэра.
Что сработало для меня, так это то, что я впервые заметил, что все начало работать, когда я отключил все брандмауэры. Затем шаг за шагом возвращаюсь к безопасной конфигурации, пока что-то не сломается. Используя ufw, его журналы сообщали мне, какой трафик проходит через общедоступный интерфейс, а не через частную сеть. Решением оказалось отсутствие набора параметров в InitConfiguration:
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
...
nodeRegistration:
kubeletExtraArgs:
"node-ip": "<insert the controllers private ip here>"
localAPIEndpoint:
advertiseAddress: "<insert the controllers private ip here>"
bindPort: 6443
При настройке высокой доступности не забудьте также добавить эти строки в часть JoinConfiguration -> controlPlane для дополнительных контроллеров.