Михаил

почему это? простой stateless-сервис: - подписываешься на состояния нод через kubernetes api - если нода ушла в NotReady, проверяешь есть ли на ноде запущенные StatefulSets - выполняешь внешний fencing ноды - убиваешь все Unknown поды с ноды, так же через kubernetes api

да зачем проврять то из вне? умерла так умерла

𝚔𝚟𝚊𝚙𝚜

а если не умерла?

𝚔𝚟𝚊𝚙𝚜

если на ней просто kubelet отвалился или сеть

𝚔𝚟𝚊𝚙𝚜

stateless приложение переедет

𝚔𝚟𝚊𝚙𝚜

а для stateful подобного рода костыли нужны

Михаил

если на ней просто kubelet отвалился или сеть

Ну так же грохаем

𝚔𝚟𝚊𝚙𝚜

ага, но как?

Михаил

ага, но как?

Ну Так ты же написал - через api убиваем unknow

Igor

но я не понимаю, как он его обрабатывает, и откуда писатель этого кода взял структуру, которую можно отправлять в dm

https://cloud.google.com/deployment-manager/docs/configuration/templates/create-template-modules Я думаю там участвует обвязка из темплейтов плагинов и еще кучи интересного https://github.com/GoogleCloudPlatform/deploymentmanager-samples/blob/b941d1f9b70390d0693d030cfc26843c75b3e165/tools/scheduled-deployments/functions/test/schedule_test.js Думаю прийдется покапаться в этой репе https://github.com/GoogleCloudPlatform/deploymentmanager-samples Но это все вам нужно только если нужен питон. Да и я не очень понимаю причем тут кубер

𝚔𝚟𝚊𝚙𝚜

Ну Так ты же написал - через api убиваем unknow

ну они unknown не просто так висят

𝚔𝚟𝚊𝚙𝚜

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

𝚔𝚟𝚊𝚙𝚜

по этому и нужен fencing сначала убиваем ноду, уже только потом убиваем ресурсы в k8s

Igor

но я не понимаю, как он его обрабатывает, и откуда писатель этого кода взял структуру, которую можно отправлять в dm

https://github.com/GoogleCloudPlatform/deploymentmanager-samples/tree/b941d1f9b70390d0693d030cfc26843c75b3e165/tools/scheduled-deployments Вот описание, это кастомная хрень для Scheduled Deployments И в общемто не сильно нужна на начальной стадии

Михаил

по этому и нужен fencing сначала убиваем ноду, уже только потом убиваем ресурсы в k8s

Хмм. Типо что бы наверняка умерла нода?

Andor

Чтобы случайно не ожила

𝚔𝚟𝚊𝚙𝚜

да, все так

Andrey

https://github.com/GoogleCloudPlatform/deploymentmanager-samples/tree/b941d1f9b70390d0693d030cfc26843c75b3e165/tools/scheduled-deployments Вот описание, это кастомная хрень для Scheduled Deployments И в общемто не сильно нужна на начальной стадии

круто, спс!

𝚔𝚟𝚊𝚙𝚜

кстати softdog - вполне годный метод основанный на таймаутах, к тому же не требующий внешних fencing-агентов, вот его и можно было бы запилить в сам куб

Andrey

https://github.com/GoogleCloudPlatform/deploymentmanager-samples/tree/b941d1f9b70390d0693d030cfc26843c75b3e165/tools/scheduled-deployments Вот описание, это кастомная хрень для Scheduled Deployments И в общемто не сильно нужна на начальной стадии

хотя нет, там action это CREATE_OR_UPDATE or DELETE - так что это не то. но всё равно спасибо

𝚔𝚟𝚊𝚙𝚜

Типа запилить следующий функционал прямо в kubelet: - после каждого успешного общения с мастером выполнять что-то типа echo 1 > /dev/watchdog - а в случае неудачи, нода ребутнется сама по таймауту - кубернетес мастер знает про этот таймаут и если нода NotReady больше чем определенное время, значит она гарантированно мертва и ее ресурсы можно решедулить

𝚔𝚟𝚊𝚙𝚜

вот правда будет весело если умрет мастер :)

𝚔𝚟𝚊𝚙𝚜

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

Михаил

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

Ну писать самому

𝚔𝚟𝚊𝚙𝚜

вот и я говорю

𝚔𝚟𝚊𝚙𝚜

хотя можно было бы придумать какой-нибудь fencing api

Andor

