Каким образом мы можем улучшить стабильность работы приложения в k8s?

Прежде всего необходимо описать probe для контейнеров в PODе, а также указать ресурсы запросов / лимиты. Затем целесообразно описать антиаффинити для PODов наших приложений, чтобы упростить обработку сбоев на конкретных узлах.

Если в нашем кластере работают как продуктовые, так и тестовые среды, хорошей практикой будет указать node selector и taints/tolerations, чтобы запускать продуктовые приложения на отдельных узлах.

Если нет возможности выделить узлы под продакшн или мы можем выделить особо важные (ядреные) сервисы в рамках продакшн, рекомендуется установить priority classes для них. Также стоит описать бюджет нарушения работы POD для особо важных приложений. В случае использования многопользовательской модели (multitenant) в пространствах имен пользователей следует указывать resourceQuotas и limitRanges.

😱 Завтра цена на курс «AI-агенты для DS» вырастет

Пока вы думаете — другие уже покупают. Что вы теряете, откладывая решение? Как минимум — 10 000 рублей, именно столько вы переплатите завтра. Как максимум — шанс войти в топ-1% дата-сайентистов, которые умеют строить AI-агенты.

🎓 Чему вы научитесь на курсе:
— адаптировать LLM под разные предметные области и данные
— собирать свою RAG-систему: от ретривера и реранкера до генератора и оценки качества
— строить AI-агентов с нуля — на основе сценариев, функций и взаимодействия с внешней средой

Решение за вами.

👉 Купить курс по старой цене

Как разработать самовосстанавливающуюся распределенную службу?

Любая система, которая должна быть способна к самовосстановлению, должна в определенной степени иметь возможность обрабатывать ошибки и разделения (т. е. когда часть системы не может получить доступ к остальной части системы).

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

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

Для облачных приложений эти три узла обычно распределяются по трем зонам доступности.