#kubernetes
#kubernetes
Вопрос:
Я обновил развертывание statefulset, и удаленные модули этого statefulset находятся в ожидании вечно. Таким образом, я описал модули и увидел, что они не могут быть запланированы на узлах, потому что узлы не соответствуют правилам привязки / анти-привязки модулей. Однако этот набор состояний вообще не имеет правил привязки.
Мой вопрос
Как я могу оценить правила привязки моего statefulset, чтобы я мог видеть, какие правила привязки препятствуют запуску этих модулей?
Я полагаю, что это должно быть другое развертывание, которое препятствует запуску этих модулей, но я понятия не имею, какое это может быть развертывание.
Комментарии:
1. После того, как они потерпели неудачу, вы побежали
kubectl describe
на них?2. Да, вот почему я знаю, что они не могут быть запланированы, потому что они не соответствуют правилам привязки / антиподности pod. Я обновлю поток исходными выводами из описания модуля.
Ответ №1:
проверьте это, чтобы определить возможную первопричину
- проверьте, есть ли у ваших узлов taints (
kubectl describe node {Node_Name} | grep Taint
) , если это так, найдите допуски, чтобы запланировать рабочую нагрузку на определенном узле. - у вас есть в определении поле
nodeName
, и оно указывает на несуществующий узел. - как рекомендовал Пратик Джейн выше, проверьте свой модуль с помощью describe, чтобы увидеть, что именно переопределяется в вашем определении.
Комментарии:
1. Привет, узел не испорчен, и причина не в nodeselector. Моя информация уже взята из описания модуля. В нем говорится, что узла нет, потому что x узлов не имели большого выбора узлов, 2 узла не имеют достаточных ресурсов, а 3 узла не соответствовали правилам сродства / антиаффинности.
Ответ №2:
Модули Statefulsets могут препятствовать удалению, потому что у вас может быть какая-то pv-защита, лучший способ устранения неполадок в этой ситуации выполняется kubectl get events -n ${yournamespace}
, любое событие в вашем пространстве имен будет указано.
Попробуйте посмотреть, отображается ли какое-либо предупреждение или сообщение об ошибке.
ПРИМЕЧАНИЕ: Если вы получаете слишком много событий, попробуйте выполнить фильтрацию с помощью --field-selector=type!=Normal,reason!=Unhealthy
✌
Комментарии:
1. Возможно, это было сформулировано нечетко, но у меня нет проблем с удалением модуля. Я имел в виду, что они находятся на рассмотрении (потому что они не могут быть запланированы) ПОСЛЕ того, как я успешно удалил модуль.
2. о, я вижу, все еще команда действительна для вашего случая, будет показано любое событие, сгенерированное планировщиком, есть несколько причин не получать ваши модули в ожидании планирования (нехватка ресурсов, привязка, флаги управления администрированием и так далее …)