Там же энвои вроде, не?

Да

nagios + telegram 😂

До слёз

Хотя я бы заменил nagios на cacti, а telegram на slack

Он не экспортит логи. Только данные о работе es. Или еще логи можно оттуда достать?

Спасибо

@count0ru  Дима, дорогой ты наш, с днем рождения! Обнимаю, бро!

Воу, ты меня смутил. Спасибо

Ты один из первых, с кем я познакомился из сообщества :) долгих лет тебе!

Надо же. Приятно, спс

Istio функциональней Nginx и предназначен для строительства Service Mesh.

Цепляясь к каждому pod-у он может:
- ssl-ить трафик между pod-ами
- repeat-ить упавшие запросы в другой инстанс сервиса
- управлять политиками межсервисной доступности
- распределять логически трафик по разным версиям одного сервиса
- трейсить межсервисное время общения и путь прохождение запроса по всем сервисам выводя это и строя карту взаимодействия сервисов
- ... + ещё пряники

Но за такое придётся заплатить:
- большой пачкой CustomResource в K8S
- которые обслуживаются почти 10-ом дополнительных Istio-сервисов
- и постоянная инкапсуляция трафика
- а тот же envoy, используемый в качестве sidecar, потребует RAM для хранения всего необходимого локально, но видел в их репо что пилется что-то более легковесное

Спасибо за развёрнутый ответ! ☺️

и ещё
Достаточно сложно проводить отладку всего этого
Если ломается, то у всех, (it depends)
На миникубе повторить конфигурацию порой невозможно(мульти дц если связан истио, а тебе надо проверить как твой фёрст класс пхп апп будет жить с чем-то что вне одного дц)

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

У меня тут сейчас кандидаты типа postgres и mongodb

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

Короче что бы админам было жить лучше, которые это деплоят

админам не пофигу что деплоить в контейнере?