Вопрос или проблема
Я пытаюсь установить k8s1.26 на debian11, моя версия ядра 5.10.0/x86_64. Вот мои журналы kubelet.
Мар 09 17:51:55 devnew0 kubelet[369024]: I0309 17:51:55.933659 369024 scope.go:115] "RemoveContainer" containerID="4ace1812ec7d981b55a51f422287499bdacf240e7c739d50872e6de1892fa7a2"
Мар 09 17:51:55 devnew0 kubelet[369024]: E0309 17:51:55.934416 369024 pod_workers.go:965] "Error syncing pod, skipping" err="failed to \"StartContainer\" for \"etcd\" with CrashLoopBackOff: \"back-off 10s restarting failed container=etcd pod=etcd-devnew0_kube-system(419ed404bfcd79b143181759583871d1)\"" pod="kube-system/etcd-devnew0" podUID=419ed404bfcd79b143181759583871d1
kubectl не работал.
E0309 18:06:07.103712 375368 memcache.go:238] couldn't get current server API group list: Get "https://162.105.85.70:6443/api?timeout=32s": dial tcp 162.105.85.70:6443: connect: connection refused
E0309 18:06:07.104510 375368 memcache.go:238] couldn't get current server API group list: Get "https://162.105.85.70:6443/api?timeout=32s": dial tcp 162.105.85.70:6443: connect: connection refused
E0309 18:06:07.106487 375368 memcache.go:238] couldn't get current server API group list: Get "https://162.105.85.70:6443/api?timeout=32s": dial tcp 162.105.85.70:6443: connect: connection refused
E0309 18:06:07.108326 375368 memcache.go:238] couldn't get current server API group list: Get "https://162.105.85.70:6443/api?timeout=32s": dial tcp 162.105.85.70:6443: connect: connection refused
E0309 18:06:07.110263 375368 memcache.go:238] couldn't get current server API group list: Get "https://162.105.85.70:6443/api?timeout=32s": dial tcp 162.105.85.70:6443: connect: connection refused
The connection to the server 162.105.85.70:6443 was refused - did you specify the right host or port?
critctl ps -a
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
dde80047d3aff 240e201d5b0d8 34 seconds ago Exited kube-controller-manager 131 fc8b51e8b4b44 kube-controller-manager-devnew0
d4157ed07257b 63d3239c3c159 2 minutes ago Exited kube-apiserver 128 96cad2187e463 kube-apiserver-devnew0
5910c6fb6fe53 fce326961ae2d 4 minutes ago Exited etcd 134 1fb01d0ecc4de etcd-devnew0
d635e40f9aade 6f64e7135a6ec 5 minutes ago Exited kube-proxy 114 c6c2597e5097a kube-proxy-2zmq7
e87d4f6d34e6d db8f409d9a5d7 5 minutes ago Exited kube-scheduler 143 0afe7b6d78151 kube-scheduler-devnew0
Я решил эту проблему. Я использовал некоторые устаревшие поля в /etc/containerd/config.toml, что вызывало неправильную работу некоторых узлов. И спасибо за ваш ответ.
@caiji233 какие устаревшие поля вы определили?
.
Ответ или решение
Установка Kubernetes версии 1.26 на системе Debian 11 с использованием инструмента kubeadm может сопровождаться различными техническими вызовами, особенно если кластер не запускается корректно, а все поды, включая etcd и kube-proxy, оказываются в состоянии CrashLoopBackOff. В данном случае проблема усугубляется также тем, что kubectl не удается подключиться к API-серверу, поскольку соединения на указанный порт отказано.
Теория
Когда поды находятся в состоянии CrashLoopBackOff, это указывает на то, что они постоянно перезапускаются из-за ошибок. Это состояние может быть связано с рядом причин, таких как неправильное конфигурирование, проблема с образами контейнеров или проблемы, связанные с сетью. В случае компонента etcd, который является ключевым для работы мастера Kubernetes, причины отказа могут быть связаны с неправильной конфигурацией или недоступностью необходимых ресурсов.
Кроме того, отказ в соединении с API-сервером может указывать на более сложные проблемы в конфигурации сети или наличии ошибки в настройках API-сервера, которые мешают установлению стабильного соединения. Это также может быть следствием ошибок в самой конфигурации etcd, если кластер не может установить работу хранилища данных.
Пример
В предоставленных логах видны явные указания на состояние CrashLoopBackOff у компонентов etcd и kubernetes-менеджмента, такими как kube-proxy, и другие. Проблемы с контейнерами и подами могут возникнуть в следующих случаях:
-
Неправильная конфигурация: Например, устаревкие поля в файле конфигурации
/etc/containerd/config.toml, как было замечено в этом конкретном случае. -
Проблемы с сетью: Ошибки подключения к API-серверу также могут указывать на проблемы с сетевым доступом или межсетевыми экранами, блокирующими необходимые порты.
-
Несоответствие версий: В тех значимых случаях, конфликты версий компонентов (например, kubelet, kube-proxy и т.д.) могут вызывать нестабильность.
Применение
Для устранения проблемы необходимо подойти пошагово:
-
Проверка конфигурации контейнерного окружения:
- Убедитесь, что файл
/etc/containerd/config.tomlне содержит устаревшие или ошибочные параметры. Устаревшие поля могут вызывать несовместимость между компонентами Kubernetes.
- Убедитесь, что файл
-
Анализ сетевых подключений:
- Проверьте конфигурацию сетевого межсетевого экрана. Убедитесь, что порты, необходимые для функционирования Kubernetes, такие как 6443 (API-сервер), открыты для необходимого трафика.
- Убедитесь, что корректно настроены основные сетевые интерфейсы, и DNS может правильно разрешать имена узлов.
-
Логи и мониторинг:
- Используйте
journalctl -u kubeletдля детального просмотра логов службы kubelet. - Рассмотрите использование
kubectl describe pod <имя_пода>для получения более детальной информации о том, почему поды могут не работать.
- Используйте
-
Релогирование и перезапуск:
- Если внесены изменения в конфигурацию, перезапустите соответствующие службы, чтобы изменения вступили в силу, и убедитесь в пересоздании непрерывно работающих контейнеров.
-
Обновление компонентов:
- Проведите проверку на наличие обновлений для ваших компонентов Kubernetes и убедитесь, что все компоненты имеют совместимые версии.
Учитывая эти шаги и их реализацию на практике, вы сможете создать рабочую среду Kubernetes, где все системные компоненты будут работать корректно. Устранение основной проблемы с конфигурацией является ключом к установлению стабильности и функциональности для вашего кластера.