Вопрос или проблема
Я следовал официальной документации на
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/
Проблема в том, что я развернул calico:
POD ID CREATED STATE NAME NAMESPACE ATTEMPT RUNTIME
6f693e90c6d20 29 секунд назад Ready kube-proxy-f8rc4 kube-system 7 (default)
1a50c48dcfee9 Около минуты назад Ready kube-scheduler-k8s kube-system 5 (default)
8cace930935ca Около минуты назад Ready kube-controller-manager-k8s kube-system 3 (default)
1db40862eccaf 2 минуты назад Ready tigera-operator-ccfc44587-vjdrs tigera-operator 3 (default)
504e4b6447e89 3 минуты назад Ready etcd-k8s kube-system 7 (default)
409c2195fe24a 4 минуты назад NotReady kube-proxy-f8rc4 kube-system 6 (default)
60cc9f215e480 5 минут назад Ready kube-apiserver-k8s kube-system 2 (default)
56646137a2a85 6 минут назад NotReady etcd-k8s kube-system 6 (default)
0cb3cfd02fc22 6 минут назад NotReady kube-scheduler-k8s kube-system 4 (default)
2f5720155ecfc 6 минут назад NotReady tigera-operator-ccfc44587-vjdrs tigera-operator 2 (default)
ff0dba559f69f 13 минут назад NotReady kube-controller-manager-k8s kube-system 2 (default)
root@k8s:~#
И оно постоянно перезапускается.
Mar 16 01:48:44 k8s kubelet[1720]: E0316 01:48:44.801833 1720 kubelet.go:3002] "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized"
Mar 16 01:48:45 k8s kubelet[1720]: I0316 01:48:45.661566 1720 pod_container_deletor.go:80] "Container not found in pod's containers" containerID="504e4b6447e89391590d61a1632f9bbc8a804d7e3ce79e87f8e5657cc1627d9e"
Mar 16 01:48:45 k8s kubelet[1720]: I0316 01:48:45.662074 1720 status_manager.go:890] "Failed to get status for pod" podUID="6bd6965193b13475a79daa0b3843be87" pod="kube-system/kube-scheduler-k8s" err="Get \"https://192.168.124.8:6443/api/v1/namespaces/kube-system/pods/kube-scheduler-k8s\": dial tcp 192.168.124.8:6443: connect: connection refused"
Он не может инициализировать CNI, потому что не может подключиться к API, не может запустить API, потому что CNI не инициализирован. Проблема CNI -> проблема API -> проблема CNI -> проблема API. Бесконечно.
Это кажется мне тупиковой ситуацией. Я следовал официальной документации, но это действительно неясно.
В чем может быть проблема?
Ответ или решение
Отвечая на вопрос о проблемах с запуском кластера Kubernetes с использованием kubeadm, особенно когда речь идет о "deadlock" состояниях, связанных с инициализацией CNI (Calico) и невозможностью подключиться к API, важно подходить комплексно. Давайте рассмотрим теоретическую сторону проблемы, проанализируем предоставленный пример и рассмотрим практические шаги для ее решения.
Теория
Проблема "deadlock" в Kubernetes:
В контексте Kubernetes, "deadlock" состояние может возникать, когда различные компоненты системы зависят друг от друга для правильной работы, но из-за ошибок или несоответствий, они не могут вовремя инициализироваться или установить соединение, что приводит к циклическим зависимостям. В данной проблеме CNI (Calico) и API сервер находятся в таком цикле: для полного запуска API требуется инициализация сетевого плагина CNI, а для работы CNI требуется доступность API.
Ключевые компоненты и их роли:
-
kube-apiserver — основной интерфейс взаимодействия с кластером. Отвечает за прием всех REST-запросов и посредничает между другими компонентами.
-
etcd — надежное хранилище, которое используется Kubernetes для хранения всех объектов данных.
-
CNI (Container Network Interface) — сетевой плагин, который обеспечивает подам сетевое взаимодействие. В данном случае, это Calico.
-
Kubelet — агент на каждом узле, который получает инструкции от API и управляет жизненным циклом контейнеров.
Сетевая инфраструктура и настройки:
В Kubernetes, правильная конфигурация сети является критической. Это означает, что конфигурации CNI должны быть верно настроены, а все узлы кластера должны иметь возможность общаться с API-сервером без перебоев.
Пример
На основании предоставленных логов можно сделать следующие наблюдения:
-
Ошибка CNI:
NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
указывает, что CNI плагин не был инициализирован должным образом, что препятствует позиционированию сети. -
Проблемы подключения к API: Ошибки, такие как
dial tcp 192.168.124.8:6443: connect: connection refused
, свидетельствуют о том, что kubelet не может подключиться к API серверу, что может быть связано с сетевыми проблемами или с невозможностью самого сервера работать стабильно в условиях отсутствия CNI.
Применение
Практические шаги для решения проблемы:
-
Проверка и настройка Calico: Убедитесь, что конфигурация Calico правильно сформирована. Сетевые политики и определения должны соответствовать заявленным субсетям IP и быть согласованы с сетью etcd.
-
Конфигурация и диагностика API: Убедитесь, что API сервер доступен и корректно настроен. Проверьте firewall и настройки безопасности (например, SELinux или AppArmor), которые могут блокировать порты.
-
Проверка сертификатов и авторизации: Убедитесь, что сертификаты, использующиеся для взаимного TLS, не истекли и корректны. Неправильные сертификаты могут привести к отказу соединения.
-
Проверка времени и синхронизации: Убедитесь, что системное время на всех узлах синхронизировано через NTP. Разница во времени может приводить к проблемам авторизации по причине несоответствия временной отметки.
-
Логи и диагностика: Изучите более детализированные логи Кубернетеса:
kube-proxy
,kube-controller-manager
, иkube-scheduler
, чтобы выявить любые другие проблемы, которые могут указывать на основную причину deadlock состояния. -
Изоляция проблемы: Попробуйте инициализировать минимальный кластер без использования Calico, чтобы определить, возникает ли проблема только при включении сетевого плагина. Это поможет выяснить, связана ли проблема напрямую с CNI или есть другие факторы.
Таким образом, проблема deadlock при запуске кластера Kubernetes с использованием kubeadm и Calico CNI связана, в основном, с циклическими зависимостями компонентов, требованиям к сетевой конфигурации и инициализации сервисов. Основательное изучение логов, корректная конфигурация сети и компонентов, а также корректная установка и обновление всех необходимых конфигураций помогут устранить возникшую проблему.