Вы правы, однако данная статья рассчитана на людей, которые уже и так знакомы с данными инструментами (их аналогами), и вникать в такие подробности - не является целью это статьи :)
Как я описал в статье, перед тем как заехать в кубер, монолит на протяжении 2-х лет дробился на части, хотя еще есть над чем работать в этом направлении, например окончательно выпилить всю статику из docker образа, из-за которого он весит примерно 2GB. Что касается бенефитов переезда, то мы ощутили их в полной мере, и в статье о них подробно говорили)
Все просто. Он написан таким образом, что подходит для всех сервисов в компании. У нас нет такого, что под каждый сервис пишется отдельный хелм чарт. Правки если и вносятся, то только в одном месте - в unique-helm-chart. Так мы его называем :)
Здравствуй! На предыдущем месте работы мы с коллегами администрировали сотни кластеров Openshift. По дефолту Openshift поставляется с Prometheus. Т.к кластеры были высоконагруженные, метрик было много, Prometheus потреблял очень много ресурсов CPU, RAM, IO. В качестве эксперимента мы подняли на серверах с такими же ресурсами Victoria Metrics и сравнили их работу. Разница в потреблении была в 2-3 раза. Поэтому без лишних раздумий, в Ситидрайве выбор пал на Victoria Metrics. Помимо этого компоненты Виктории легко масштабируются.
Т.к livenessProbe отвечает за рестарт Pod'ов, этот хелсчек дёргается наиболее часто. Логика его работы на данный момент проста - мы проверям работоспособность веб-сервера в целом и отвечаем 200.
readinessProbe - с этим хелсчеком ситуация обстоит хитрее. Результат этой пробы говорит о том, готов или не готов Pod принимать трафик. Когда мы дёргаем его, помимо работы веб-сервера, мы проверяем критически важные инфраструктурные компоненты на доступность включая базы, шины данных и т.д.
Что касается самих метрик, то тут тоже всё просто. У нас заведены алерты на все критически важные для инфраструктуры и бизнеса метрики. Если что-то идёт не так, Alertmanager даст нам знать.
Секреты из Vault на данный момент доставляются в k8s с помощью gitlab-ci, но в будущем есть планы усовершенствовать этот способ, добавив монтирование секретов при инициализации контейнера. Таким образом из gitlab-ci этот этап вообще можно будет убрать.
Вы правы, однако данная статья рассчитана на людей, которые уже и так знакомы с данными инструментами (их аналогами), и вникать в такие подробности - не является целью это статьи :)
Как я описал в статье, перед тем как заехать в кубер, монолит на протяжении 2-х лет дробился на части, хотя еще есть над чем работать в этом направлении, например окончательно выпилить всю статику из docker образа, из-за которого он весит примерно 2GB. Что касается бенефитов переезда, то мы ощутили их в полной мере, и в статье о них подробно говорили)
Окей, исправил.
Спасибо! Да, мы используем своё железо, но если вдруг будет такая потребность, заехать в cloud будет не проблема.
Все просто. Он написан таким образом, что подходит для всех сервисов в компании. У нас нет такого, что под каждый сервис пишется отдельный хелм чарт. Правки если и вносятся, то только в одном месте - в unique-helm-chart. Так мы его называем :)
Здравствуй! На предыдущем месте работы мы с коллегами администрировали сотни кластеров Openshift. По дефолту Openshift поставляется с Prometheus. Т.к кластеры были высоконагруженные, метрик было много, Prometheus потреблял очень много ресурсов CPU, RAM, IO. В качестве эксперимента мы подняли на серверах с такими же ресурсами Victoria Metrics и сравнили их работу. Разница в потреблении была в 2-3 раза. Поэтому без лишних раздумий, в Ситидрайве выбор пал на Victoria Metrics. Помимо этого компоненты Виктории легко масштабируются.
Приветствую!
Т.к livenessProbe отвечает за рестарт Pod'ов, этот хелсчек дёргается наиболее часто. Логика его работы на данный момент проста - мы проверям работоспособность веб-сервера в целом и отвечаем 200.
readinessProbe - с этим хелсчеком ситуация обстоит хитрее. Результат этой пробы говорит о том, готов или не готов Pod принимать трафик. Когда мы дёргаем его, помимо работы веб-сервера, мы проверяем критически важные инфраструктурные компоненты на доступность включая базы, шины данных и т.д.
Что касается самих метрик, то тут тоже всё просто. У нас заведены алерты на все критически важные для инфраструктуры и бизнеса метрики. Если что-то идёт не так, Alertmanager даст нам знать.
Секреты из Vault на данный момент доставляются в k8s с помощью gitlab-ci, но в будущем есть планы усовершенствовать этот способ, добавив монтирование секретов при инициализации контейнера. Таким образом из gitlab-ci этот этап вообще можно будет убрать.