не могу запланировать pod prometheus-server на кубернетах, pod сообщает о порчах, но узлы не имеют каких-либо заражений

я получаю

0/7 nodes are available: 2 node(s) had taints that the pod didn't tolerate, 5 node(s) had volume node affinity conflict.

для моего модуля сервера Prometheus, но если я проверю каждый узел, нет никаких повреждений. и есть достаточно процессора и памяти для распределения .. что мне здесь не хватает?

Я попытался удалить модули и даже объект развертывания, но ошибка все еще сохраняется

все узлы имеют 0 повреждений .. это новая установка Prometheus на новый кластер Kubernetes файлы yaml, которые я использовал для работы до сих пор, когда мне нужно было развернуть новый кластер Kubernetes


kubernetes kubernetes-pod prometheus
person markrosario    schedule 27.05.2019    source источник
comment
Например, на мастер-узлах есть специальные загрязнения, которые не позволяют запускать на них обычные поды. У вас есть 2 главных узла?   -  person Vasili Angapov    schedule 27.05.2019
comment
Можете ли вы показать информацию об узлах (в частности, об их пороках и деталях сродства)?   -  person Vishal Biyani    schedule 27.05.2019

Ответы (1)


arrow_upward
1
arrow_downward

Доступно 0/7 узлов: 2 узла (ов) имели загрязнения, которые не допускались модулем, 5 узлов имели конфликт сродства узла тома.

Это конкретное сообщение: это не заражение, которые удерживают ваши стручки Prometheus от ваших рабочих, а проблема в объеме. Если вы используете AWS, это потому, что ваш том находится в зоне доступности, которой не являются ваши рабочие (например, us-west-2a том и us-west-2c рабочие)

Кратчайший путь к успеху в вашей ситуации может заключаться в воссоздании тома в правильном A.Z. если он был пустым, или вручную создайте новый том и скопируйте данные в A.Z. который соответствует вашим рабочим, или (конечно) создайте нового рабочего в A.Z. что соответствует объему

все узлы имеют 0 повреждений ..

Это наверняка неверно по двум причинам: потому что планировщик ясно говорит, что есть два узла с заражениями, и потому что, если вы специально не удалили их, мастера почти всегда (?) Явно снабжены node.kubernetes.io/master:NoSchedule заражениями, чтобы не допустить нагрузки на них.

person mdaniel    schedule 27.05.2019
comment
Я определенно пропустил ту часть о том, что главные узлы по умолчанию не подлежат планированию. Благодарность! Теперь я могу сузить отладку до PV .. - person markrosario; 28.05.2019