Рейтинг:0

Нет доступных или планируемых подов в кластере kubernetes

флаг ru

У меня есть 2 кластера kubernetes в облаке IBM, в одном 2 узла, в другом 4.

Тот, который имеет 4 узла, работает нормально, но на другом мне пришлось временно удалить рабочие узлы из-за денежных причин (не следует платить во время простоя).

Когда я повторно активировал два узла, все, казалось, запустилось нормально, и пока я не пытаюсь взаимодействовать с модулями, на поверхности все выглядит нормально, никаких сообщений о недоступности или критическом состоянии здоровья. Хорошо, я удалил два устаревших Пространство именs, который застрял в Прекращение состояние, но я мог бы решить эту проблему, перезапустив узел кластера (уже точно не знаю, какой именно).

Когда все выглядело нормально, я попытался получить доступ к панели инструментов kubernetes (все, что делалось до этого, было на уровне управления IBM или в командной строке), но, к удивлению, я обнаружил, что она недоступна со страницей ошибки в браузере с указанием:

сервис 503 недоступен

Внизу этой страницы было небольшое сообщение JSON, в котором говорилось:

{
  "вид": "Статус",
  "апиВерсия": "v1",
  "метаданные": {},
  "статус": "Отказ",
  "message": "ошибка при попытке связаться с сервисом: чтение tcp 172.18.190.60:39946->172.19.151.38:8090: чтение: сброс соединения узлом",
  "причина": "Сервис недоступен",
  "код": 503
}

я отправил журналы kubectl kubernetes-dashboard-54674bdd65-nf6w7 --namespace=kube-system где Стручок был показан как работающий, но результатом были не журналы для просмотра, а вместо этого было это сообщение:

Ошибка с сервера: получить «https://10.215.17.75:10250/containerLogs/kube-system/kubernetes-dashboard-54674bdd65-nf6w7/kubernetes-dashboard»:
прочитать tcp 172.18.135.195:56882->172.19.151.38:8090:
чтение: соединение сброшено узлом

Затем я узнал, что я не могу получить журналы Любые Стручок работающий в этом кластере, и я не могу развернуть какой-либо новый пользовательский объект kubernetes, который требует планирования (на самом деле я мог бы применить Оказание услугс или Карта конфигурациис, но нет Стручок, набор реплик, Развертывание или похожие).

я уже пытался

  • перезагрузить рабочие узлы в рабочем пуле
  • перезапустить рабочие узлы в рабочем пуле
  • перезапустил kubernetes-dashboard Развертывание

К сожалению, ни одно из вышеперечисленных действий не изменило доступность Стручокс.

Есть еще одна вещь, которая может быть связана (хотя я не совсем уверен, что это на самом деле):

В другом кластере, который работает нормально, есть три ситцевых Стручокработают и все три работают, в то время как в проблемном кластере только 2 из трех коленкоров Стручокзапущены и работают, третий остается В ожидании государство и kubectl описать pod calico-blablabla-blabla раскрывает причину, Событие

Предупреждение FailedScheduling 13s планировщик по умолчанию
Доступно 0/2 узла: у 2 узлов не было свободных портов для запрошенных портов модуля.

Кто-нибудь знает, что происходит в этом кластере, и может указать мне на возможные решения? Я действительно не хочу удалять кластер и создавать новый.

Редактировать

Результат kubectl описывает модуль kubernetes-dashboard-54674bdd65-4m2ch --namespace=kube-system:

Имя: kubernetes-dashboard-54674bdd65-4m2ch
Пространство имен: kube-system
Приоритет: 2000000000
Имя класса приоритета: системный-кластер-критический
Узел: 10.215.17.82/10.215.17.82
Время начала: Пн, 15 нояб. 2021 г., 09:01:30 +0100
Ярлыки: k8s-app=kubernetes-dashboard
                      стручок-шаблон-хэш = 54674bdd65
