Недавно мы помогли нашему клиенту Adapty перенести инфраструктуру с managed-сервисов AWS. Теперь она размещена в Kubernetes-кластере на обычных инстансах другого облачного провайдера, но ее можно легко мигрировать в другой ЦОД в случае необходимости. Этот бизнес-кейс во многом показательный: Adapty удалось минимизировать зависимость от поставщика, снизить инфраструктурные затраты на 50%, а также снять некоторые технические ограничения по масштабированию и оптимизации своих приложений.

Статья посвящена так называемым review-окружениям, реализуемым в рамках кластеров Kubernetes. Ранее эта тема затрагивалась, например, в нашем докладе «Лучшие практики CI/CD с Kubernetes и GitLab», но не была там основной темой, поэтому раскрывалась не во всех деталях. Попробую восполнить этот пробел, рассказав, для чего нужны и/или обычно используют review-окружения, как сделать pipeline c review-окружением в GitLab CI/CD, какие могут быть потенциальные проблемы и способы их решения.

Прим. перев.: С ростом числа YAML-конфигураций для K8s-окружений всё более актуальной становится потребность в их автоматизированной проверке. Автор этого обзора не просто отобрал существующие решения для этой задачи, но и на примере Deployment'а посмотрел, как они работают. Получилось весьма информативно для тех, кому эта тема интересна.

TL;DR: В статье сравниваются шесть статических инструментов проверки и оценки YAML-файлов Kubernetes на соответствие лучшим практикам и требованиям.

Рабочие нагрузки Kubernetes, как правило, определяются в форме YAML-документов. Одна из проблем с YAML'ом — сложность задания ограничений или взаимоотношений между файлами манифестов.