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

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

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

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

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

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

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

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

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

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

kubevirt.io

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

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

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

https://github.com/rancher/longhorn

Вроде OpenEBS это форк лонгхорна, частично или полностью

я сырцов то лонхорна не нашел

https://github.com/rancher/longhorn#source-code

Но я бы больше в сторону Linstor посмотрел бы ес честно

linstor это ж drbd?

уж лучше с сефом потрахаться

Зависит от конкретных задач, цеф под хайлоад ваще не вариант

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

https://www.meetup.com/Moscow-Kubernetes-Meetup/events/253451195/ Когда: четверг, 9 августа 2018, 19:30 - 22:15 Где: Москва, Ленинградский проспект 39, стр. 79 (офис Mail.Ru Group) Друзья, жаркое лето в Москве ещё больше подогревает интерес к Kubernetes со стороны русскоговорящего сообщества. Прошёл всего месяц с момента предыдущего митапа, наш Telegram-чат-канал про Kubernetes ( https://t.me/kubernetes_ru ) уже вырос почти до 2000 человек, а вместе с ним продолжают расширяться и области применения Kubernetes, как и масштаб проблем, которые успешно решаются с его помощью. Облака спускаются на землю в следующий четверг, ведь мы снова встречаемся и на этот раз мы будем делать это вместе с Mail.Ru Group! ПРОГРАММА: 19:30 - 19:50 Socializing, встречаемся, общаемся, shake it! 19:50 - 20:05 Welcome & digest (Денис Измайлов, Axept) 20:05 - 20:45 Подводные камни при production-эксплуатации Kubernetes (Дмитрий Лазаренко, Mail.Ru Cloud Solutions, менеджер продукта) Изначально Kubernetes был спроектирован для работы stateless-приложений. Однако сейчас все больше и больше компаний пытаются размещать в нем stateful-сервисы, требующие надежного хранения. Помогая клиентам Mail.Ru Cloud Kubernetes, мы обнаружили много неочевидных особенностей, прежде всего связанных с persistent-хранением данных и поведением Kubernetes при выходе из строя оборудования. Как Persistent Volumes работают в штатных и нештатных ситуациях? Например, если вы выключите ноду или она аварийно остановится (падение хоста, гипервизора или Kubelet)? Какие проблемы бывают при эксплуатации RWX PVС? Как правильно дружить с облачным балансировщиком нагрузки? Всё это Дмитрий раскроет в своем докладе для вас. Био: Дмитрий Лазаренко возглавляет PaaS-направление Mail.Ru Cloud Solutions, включая контейнерные решения на базе Kubernetes. До Mail.Ru Group в течение 6 лет отвечал за разработку и развитие контейнерной PaaS-платформы Jelastic. Более 10 лет занимается созданием высоконагруженных сервисов. 20:45 - 21:15 История разработки Production-ready сборки Kubernetes (Константин Феофантов, Exon Lab, CTO) Доклад основывается на истории разработки [предположительно] первого в России Docker-хостинга. Константин расскажет про опыт с Kubernetes и проблемы, с которыми он с командой столкнулся в ходе разработки и эксплуатации. В докладе обосновывается выбор компонентов и плагинов Kubernetes при создании собственного production-ready кластера, а также варианты развертывания Kubernetes и рекомендации по ним. Био: Константин программирует с 2012 года, писал на C, затем на C#. Потом начал изучать веб-разработку (Node.js, HTML5, SaSS) и вот уже в 2015 году перевел всё на Golang. В 2017 стал техническим директором, основал проект Containerum и основательно занялся изучением Kubernetes. 21:15 - 21:35 Кофе-брейк, чай-пати, горячие дискуссии 21:35 - 22:15 Turing Pi – кластерный компьютер на базе Kubernetes для граничных вычислений и интернета вещей (Константин Шмойлов-Александров, Jelastic, сооснователь) Рынок IoT бурно развивается, но в основном он наполнен крайне простыми устройствами с ограниченным диапазоном применения. Мы создали компактное кластерное устройство с Kubernetes и Docker на борту, воплощающее идею вычислительного узла IoT-сети нового типа. В нем сочетается множество разнотипных одноплатных компьютеров, соединенных сетью в рамках единой материнской платы. Этот кластер предназначен для граничных вычислений: в частности, для размещения приложений машинного обучения не в облаке, а локально – в месте, где необходимо собирать, хранить, анализировать данные и управлять окружающими устройствами. В докладе мы расскажем, что под капотом этого устройства и как контейнеры и Kubernetes могут эффективно работать не только на огромных серверах, но и на мини-устройствах.

Друзья, по стечению серьезных обстоятельств наш фотограф не смог добраться на митап в этот раз. Но как бы не так! Небольшой личный фотоотчёт опубликовал на своей личной странице в Facebook. Все получились счастливые и красивые. ? Находим там себя и отмечаемся: https://www.facebook.com/denis.izmaylov/posts/1275186792622794 Слайды будут опубликованы очень скоро, видеозаписи докладов будут опубликованы в течении пары недель.

Друзья, по стечению серьезных обстоятельств наш фотограф не смог добраться на митап в этот раз. Но как бы не так! Небольшой личный фотоотчёт опубликовал на своей личной странице в Facebook. Все получились счастливые и красивые. ? Находим там себя и отмечаемся: https://www.facebook.com/denis.izmaylov/posts/1275186792622794 Слайды будут опубликованы очень скоро, видеозаписи докладов будут опубликованы в течении пары недель.

+ я сейчас активно использую drbd и доволен им как слон

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

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

https://www.linbit.com/en/products-and-services/linstor/

А. Через flex, аналог лонгхорну /openEBS только сложный. Зачем тогда такое?