Аннотации: cni.projectcalico.org/containerID: ca52cefaae58d8e5ce6d54883cb6a6135318c8db53d231dc645a5cf2e67d821e
                      cni.projectcalico.org/podIP: 172.30.184.2/32
                      cni.projectcalico.org/podIPs: 172.30.184.2/32
                      container.seccomp.security.alpha.kubernetes.io/kubernetes-dashboard: время выполнения/по умолчанию
                      kubectl.kubernetes.io/restartedВ: 2021-11-10T15:47:14+01:00
                      kubernetes.io/psp: ibm-привилегированный-psp
Статус: Работает
IP: 172.30.184.2
IP-адреса:
  IP: 172.30.184.2
Контролируется: ReplicaSet/kubernetes-dashboard-54674bdd65
Контейнеры:
  kubernetes-панель управления:
    Идентификатор контейнера: containerd://bac57850055cd6bb944c4d893a5d315c659fd7d4935fe49083d9ef8ae03e5c31
    Изображение:Registry.eu-de.bluemix.net/armada-master/kubernetesui-dashboard:v2.3.1
    Идентификатор изображения: Registration.eu-de.bluemix.net/armada-master/kubernetesui-dashboard@sha256:f14f581d36b83fc9c1cfa3b0609e7788017ecada1f3106fab1c9db35295fe523
    Порт: 8443/TCP
    Хост-порт: 0/TCP
    Аргументы:
      --auto-генерировать-сертификаты
      --namespace=kube-система
    Состояние: работает
      Начато: Пн, 15 Ноя 2021 09:01:37 +0100
    Готово: Верно
    Количество перезапусков: 0
    Запросы:
      процессор: 50 м
      память: 100Ми
    Жизнеспособность: http-get https://:8443/ delay=30s timeout=30s period=10s #success=1 #failure=3
    Готовность: http-get https://:8443/ delay=10s timeout=30s period=10s #success=1 #failure=3
    Среда: <нет>
    Маунты:
      /certs из kubernetes-dashboard-certs (rw)
      /tmp из tmp-тома (RW)
      /var/run/secrets/kubernetes.io/serviceaccount из kube-api-access-sc9kw (ro)
Условия:
  Тип Статус
  Инициализировано Истинно 
  Готов Верно 
  ContainersReady True 
  PodScheduled True 
Объемы:
  Kubernetes-приборная панель-сертификаты:
    Тип: секрет (том, заполненный секретом)
    SecretName: kubernetes-dashboard-certs
    Необязательно: ложь
  tmp-том:
    Тип: EmptyDir (временный каталог, который разделяет время существования модуля)
    Середина:     
    Ограничение размера: <не установлено>
  куб-апи-доступ-sc9kw:
    Тип: спроецированный (том, который содержит внедренные данные из нескольких источников)
    TokenExpirationSeconds: 3607
    ConfigMapName: kube-root-ca.crt
    ConfigMapOptional: <ноль>
    Нисходящий API: правда
Класс QoS: взрывоустойчивый
Селекторы узлов: <нет>
Допуски: node-role.kubernetes.io/master:NoSchedule
                             node.kubernetes.io/not-ready:NoExecute op=Существует 600 сек.
                             node.kubernetes.io/unreachable:NoExecute op=Существует 600 сек.
