https://blog.russellbryant.net/2019/04/30/metal%C2%B3-metal-kubed-bare-metal-provisioning-for-kubernetes/

This process takes some time. Under the hood, the baremetal-operator is driving Ironic through a provisioning process. This begins with wiping disks to ensure the host comes up in a clean state. It will eventually write the desired OS image to disk and then reboot into that OS. When complete, a new Kubernetes Node will register with the cluster.Ну вот опять зачем так сложно?

кажись реально на месяц сгенерировал

ещё один

Почему бы просто не грузить сразу в RAM?

чо сложного-то, там PXE ж

а если ребутнется в процессе?

насколько я помню, он за собой тянет половину опенстека

а если ребутнется в процессе?

стейт нам не нужен, даже на нодах

А вы юзаете какой-нибудь ipmi/redfish и прочее?

А, ну еще плейбук, который собирает MAC-адреса и добавляет их в DHCP при начальной конфигурации

ну я не знаю что сложнее тогда :/

Что сложнее ironic или dhcp? :D

один контейнер с ironic + sqlite (хз зачем он ему нужен) vs. плейбук + dhcp + настройка ltsp

dhcp + ltsp всё ещё проще чем ironic

один контейнер с ironic + sqlite (хз зачем он ему нужен) vs. плейбук + dhcp + настройка ltsp

Кстати для ironic я так понимаю dhcp все равно нужен)

кстати, у меня тут была трабла с openebs – после совместного дебага на кластере разрабы нашли проблему и сейчас готовят фикс, так что уровень поддержки приятно порадовал. 🙂

Кстати для ironic я так понимаю dhcp все равно нужен)

кстати, если кто соберется попробовать https://godarch.com/ отпишитесь пожалуйста - очень интересно

блин, звучит интересно, но хз для чего можно применить 🙂

A utility to that uses containerd to build stateless operating system images that can be booted bare-metalв качестве замены ltsp

Можешь и цеф завести или где-нибудь NFS сервер сделать

Извиняюсь за вопрос слегка в стороне - а какие обычно используют варианты отказоустойчивого NFS? DRBD+pacemeker/corosync стек или аппаратная полка с NFS? Или что-то комбинированное?

NFS планируется в качестве основного хранилища или в качестве дополнительного?

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

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

а это зависит от того что за данные и что приложения с ними делают

Файлы - данные океанологических моделей, приложения их обсчитывают, соотношения чтение/запись скажем 10 к 1. Плюс там же в кластере живет REST API, раздающий доступ у тем же данным

я бы в s3 положил

поднимите с3

в той степене на сколько продакшн реди то хранилище на которое вы это натягивать будете

Хорошо сказал)

Файлы - данные океанологических моделей, приложения их обсчитывают, соотношения чтение/запись скажем 10 к 1. Плюс там же в кластере живет REST API, раздающий доступ у тем же данным

В этом кейсе цеф должен хорошо зайти

в той степене на сколько продакшн реди то хранилище на которое вы это натягивать будете

ты еще не надумал с небулы слезать?

мне чет кажется там и минио справится

Человек хочет fault-tolerant решение, насколько я помню у minio с этим проблемы

Хотя его с тем же успехом и поверх drbd запускать можно, зато быстро будет

я говорю про способ доступа из кластера к данным - с3 лучше чем монтировать шары. Про фолт толерант я считаю что это задача блочного устройства

мне кажется консистентность в моделях важнее скорости чтения

мне кажется консистентность в моделях важнее скорости чтения

мне чет кажется там и минио справится

а в minio несколько server-нод могут шарить один блочный сторадж?

Нет, только общую фс

а в minio несколько server-нод могут шарить один блочный сторадж?

этл равносильно тому что ваше блочное устройство поддерживает multiple write

ну, то бишь либо NFS либо кластерная fs нужны