Некоторые думают, что достаточно просто перенести приложение на Kubernetes (вручную или с помощью Helm), и будет счастье. Однако на деле не все так просто. Мы уже говорили про настройку запросов пода и лимитов, а также про тесты Liveness и Readiness. Пришло время рассказать о настройке дефолтных сетевых политик пода.

Эта тема нередко обсуждается в Kubernetes-сообществе. Почему же так важно хорошо разбираться в тестах готовности (Readiness) и жизнеспособности (Liveness)? Потому что они как минимум обеспечивают устойчивую работу ПО, минимизируя время простоя. К тому же, если тесты настроены неправильно, они могут существенно повлиять на производительность вашего приложения.

Так как DevOps-инженер отвечает за автоматизацию процессов на всех этапах разработки ПО, он обязан понимать, как устроен процесс разработки в целом, начиная от построения архитектуры, заканчивая доставкой приложения пользователям. Разумеется, еще он должен владеть DevOps-инструментами. Но ведь это еще далеко не все.

Если решение какой-нибудь задачи предполагает наличие конфиденциальной информации (к примеру, доступ в базу данных), неплохой практикой является хранение данной информации в зашифрованном виде. Создавать и управлять шифрованными файлами позволяет утилита командной строки ansible-vault, поставляемая вместе с Ansible.

Предлагаем вам несколько простых советов на тему того, как заставить Ansible работать быстрее.

В этой статье мы вкратце рассмотрим ключевые особенности и структуру Ansible, его установку и запуск, а также модули и архитектуру.

Kubernetes прекрасно справляется с обработкой состояний отказа и планированием подов. Однако на практике планировщик порой не может разместить под. Это происходит, если он затрудняется оценить, какое количество ресурсов ему требуется для успешной работы. Специалисты до сих пор спорят, какой подход к настройке лимитов и запросов является наилучшим. Порой возникает ощущение, что это скорее искусство, чем наука. Об этом — наша статья.

Нередко бывает, что программы ломаются, а серверы падают. Вряд ли этого можно избежать со 100%-ной вероятностью. Скачок напряжения, случайный баг, сбои в подаче электроэнергии — эти и многие другие факторы способны вызвать поломки. Минимизировать вероятность появления проблемы поможет мониторинг.

Иногда приходится перетряхивать инфраструктуру, делая это самым радикальным образом. Такой шаг устраняет недостатки старых версий вашей системы, позволяет обновить технологии и снизить расходы. Рассмотрим основные причины, которые могут подтолкнуть к миграции серверов:

Как известно, мониторинг и логирование позволяют поддерживать работоспособность современной IT-инфраструктуры. Если же речь идёт о микросервисной архитектуре, то мониторинг приобретает ещё большую важность. И это очевидно, ведь когда компонентов больше, больше и зависимостей, не говоря уже о повышенных требованиях к отказоустойчивости.