Или кому-то починить бота

ты про спам бота?

Ага

я думал у всех один бот, в @devops_jobs @devops_ru вродь работает О.о

я думал у всех один бот, в @devops_jobs @devops_ru вродь работает О.о

Самое забавное что у меня докер вообще на другом разделе, а кубелет паникует когда на руте места мало

А ещё такой вопрос, я тут сооуражаю плэйбук для мультимастера в очередной раз. Мастерам достаточно одинакового ca.crt, а apiserver.crt могут быть разными?

Где можно почитать про плейбуки для мультимастеров?

Читать нужно про то как поднять мультимастер и переделить инструкцию в плэйбук читая доки ansible.

Kubespray?

Мне кажется он сложноват будет для понимания. Я бы начал с простых инструкции по настройке мультимастера, коих полно

Мне кажется он сложноват будет для понимания. Я бы начал с простых инструкции по настройке мультимастера, коих полно

Ну да, более того, он продолжит выполняться на ноде, при этом куб не знает выполняется он или нет. Если такой под просто удалить из API, куб его пересоздаст на другой ноде, подключит и смаунтит тот же iscsi-volume, при этом в лучшем случае под не заведется, в худшем заведется и ты получишь поврежденную фс на волуме. Так как она смонтирована на нескольких физически разных нодах.

Оу, добро пожаловать снова!

ты вообще спишь?

Неправда, пока нода не зарепортит что вольюм неиспользуется, нигде никто его не подключит. Attach-Detach контроллер этим занимается и проследит.

А как он узнает, что волум еще где-то подключен? - через attachedVolumes ноды. Ну вот если эту информацию просто выпиливать из API вместе с подом безо всяких дополнительных проверок, то будет плохо.

Эта информация в статусе ноды, если выпилить под, а нода мертва, то никто под не даст запустить пока скажем и объект ноды не удалить. Но это сильно ручное действие, по-моему ничто в кубе ноды не удаляет, это может только пользователь сдедать

Эта информация в статусе ноды, если выпилить под, а нода мертва, то никто под не даст запустить пока скажем и объект ноды не удалить. Но это сильно ручное действие, по-моему ничто в кубе ноды не удаляет, это может только пользователь сдедать

@SinTeZoiD

Что?

не станешь теперь криптомаганатом ты

А есть какой-нибудь универсальный парсер ответов в командной строке ? Некоторые команды, например 'kubectl top nodes' не выдаёт результат в json, а запустить kubectl Proxy мы не можем по ряду причин

А есть какой-нибудь универсальный парсер ответов в командной строке ? Некоторые команды, например 'kubectl top nodes' не выдаёт результат в json, а запустить kubectl Proxy мы не можем по ряду причин

>ничто в кубе ноды не удаляет @lazarenkod говорил что это дефолтное поведение openstack cloud provider :)

Эта информация в статусе ноды, если выпилить под, а нода мертва, то никто под не даст запустить пока скажем и объект ноды не удалить. Но это сильно ручное действие, по-моему ничто в кубе ноды не удаляет, это может только пользователь сдедать

Aws cloud provider удаляет.

Всем привет. Никто не подскажет в чем может быть дело. Есть deployment, три реплики, образы тянутся с приватного гитлаб регистри. Стабильно одна реплика не взлетает типа registry http access denied . Каждый раз это происходит на разных нодах. напрямую ssh и docker pull отрабатывает.

Тогда непонятно о чем речь и что надо улучшать, клауд провайдер по определению знает правду,,если говорит что ноды нет, значит ее точно нет и диск неожиданно никак не замонтируется

Согласен. Факт остаётся фактом, fencing - это не проблема кубера, это проблема клауд-провайдера.

Тем не менее по-умолчанию кубер безопасен, а вы страшилки рассказывали :) если руками не лезть, то ничего с данными не случится

наоборот, я объяснял почему это должно быть так

не уж-то удаление ноды было проще реализовать, чем вычищать волумы и поды с нее