Опять пейсмейкер?

𝚔𝚟𝚊𝚙𝚜

да ну не

Andor

:)

Михаил

Типа запилить следующий функционал прямо в kubelet: - после каждого успешного общения с мастером выполнять что-то типа echo 1 > /dev/watchdog - а в случае неудачи, нода ребутнется сама по таймауту - кубернетес мастер знает про этот таймаут и если нода NotReady больше чем определенное время, значит она гарантированно мертва и ее ресурсы можно решедулить

Я запутался. Зачем ребутать ноду? Что бы unmount прошел?

𝚔𝚟𝚊𝚙𝚜

просто нужна еще одна абстракция для куба, как provisioner только для fencing

𝚔𝚟𝚊𝚙𝚜

Я запутался. Зачем ребутать ноду? Что бы unmount прошел?

ну смотри, допустим у тебя есть stateful сервис, он имеет один под к которому подключен какой-нибудь iscsi волум

𝚔𝚟𝚊𝚙𝚜

Что по твоему должно произойти если ты просто остановишь kubelet на ноде где он выполняется?

Михаил

Что по твоему должно произойти если ты просто остановишь kubelet на ноде где он выполняется?

Под уйдет в unknow, но вольюм останется в нем

Anton

Типа запилить следующий функционал прямо в kubelet: - после каждого успешного общения с мастером выполнять что-то типа echo 1 > /dev/watchdog - а в случае неудачи, нода ребутнется сама по таймауту - кубернетес мастер знает про этот таймаут и если нода NotReady больше чем определенное время, значит она гарантированно мертва и ее ресурсы можно решедулить

есть же механизм нотификации живости, таймауты настраиваются. systemd можно попросить живость kubelet проверять, зачем рестартить ноду то.

𝚔𝚟𝚊𝚙𝚜

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

𝚔𝚟𝚊𝚙𝚜

есть же механизм нотификации живости, таймауты настраиваются. systemd можно попросить живость kubelet проверять, зачем рестартить ноду то.

ок, другой кейс, что если у вас пропал коннект со стораджем на ноде которая выполняет под, приложение зависло на какой-то конкретной i/o-операции и не отвечает, любые проверки говорят что приложение не работает

𝚔𝚟𝚊𝚙𝚜

допустим куб перезапускает такой под на другой ноде, при этом не до конца убедившись что старый однозначно мертв. а через какое-то время восстанавливется подключение к стораджу на прежней ноде, i/o продолжается исход такой-же: поврежденная фс и даннные на ней

Михаил

допустим куб перезапускает такой под на другой ноде, при этом не до конца убедившись что старый однозначно мертв. а через какое-то время восстанавливется подключение к стораджу на прежней ноде, i/o продолжается исход такой-же: поврежденная фс и даннные на ней

Итого ребут ноды это гарантия смерти и анмаунта

Михаил

Ну или не использовать stateful в кубе)

Михаил

Точнее PV

𝚔𝚟𝚊𝚙𝚜

ну есть еще вариант отрезать ноду от стораджа, но это работет немного хуже, т.к. оставляет ноду в непонятном состоянии

Artem

Как считаете, Kubernetes как гипервизор на kvm это бред или рацианальное зерно в этом есть?

𝚔𝚟𝚊𝚙𝚜

я деплою opennebula с помощью куба

Vadim

Как считаете, Kubernetes как гипервизор на kvm это бред или рацианальное зерно в этом есть?

kubevirt.io

Михаил

kubevirt.io

Сырая альфа

Михаил

И больше похоже на refrence архитектуру для своего проекта)

𝚔𝚟𝚊𝚙𝚜

Ну или не использовать stateful в кубе)

на самом деле все отлично работает когда все pv локальные, и не должны переезжать если нода упадет. а каждое stateful-приложение имеет несколько инстансов и redundancy на уровне приложения

𝚔𝚟𝚊𝚙𝚜

по сути любая база данных с поддержкой репликации

Михаил

на самом деле все отлично работает когда все pv локальные, и не должны переезжать если нода упадет. а каждое stateful-приложение имеет несколько инстансов и redundancy на уровне приложения

Ну host path

Михаил

Или как его там

𝚔𝚟𝚊𝚙𝚜

сейчас local volumes изобрели спецом для этого

𝚔𝚟𝚊𝚙𝚜

но я не вижу особой разницы с hostpath, тем более что nodeAffinity прекрассно работает и для тех и для других волумов

Михаил