События: <нет>
Mikołaj Głodziak avatar
флаг id
Здравствуйте, возможно, проблема связана с SSL-сертификатом. Посмотрите [этот вопрос] (https://stackoverflow.com/questions/46411598/kubernetes-dashboard-serviceunavailable-503-error) и сообщите мне о результате. Какую версию Kubernetes вы использовали?
deHaar avatar
флаг ru
Сеск @MikoÅajGÅodziak, спасибо за ваши предложения. Версия кластера — 1.22.2_1526, а рабочие узлы — версии 1.22.2_1528. Следующее, что я сделаю (снова сейчас), — обновлю кластер. Я проверю вопрос, который вы связали, еще раз спасибо!
Mikołaj Głodziak avatar
флаг id
И как именно вы настроили свой кластер? Это голое железо или какой-то облачный провайдер? Важно воспроизвести вашу проблему. Пожалуйста, проверьте мое предложение и дайте мне знать;)
deHaar avatar
флаг ru
Это классический кластер в IBM Cloud, который я настроил с помощью веб-консоли (и cli для частичных взаимодействий).
deHaar avatar
флаг ru
@ MikoÅajGÅodziak может ли быть причиной старый (возможно, восстановленный) tls-сертификат, который был на первых узлах (который должен был быть удален несколько недель назад)? Я вижу подозрительный "Секрет"...
Mikołaj Głodziak avatar
флаг id
Да, конечно, это возможно. Если у вас есть текущий сертификат и вы восстановили старый (который следует удалить), возможно, теперь он выглядит как самый новый. Однако он устарел, поэтому вы получаете сообщение об ошибке.
deHaar avatar
флаг ru
Хм, у меня нет нового или текущего сертификата, но, возможно, он был сгенерирован, когда появились новые узлы (или новый рабочий пул). Я должен копнуть в это немного глубже...
Mikołaj Głodziak avatar
флаг id
Не могли бы вы также запустить `kubectl описать pod ` и вставить результаты в вопрос?
deHaar avatar
флаг ru
Теперь это включено в вопрос ...
Mikołaj Głodziak avatar
флаг id
Вы проверили выпуск SSL-сертификата?
deHaar avatar
флаг ru
Пока нет, я не мог узнать, как... Ответ на вопрос, который вы связали, не применим в IBM Cloud.
Mikołaj Głodziak avatar
флаг id
Вы сказали: «Может ли быть причиной старый (возможно, восстановленный) tls-сертификат, который был на первых узлах (который должен был быть удален несколько недель назад)? Я вижу подозрительный секрет ...» Вы уверены, что у вас есть только один действующий сертификат?
deHaar avatar
флаг ru
Я не уверен в этом, но поставщик облачных услуг обнаружил, что эта проблема была вызвана обновлением версии кластера до версии 1.21 с включенной общедоступной и частной конечной точкой, поскольку VRF отключен. Это созвездие привело к моей проблеме, которая до сих пор не решена и, скорее всего, останется в этом состоянии. Поставщик говорит, что это не связано с сертификатами.
deHaar avatar
флаг ru
@MikoÅajGÅodziak спасибо за интерес к этому вопросу, пожалуйста, посмотрите мой собственный ответ на этот вопрос, который я узнал в ходе трехдневной борьбы со службой поддержки IBM. Кто-то оттуда наконец указал мне на решение.
Рейтинг:2
флаг ru

Проблема решена¦

Причиной проблемы было обновление кластера до версии kubernetes 1.21, в то время как мой кластер удовлетворял следующим условиям:

  • включена конечная точка частной и общедоступной службы
  • VRF отключен

Первопричина:

В Kubernetes версии 1.21 Konnectivity заменяет OpenVPN в качестве сетевого прокси-сервера, который используется для защиты связи главного сервера API Kubernetes с рабочими узлами в кластере.
При использовании Konnectivity возникает проблема со связью мастеров с узлами кластера, когда выполняются все вышеперечисленные условия.

Шаги решения:

  • отключил конечную точку частной службы (общедоступная, похоже, не проблема) с помощью команды
    ibmcloud ks cluster master private-service-endpoint disable --cluster <CLUSTER_NAME> (эта команда зависит от провайдера, если у вас возникла та же проблема с другим провайдером или при локальной установке, узнайте, как отключить эту конечную точку частной службы)
  • обновил мастер кластера, используя обновление главного узла кластера ibmcloud ks --cluster <CLUSTER_NAME> и наконец
  • перезагрузил все рабочие узлы (в веб-консоли это также возможно с помощью команды)
  • ждал около 30 минут:
    • Панель управления доступна / снова доступна
    • Стручокснова доступно и доступно по расписанию

Общая рекомендация:

ПЕРЕД вы обновляете любой кластер до kubernetes 1.21, проверьте, включили ли вы конечную точку частной службы. Если у вас есть, либо отключите его, либо отложите обновление до тех пор, пока не сможете, либо включите VRF (виртуальную маршрутизацию и переадресацию), чего я не мог, но мне сказали, что это, вероятно, решит проблему.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.