Comments 18
Куча работы еще впереди, но шаг в нужную сторону. Раз сервис так и остался частично в виде монолита, хотелось бы узнать, какие именно метрики его частей отвечают за readness/liveness. Что делать, если 1 за 10 метрик начинает моросить, хотя остальные части монолита в норме?
И еще очень болезненный вопрос для меня - секреты в волте, а как вы их безопасно вытягиваете? Те же логопассы к базам как в приклад подкладываются?
Приветствую!
Т.к livenessProbe отвечает за рестарт Pod'ов, этот хелсчек дёргается наиболее часто. Логика его работы на данный момент проста - мы проверям работоспособность веб-сервера в целом и отвечаем 200.
readinessProbe - с этим хелсчеком ситуация обстоит хитрее. Результат этой пробы говорит о том, готов или не готов Pod принимать трафик. Когда мы дёргаем его, помимо работы веб-сервера, мы проверяем критически важные инфраструктурные компоненты на доступность включая базы, шины данных и т.д.
Что касается самих метрик, то тут тоже всё просто. У нас заведены алерты на все критически важные для инфраструктуры и бизнеса метрики. Если что-то идёт не так, Alertmanager даст нам знать.
Секреты из Vault на данный момент доставляются в k8s с помощью gitlab-ci, но в будущем есть планы усовершенствовать этот способ, добавив монтирование секретов при инициализации контейнера. Таким образом из gitlab-ci этот этап вообще можно будет убрать.
Для секретов из vault - есть довольно удобный оператор vault secrets operator от самого hashicorp. Стабильная штука. Создает CRD и через эти CRD настраивается связь между развернутым приложением и Vault. Не супер секьюрно, так как secrets создаются в кубере как они есть, как если бы вы их деплоили через kubectl apply, и это на тот случай, если секреты не хочется держать в репозитории. Но и не так геморно, если вдруг надо подружить например ArgoCD с Vault через его систему плагинов.
В качестве основной системы мониторинга используем TSDB решение Victoria Metrics
Было бы интересно услышать - почему не Prometheus?
Здравствуй! На предыдущем месте работы мы с коллегами администрировали сотни кластеров Openshift. По дефолту Openshift поставляется с Prometheus. Т.к кластеры были высоконагруженные, метрик было много, Prometheus потреблял очень много ресурсов CPU, RAM, IO. В качестве эксперимента мы подняли на серверах с такими же ресурсами Victoria Metrics и сравнили их работу. Разница в потреблении была в 2-3 раза. Поэтому без лишних раздумий, в Ситидрайве выбор пал на Victoria Metrics. Помимо этого компоненты Виктории легко масштабируются.
Вы забыли добавить, что VictoriaMetrics (VM) является in place replacement Prometheus'а, т.е. она практически полностью дублирует весь функционал, api и т.д Vm'а, поэтому, если вы используете Prometheus или знаете как его использовать, то с высокой долей вероятности вы можете просто заменить его на VM и остальные компоненты системы этого даже не поймут.
Более того, у VM есть отличный собственный функционал длительного хранения метрик без необходимости подключения какого-нибудь внешнего решения вроде Thanos, который для этого нужен Prometheus.
этого признания я давно ждал "прод шатал" - где мои 800 р? когда я с не смог сдать машину?
А если серьезно, то результат супер! Сам в таком сейчас варюсь.
но про 800р осадок остался....... ((( ;)
Вы пишите, что разработали "уникальный chart". А в чем его уникальность?
вопрос про монолит в облаке, понятно что все преимущества переезда ощущаются после распила монолита, когда можно оперировать маленькими автономными кусками приложения. Но в статье говорится что мигрировали именно монолит. Так а в чем собственно преимущества монолита в облаке если деплой по прежнему занимает много времени, скейлинг работает но требует количество ресурсов пропорциональное количеству реплик, стоимость тоже достаточно высокая, т.к. у всех провайдеров стоимость "больших" инстансов высокая (а в "маленькие" он не поместится). Если не секрет, какой примерно был размер артефактов\потребление ресурсов в кубере сразу после переезда?
Как я описал в статье, перед тем как заехать в кубер, монолит на протяжении 2-х лет дробился на части, хотя еще есть над чем работать в этом направлении, например окончательно выпилить всю статику из docker образа, из-за которого он весит примерно 2GB. Что касается бенефитов переезда, то мы ощутили их в полной мере, и в статье о них подробно говорили)
Полезный real-life опыт, интересно почитать. И привязки к конкретным cloud-providers нет, молодцы!
Переезд монолита в k8s. Делаем каршеринг cloud native