Примерно полгода назад пробовали внедрять Istio в Openshift в их имплементации (Maistra) и имели неприятный опыт: через некоторое время после деплоя самого Istio падал Под с Sidecar-injector с ошибкой, что не может найти webhook (который при установке присутствовал, но пропадал со временем). Все это приводило к тому, что ни один деплоймент, помеченный на установку sidecar'а с envoy не мог раскатиться. Т.е. все приложения, настроенные на работу с istio превращаются в тыкву, если с последним что-то случается. Получаем лишнюю точку отказа.
Кроме того, возникают вопросы к самому envoy. Тут на хабре были публикации, что envoy сам по себе медленный и кушает недопустимо много ресурсов.
Далее (не знаю, как сейчас, но полгода назад было именно так и в имплементации красной шапки), как быть с изоляцией? Если вы хотите иметь Service Mesh для нескольких несвязанных проектов, красная шапка предлагает устанавливать столько же «контроллеров» Istio, т.к. у него нет изоляции (multi-tenancy). А учитывая, что ресурсы он все-таки потребляет, выглядит, как очень дорогое решение.
Ну и на последок, DistributedTracing можно реализовать и без Istio, безопасность натянуть через NetworkPolicy, так что часть задач закрывается вполне и без наворотов.
Стандартная ситуация, когда заказывает начальство, а мы (эксплуатация) видим только конечный результат, на который повлиять уже не можем, но должны отвечать за бесперебойную работу сервиса под любой нагрузкой.
И после таких статей и советов приходит к тебе подрядчик вот с таким решением, когда в одном контейнере упаковано все, а у тебя кубер. И совершенно непонятно, как это запускать без переделки: ни логов нормально не собрать, ни масштабировать невозможно. А подрядчик переделывать не хочет, он ведь разработчик, ему так удобнее и его совершенно не интересует, как это потом должно в эксплуатации работать.
Не планируете организовать публикацию тестов в свободном доступе для всех желающих? Если это виртуальные машины, можно было бы выложить образы с кратким описанием проблем, которые необходимо решить.
В свое время собирали Proxmox на ZFS для офиса. Были неприятно удивлены невозможности делать клоны машин со снапшотов (только с текущего состояния) и откатывать не до последнего снепшота. Судя по комментариям на форумах — это стандартное ограничение ZFS, из-за чего пришлось от него отказаться (сейчас CEPH). Может быть я что-то делал неправильно, или оно так у всех?
laba.media/materials/voda-sakhar
Кроме того, возникают вопросы к самому envoy. Тут на хабре были публикации, что envoy сам по себе медленный и кушает недопустимо много ресурсов.
Далее (не знаю, как сейчас, но полгода назад было именно так и в имплементации красной шапки), как быть с изоляцией? Если вы хотите иметь Service Mesh для нескольких несвязанных проектов, красная шапка предлагает устанавливать столько же «контроллеров» Istio, т.к. у него нет изоляции (multi-tenancy). А учитывая, что ресурсы он все-таки потребляет, выглядит, как очень дорогое решение.
Ну и на последок, DistributedTracing можно реализовать и без Istio, безопасность натянуть через NetworkPolicy, так что часть задач закрывается вполне и без наворотов.