согласен )))

Ну а если у тебя сколь-нибудь специфические требования к надежности или к безопасности, то шансов сделать это на k8s без выращивания очень-очень дорогих спецов - вообще нет (

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

Опять же, не обязательно гонять всё через него. И я бы посмотрел на https://docs.cilium.io/en/stable/gettingstarted/hubble/

Э, какой смысл иметь меш и не гонять все через него?
И при чем тут observatory layer?
Так-то мы написали свой меш на 10K rps на ядро, но это решение не для всех )

Если в проекте высокий disk IO и много фулстэйта то онпрем кубер брать не получится
Разве что сумеете local persistent volume правильно приготовить

Это было верно года два назад. С тех пор появилось куча проектов, как гонять k8s локально легко и просто.

Эээ, развернуть - да, можно легко.
Поддерживать, развивать, гарантировать безопасность без погружения вглубь - увы (

Речь о том, что istio - не единственный и не надо всё гонять именно через него.

Это да, но вроде бы быстрых и экономных публичных мешей (решающих именно задачи выкладки) пока просто нет (

Это какой-то адский сектантский культ. Кубер ради кубера без понимания, какие стейты есть и что вы хотите получить.

Впрочем, ничего нового. Уже были и прошли фанаты SOAP, XML, FreeBSD и Perl))

Ничего не понял про стейты. Но верю, что есть какие-то "стейты", которые заставляют без понимания внедрять ансибл вместо кубера.

Что посоветуете для перевода небольшой инфраструктуры на автоматический деплой?
Когда-то был виртуальный хостинг, потом была виртуальная машина с веб-сервером, почтой, DNS, MySQL, потом виртуальная машина была rsync-ом скопирована в контейнер systemd-nspawn и запускается как полноценная ОС.
Рядом с ней по аналогии несколько других штук работает.
Это все настраивалось вручную.
Сейчас этого не хватает, нужно иметь резервный сервер с быстрым переключением в dns, сделать настройку воспроизводимой.
Есть 2-3 физических сервера и несколько виртуалок (VPS).
K8S вообще жесть, nomad выглядит тоже слишком сложным.
Нужно что-то такое, что будет работать просто и надёжно.
Склоняюсь к такой схеме:
собираем squashfs образ ОС (контейнера), пакуем его в RPM вместе с конфигом systemd-nspawn, в котором прописано, какие директории смонтировать на запись поверх этого образа, как настроить сеть, можно и конфиги systemd-networkd сразу паковать.
Деплоить пакеты через локальный репозиторий и пакетный менеджер RPM.
ОС устанавливать и делать готовой к работе по кикстрарт-сценарию.
Ansible? Он будет полезен для автоматизации перенастройки, но нужно ли это, когда серверов меньше десяти? Наверное, да, пакеты из локального репозитория можно ставить ансиблом. А не проще тупо cluster ssh - обход серверов скриптом?
Мониторить все в zabbix.
Вроде неплохо с масштабируаемостью у такого решения
Сложно найти баланс.

И сопровождение этого по мелочам не должно требовать зарплату уровня модного девопса

Речь про инфраструктуру компании, где ИТ - средство помощи основной деятельности, а не ИТ ради ИТ

Да я вижу, что ты не особо понимаешь, фанатик куба

Поставить Опенстек и сделать для него набор образов. Прицепить ansible. Для небольшой инсталляции этого за глаза.

Запустить виртуалку в Опенстеке может даже директор по пиару))

Ехал кубер через кубер

Воткнуть nomad и использовать gitlab-ci. И избавится от жирного контейнера.