Круговая проблема – тупик при запуске кластера с использованием kubeadm [закрыто]

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

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"

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

Отвечая на вопрос о проблемах с запуском кластера Kubernetes с использованием kubeadm, особенно когда речь идет о "deadlock" состояниях, связанных с инициализацией CNI (Calico) и невозможностью подключиться к API, важно подходить комплексно. Давайте рассмотрим теоретическую сторону проблемы, проанализируем предоставленный пример и рассмотрим практические шаги для ее решения.

Теория

Проблема "deadlock" в Kubernetes:

В контексте Kubernetes, "deadlock" состояние может возникать, когда различные компоненты системы зависят друг от друга для правильной работы, но из-за ошибок или несоответствий, они не могут вовремя инициализироваться или установить соединение, что приводит к циклическим зависимостям. В данной проблеме CNI (Calico) и API сервер находятся в таком цикле: для полного запуска API требуется инициализация сетевого плагина CNI, а для работы CNI требуется доступность API.

Ключевые компоненты и их роли:

1. kube-apiserver — основной интерфейс взаимодействия с кластером. Отвечает за прием всех REST-запросов и посредничает между другими компонентами.

2. etcd — надежное хранилище, которое используется Kubernetes для хранения всех объектов данных.

3. CNI (Container Network Interface) — сетевой плагин, который обеспечивает подам сетевое взаимодействие. В данном случае, это Calico.

4. Kubelet — агент на каждом узле, который получает инструкции от API и управляет жизненным циклом контейнеров.

Сетевая инфраструктура и настройки:

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

Пример

На основании предоставленных логов можно сделать следующие наблюдения:

1. Ошибка CNI: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized указывает, что CNI плагин не был инициализирован должным образом, что препятствует позиционированию сети.

2. Проблемы подключения к API: Ошибки, такие как dial tcp 192.168.124.8:6443: connect: connection refused, свидетельствуют о том, что kubelet не может подключиться к API серверу, что может быть связано с сетевыми проблемами или с невозможностью самого сервера работать стабильно в условиях отсутствия CNI.

Применение

Практические шаги для решения проблемы:

1. Проверка и настройка Calico: Убедитесь, что конфигурация Calico правильно сформирована. Сетевые политики и определения должны соответствовать заявленным субсетям IP и быть согласованы с сетью etcd.

2. Конфигурация и диагностика API: Убедитесь, что API сервер доступен и корректно настроен. Проверьте firewall и настройки безопасности (например, SELinux или AppArmor), которые могут блокировать порты.

3. Проверка сертификатов и авторизации: Убедитесь, что сертификаты, использующиеся для взаимного TLS, не истекли и корректны. Неправильные сертификаты могут привести к отказу соединения.

4. Проверка времени и синхронизации: Убедитесь, что системное время на всех узлах синхронизировано через NTP. Разница во времени может приводить к проблемам авторизации по причине несоответствия временной отметки.

5. Логи и диагностика: Изучите более детализированные логи Кубернетеса: kube-proxy, kube-controller-manager, и kube-scheduler, чтобы выявить любые другие проблемы, которые могут указывать на основную причину deadlock состояния.

6. Изоляция проблемы: Попробуйте инициализировать минимальный кластер без использования Calico, чтобы определить, возникает ли проблема только при включении сетевого плагина. Это поможет выяснить, связана ли проблема напрямую с CNI или есть другие факторы.

Таким образом, проблема deadlock при запуске кластера Kubernetes с использованием kubeadm и Calico CNI связана, в основном, с циклическими зависимостями компонентов, требованиям к сетевой конфигурации и инициализации сервисов. Основательное изучение логов, корректная конфигурация сети и компонентов, а также корректная установка и обновление всех необходимых конфигураций помогут устранить возникшую проблему.