Я бы упростил,
исключил бы сразу kind, minikube (не правильно выразился, даже бы не исключил, а комбинировал подходы), т.к. все они клёвые но у каждой есть свои недостатки (и перешёл к вагрант, кубспрей):
kind
Самый лучший use case: использование когда нужно что то многокластерное
плюсы:
- использует докер для разворачивания
- очень быстро всё разворачивается, любое кол-во нод и кластеров
- экстра аргументы позволяют опубликовать 80 и 443 порты
- выживает после перезагрузки, норм работает с metallb
минусы:
- использует докер для разворачивания
- отсюда невозможность управления ресурсами (т.е. ограничить ноде 2гб памяти например и посмотреть как ведет себя деплоймент)
minikube
Самый лучший use case: любой поддерживаемый драйвер на VM (на докере лучше кайнд)
плюсы:
- очевидно норм кластер, быстро поднимаемый с мультинодами
минусы:
- не выживает после ребута (не поднимает сервисы внутри ВМ, требуется снова делать minikube start и передеплоивать), после сейвстейт на линукс плюс Virtualbox теряет сетевые интерфейсы (ребут возвращает интерфейсы в норм стейт, но уже не поднимаются сервисы кубера-докера)
vagrant или kubespray based
Самый лучший use case: для всего
плюсы:
- железный кластер, можно шатдаунить ноды, симулировать отказы нод, лимит ресурсов.
- можно саспендить машины, когда не требуется (в вагранте одной командой все ноды сразу)
минусы:
- жрет ресурсы,
- без ссд медленно
Есть еще варианты на голом железе, ну тут вы и сами должны понимать плюсы и минусы.
