Я пытаюсь выполнить чистую установку Kubernetes 1.23.x в кластере из четырех Raspberry Pi, каждый из которых работает под управлением x64-версии ОС Raspberry Pi, однако я сталкиваюсь с серьезной проблемой, как только пытаюсь запустить инициализация кубеадм на главном узле (еще до того, как попытаться подключить другие узлы). А именно: всего через пять минут после звонка инициализация кубеадм на главном узле кластер перестает работать. На самом деле, это никогда не работает с самого начала. Сначала сервер отвечает, что узел NotReady, но через 5 минут вообще перестает отвечать.
Итак, вот что я сделал и что увидел: я установил containerd и kubeadm. Затем я запускаю следующую команду на главном узле, чтобы попытаться запустить Kubernetes:
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
--token-ttl=0 --apiserver-advertise-address=192.168.1.194
После запуска этой команды и последующего копирования файла /etc/kubernetes/admin.conf в ~/.kube/config я могу выполнить следующую команду:
$ kubectl получить узлы
ИМЯ СТАТУС РОЛИ ВОЗРАСТ ВЕРСИЯ
k8s-master-1 NotReady control-plane, master 3m36s v1.23.4
И он будет продолжать показывать статус NotReady в течение примерно 5 минут, после чего та же команда дает совсем другой результат:
$ kubectl получить узлы
В соединении с сервером 192.168.1.194:6443 было отказано - вы указали правильный хост или порт?
Я не уверен, почему это происходит, но это очень последовательно. Я уже несколько раз пытался сброс кубеадм а потом инициализация кубеадм снова, и тайм-аут соединения всегда происходит на 5-минутной отметке. Итак, в последний раз, когда я пытался это сделать, я решил спрятать все файлы журналов под /var/лог/контейнеры/. После 5-минутной отметки он неоднократно регистрирует некоторые варианты ошибок подключения к 127.0.0.1:2379. Например:
2022-03-09T19:30:29.307156643-06:00 stderr F W0310 01:30:29.306871 1 clientconn.go:1331] [ядро] grpc: addrConn.createTransport не удалось подключиться к {127.0.0.1:2379 127.0.0.1 0 }. Err: ошибка соединения: desc = "транспорт: ошибка при наборе номера tcp 127.0.0.1:2379: соединение: соединение отклонено". Повторное подключение...
Из Google видно, что на этом порту работает etcd, но через 5 минут несколько служб (включая etcd) начинают отключаться. Я загрузил полные журналы с того времени инициализация кубеадм работает, вплоть до страшной 5-минутной отметки, как суть.
Я уже проверил, что все порты тоже открыты. (Они есть.) В течение этих первых пяти минут я могу подключиться к локальному порту 2379 по телнету. Почему Kubernetes не запускается на моем Pi? Что мне не хватает?
ОБНОВИТЬ: В соответствии с просьбой, я могу предоставить более подробную информацию. Я видел сообщение, рекомендующее установить значение --apiserver-рекламный-адрес к 0.0.0.0 вместо прямого IP, поэтому я попробовал это, но, похоже, это не имело значения. я пытался бежать статус systemctl кубелет который показывает, что служба kubelet «активна» в течение этого начального 5-минутного периода.
я тоже побежал kubectl описывает узел k8s-master-1, который показывает четыре события в этой последовательности:
- KubeletHasSufficientMemory
- KubeletHasNoDiskPressure
- KubeletHasSufficientPID
- KubeletNotReady
Это последнее событие сопровождается этим сообщением: «Сеть среды выполнения контейнера не готова: NetworkReady = false, причина: сообщение NetworkPluginNotReady: сетевой плагин возвращает ошибку: плагин cni не инициализирован». Так что это заставило меня задуматься. Я ждал, пока узел перейдет в состояние готовности, прежде чем устанавливать Flannel (также известный как плагин CNI), но на этот раз я решил попробовать установить Flannel в течение этого начального 5-минутного периода, используя эту команду:
kubectl применить -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
И, к моему большому удивлению, это сработало! Ну вроде. Главный узел в конце концов начал сообщать о состоянии «Готово».И я заметил, что все мои стручки подошли с заметным исключением стручков coredns. Однако через некоторое время модуль kube-proxy (в пространстве имен kube-system) умирает и застревает в CrashLoopBackoff, а еще позже модули kube-controller-manager и kube-scheduler аналогичным образом входят в CrashLoopBackoff. Затем, на этот раз, примерно через 15 минут, весь кластер снова умер, как и раньше (это означает, что я получил то же сообщение «отказано в подключении к серверу»). Так что я чувствую, что я немного ближе, но все еще далек от того, чтобы заставить это работать.
ВТОРОЕ ОБНОВЛЕНИЕ: Пара вещей: кажется, что когда я устанавливаю плагин CNI для фланели, coredns либо не включается, либо не работает. Но когда я устанавливаю Weave Works CNI, он, по крайней мере, пытается раскрутить coredns, хотя, к сожалению, эти модули застревают в ContainerCreating и никогда не активируются. Поэтому по запросу я предоставляю ряд дополнительных журналов. Они достаточно длинные, чтобы загружать их отдельно, так что вот ссылка на гист содержащий четыре журнала:
- Бег
kubectl -n kube-системные журналы pod/coredns-...
- Бег
kubectl -n kube-system logs pod/kube-controller-manager-k8s-master-1
- Бег
kubectl -n kube-system logs pod/kube-proxy-...
- Бег
kubectl описывает узел k8s-master-1
Обратите внимание, что перед тем, как все умрет, модуль kube-controller-manager-... запускается, но вскоре оказывается в CrashLoopBackoff. В то время как модули coredns вообще никогда не запускаются успешно.
