Кластер Kubernetes в облаке Azure с ОС Red Hat 8.4 с kubeadm v1.30.8 – узлы coredns и calico застряли в неизвестном состоянии.

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

[root@master01 net.d]# kubectl get pods -n kube-system -o wide
NAME                                           READY   STATUS    RESTARTS       AGE   IP         NODE                   NOMINATED NODE   READINESS GATES
calico-kube-controllers-564985c589-m6ttv       0/1     Unknown   12             17d   <none>     master01.example.com   <none>           <none>
calico-node-lzcl8                              0/1     Unknown   12             17d   10.5.0.5   master01.example.com   <none>           <none>
calico-node-x5284                              0/1     Unknown   8              17d   10.5.0.4   worker01.example.com   <none>           <none>
coredns-55cb58b774-knfbm                       0/1     Unknown   12             17d   <none>     master01.example.com   <none>           <none>
coredns-55cb58b774-lj5mm                       0/1     Unknown   12             17d   <none>     master01.example.com   <none>           <none>
etcd-master01.example.com                      1/1     Running   2 (63m ago)    23h   10.5.0.5   master01.example.com   <none>           <none>
kube-apiserver-master01.example.com            1/1     Running   2 (63m ago)    23h   10.5.0.5   master01.example.com   <none>           <none>
kube-controller-manager-master01.example.com   1/1     Running   16 (63m ago)   17d   10.5.0.5   master01.example.com   <none>           <none>
kube-proxy-l8shz                               1/1     Running   15 (63m ago)   17d   10.5.0.5   master01.example.com   <none>           <none>
kube-proxy-p28ff                               1/1     Running   11 (64m ago)   17d   10.5.0.4   worker01.example.com   <none>           <none>
kube-scheduler-master01.example.com            1/1     Running   16 (63m ago)   17d   10.5.0.5   master01.example.com   <none>           <none>
[root@master01 net.d]#
[root@master01 net.d]# kubectl get pods -o wide
NAME                          READY   STATUS              RESTARTS   AGE     IP       NODE                   NOMINATED NODE   READINESS GATES
app-server-5f7d8f6d56-6vk68   0/1     Unknown             1          2d4h    <none>   worker01.example.com   <none>           <none>
app-server-5f7d8f6d56-x2zmc   0/1     Unknown             1          2d4h    <none>   worker01.example.com   <none>           <none>
debug                         0/1     ContainerCreating   0          5m54s   <none>   worker01.example.com   <none>           <none>
[root@master01 net.d]# kubectl get nodes -o wide
NAME                   STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                               KERNEL-VERSION
              CONTAINER-RUNTIME
master01.example.com   Ready    control-plane   17d   v1.30.8   10.5.0.5      <none>        Red Hat Enterprise Linux 8.4 (Ootpa)   4.18.0-305.82.1.el8_4.x86_64   containerd://1.7.25
worker01.example.com   Ready    <none>          17d   v1.30.8   10.5.0.4      <none>        Red Hat Enterprise Linux 8.4 (Ootpa)   4.18.0-305.82.1.el8_4.x86_64   containerd://1.7.25
[root@master01 net.d]#

[root@master01 net.d]# uname -a
Linux master01.example.com 4.18.0-305.82.1.el8_4.x86_64 #1 SMP Thu Feb 23 09:21:04 EST 2023 x86_64 x86_64 x86_64 GNU/Linux
[root@master01 net.d]#

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

Создание и управление Kubernetes кластером на платформе Azure с операционной системой Red Hat 8.4 и использованием kubeadm, coredns и Calico требуют серьезного подхода и внимания к деталям, особенно после переноса виртуальных машин из AWS в Azure. Проблема, связанная с тем, что узлы coredns и calico находятся в неизвестном состоянии, может быть вызвана различными факторами, начиная от сетевых проблем, заканчивая проблемами с конфигурацией Kubernetes. В данном разборе мы подробно рассмотрим возможные причины и шаги для устранения этой ситуации.

Теория (Theory)

Основные компоненты, такие как coredns и Calico в Kubernetes, ответственны за важные функции в кластере. CoreDNS выполняет функции DNS-сервера для внутренних сервисов кластера, в то время как Calico обеспечивает сетевую политику и интерфейсы для взаимодействия подов. Когда узлы или поды этих сервисов находятся в состоянии "Unknown", это указывает на проблемы с их запуском или взаимодействием с остальными компонентами кластера. Возможные причины могут включать:

1. Сетевые проблемы: После миграции сети могут быть неправильно сконфигурированы, связность между узлами может быть нарушена.
2. Проблемы с конфигурацией Kubelet или контейнерного рантайма: Неправильно настроенные параметры могут мешать узлам и подам обновлять свой статус.
3. Ошибки в конфигурации кластерных компонентов: Неправильные параметры в конфигурации Kubernetes могут вызвать некорректную работу подов.
4. Обновление или несовместимость версий: Несовместимость версий Red Hat, Kubernetes и компонентов может привести к проблемам при их взаимодействии.

Пример (Example)

Представим, что после миграции вы заметили, что connect и read таймауты в конфигурации Calico или служб DNS превышают ожидания, что указывает на потенциальные задержки в сети. Стандартным подходом будет диагностика сети между узлами для выявления проблем.

Применение (Application)

1. Диагностика сети

• Проверка сетевого взаимодействия: Убедитесь, что все узлы могут пинговать друг друга, и проверка сетевой маршрутизации успешна. Для этого используйте команды ping, traceroute и проверку правил межсетевых экранов (NSG) в Azure.

• Проверка конфигурации DNS: Убедитесь, что все звенья в цепочке DNS, включая резолверы, работают правильно. Используйте команду dig для проверки разрешения DNS из подов.

2. Проверка журналов и диагностика узлов

• Журналы системных служб: Просмотрите журналы служб kubelet и контейнерного рантайма на каждом из узлов с помощью journalctl для обнаружения ошибок и предупреждений.

• Лога Calico и CoreDNS: Используйте команду kubectl logs для извлечения журналов подов calico и coredns, чтобы проверить, какие ошибки или исключения происходят.

3. Проверка конфигурации Kubelet и контейнерного рантайма

• Конфигурация Kubelet: Убедитесь, что на всех узлах используются корректные kubelet конфигурации, соответствующие документации Kubernetes.

• Контейнерный рантайм: Проверьте настройки и версии containerd, чтобы они соответствовали требованиям Kubernetes версии 1.30.8.

4. Проверьте совместимость версий

• Версии компонент: Убедитесь, что все используемые версии компонентов совместимы друг с другом. Проверьте совместимость Kubernetes 1.30.8 с другими установленными системными пакетами на Red Hat 8.4.

Заключительные шаги

После выполнения всех проверок и исправлений выполните перезапуск подов kubectl delete pod <pod-name> -n kube-system и проверьте их состояние после перезапуска. Это может помочь очистить временные проблемы или кеши, которые не обновлялись после миграции.

Помните, что систематический подход к обнаружению и устранению неисправностей — ключ к успешному решению проблем в Kubernetes-кластере. Если проблема остается нерешенной, рассмотрите возможность привлечения специалистов Azure и экспертов по Kubernetes для более глубокого анализа.