rolling update что это

Стратегии деплоя в Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-тестирование)

Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.

Схема взята из другого обзора стратегий выката, сделанного в Container Solutions

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

Более короткие и частые развертывания имеют следующие преимущества:

В этой публикации мы обсудим различные стратегии деплоя в Kubernetes, в том числе rolling-развертывания и более продвинутые методы, такие как канареечные (canary) выкаты и их разновидности.

Стратегии деплоя

Существует несколько различных типов стратегий развертывания, коими можно воспользоваться в зависимости от цели. Например, вам может потребоваться внести изменения в некое окружение для дальнейшего тестирования, или в подмножество пользователей/клиентов, или возникнет необходимость провести ограниченное тестирование на пользователях, прежде чем сделать некую функцию общедоступной.

Rolling (постепенный, «накатываемый» деплой)

Это стандартная стратегия развертывания в Kubernetes. Она постепенно, один за другим, заменяет pod’ы со старой версией приложения на pod’ы с новой версией — без простоя кластера.

Kubernetes дожидается готовности новых pod’ов к работе (проверяя их с помощью readiness-тестов), прежде чем приступить к сворачиванию старых. Если возникает проблема, подобное накатываемое обновление можно прервать, не останавливая всего кластера. В YAML-файле с описанием типа deployment’а новый образ заменяет собой старый образ:

Параметры накатываемого обновления можно уточнить в файле манифеста:

Recreate (повторное создание)

В этом простейшем типе развертывания старые pod’ы убиваются все разом и заменяются новыми:

Соответствующий манифест выглядит примерно так:

Blue/Green (сине-зеленые развертывания)

Стратегия сине-зеленого развертывания (иногда ее ещё называют red/black, т.е. красно-чёрной) предусматривает одновременное развертывание старой (зеленой) и новой (синей) версий приложения. После размещения обеих версий обычные пользователи получают доступ к зеленой, в то время как синяя доступна для QA-команды для автоматизации тестов через отдельный сервис или прямой проброс портов:

После того, как синяя (новая) версия была протестирована и был одобрен ее релиз, сервис переключается на неё, а зеленая (старая) сворачивается:

Canary (канареечные развертывания)

Канареечные выкаты похожи на сине-зеленые, но лучше управляются и используют прогрессивный поэтапный подход. К этому типу относятся несколько различных стратегий, включая «скрытые» запуски и А/В-тестирование.

Эта стратегия применяется, когда необходимо испытать некую новую функциональность, как правило, в бэкенде приложения. Суть подхода в том, чтобы создать два практически одинаковых сервера: один обслуживает почти всех пользователей, а другой, с новыми функциями, обслуживает лишь небольшую подгруппу пользователей, после чего результаты их работы сравниваются. Если все проходит без ошибок, новая версия постепенно выкатывается на всю инфраструктуру.

Хотя данную стратегию можно реализовать исключительно средствами Kubernetes, заменяя старые pod’ы на новые, гораздо удобнее и проще использовать service mesh вроде Istio.

Например, у вас может быть два различных манифеста в Git: обычный с тегом 0.1.0 и «канареечный» с тегом 0.2.0. Изменяя веса в манифесте виртуального шлюза Istio, можно управлять распределением трафика между этими двумя deployment’ами:

Пошаговое руководство по реализации канареечных развертываний с помощью Istio можно найти в материале GitOps Workflows with Istio. (Прим. перев.: Мы также переводили материал про канареечные выкаты в Istio здесь.)

Канареечные развертывания с Weaveworks Flagger

Weaveworks Flagger позволяет легко и эффективно управлять канареечными выкатами.

Flagger автоматизирует работу с ними. Он использует Istio или AWS App Mesh для маршрутизации и переключения трафика, а также метрики Prometheus для анализа результатов. Кроме того, анализ канареечных развертываний можно дополнить вебхуками для проведения приемочных (acceptance) тестов, нагрузочных и любых других типов проверок.

На основе deployment’а Kubernetes и, при необходимости, горизонтального масштабирования pod’ов (HPA), Flagger создает наборы из объектов (deployment’ы Kubernetes, сервисы ClusterIP и виртуальные сервисы Istio или App Mesh) для проведения анализа и реализации канареечных развертываний:

Реализуя контур управления (control loop), Flagger постепенно переключает трафик на канареечный сервер, параллельно измеряя ключевые показатели производительности, такие как доля успешных HTTP-запросов, средняя продолжительность запроса и здоровье pod’ов. Основываясь на анализе KPI (ключевых показателей эффективности), канареечная часть либо растет, либо сворачивается, и результаты анализа публикуются в Slack. Описание и демонстрацию этого процесса можно найти в материале Progressive Delivery for App Mesh.

Dark (скрытые) или А/В-развертывания

Скрытое развертывание — еще одна вариация канареечной стратегии (с ней, кстати, Flagger тоже может работать). Разница между скрытым и канареечным развертыванием состоит в том, что скрытые развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.

Другое название этих развертываний — А/В-тестирование. Вместо того, чтобы открыть доступ к новой функции всем пользователям, ее предлагают лишь ограниченной их части. Обычно эти пользователи не знают, что выступают тестерами-первопроходцами (отсюда и термин «скрытое развертывание»).

С помощью переключателей функциональности (feature toggles) и других инструментов можно следить за тем, как пользователи взаимодействуют с новой функцией, увлекает ли она их или они считают новый пользовательский интерфейс запутанным, и другими типами метрик.

Flagger и A/B-развертывания

Помимо маршрутизации с учётом весов, Flagger также может направлять на канареечный сервер трафик в зависимости от параметров HTTP. При А/В-тестировании можно использовать заголовки HTTP или файлы cookie для перенаправления определенного сегмента пользователей. Это особенно эффективно в случае frontend-приложений, требующих привязки сессии к серверу (session affinity). Дополнительную информацию можно найти в документации Flagger.

Автор выражает благодарность Stefan Prodan, инженеру Weaveworks (и создателю Flagger), за все эти потрясающие схемы деплоя.

Источник

Русские Блоги

Kubernetes Rolling Обновление боя

1. Фон

2. Шаги

2.1 Развертывание начальной версии Развертывание.

YAML начального развертывания выглядит следующим образом:

2.2 Обновите первоначальную версию.

Обновление до 2.4.31, YAML выглядит следующим образом:

Заметим еще раз позже:

В этом процессе мы обнаружим, что ReplicaSet развертывание-развертывание-5fb9c69c5c постепенно заменяется развертыванием-развертывание-54766f574f. После создания новой версии модуля первоначальная версия модуля прекращается. Это гладкий процесс обновления. Kubernetes предоставляет два параметра maxSurge и maxUnavailable для точного управления количеством замен Pod.

Откат версии 2.3.

По умолчанию Kubernetes сохранит только самые последние версии. В описанном выше процессе обновления количество ревизий устанавливается с помощью revisionHistoryLimit. Давайте посмотрим на команду:

Продолжайте обновлять. Новая версия YAML выглядит следующим образом:

Выполните обновление и запишите журнал обновлений.

Измените версию образа в файле YAML, чтобы продолжить обновление, и просмотрите результат обновления:

Образы httpd были обновлены до 2.4.35, затем мы пытаемся откатиться до версии v2:

3. Резюме

3.1 Еще раз убедившись в прелести Kubernetes, обновление / выпуск / обновление в оттенках серого при нормальной работе (остановка экземпляров старых версий в пакетном режиме, включение экземпляров новых версий, сосуществование с новыми и старыми версиями, постепенное расширение диапазона новых версий и, наконец, всех пользователей Миграция на новую версию), сине-зеленое обновление / выпуск / обновление (не останавливайте старую версию и не развертывайте новую версию, новая версия будет удалена после выпуска теста), переход на обновление / выпуск / обновление (одна или несколько служб) Остановите, выполните обновление и постепенно используйте новую версию, а затем начните снова и снова и, наконец, завершите обновление версии всех экземпляров во всем кластере). Эти концепции более понятны.

3.2 В настоящее время некоторая информация больше не применима к новой версии. Не вводите в заблуждение информацию в Интернете. Вы должны опираться на официальные документы и системную помощь. Например:

Команды, связанные с Deploy в Kubernetes:

Развернуть доступные типы ресурсов:

3.3 Развертывание обновления также может быть достигнуто через YAML, который будет представлен в последующих статьях.

Источник

Русские Блоги

Очередное обновление сервиса в кластере Kubernetes

1. Предварительные знания

1. Роллинг-обновление

б) «Роллинг» может быть вперед или назад. В процессе обновления мы можем вовремя обнаружить проблемы в «обновлении» и выполнить «откат назад», чтобы выполнить откат обновления, что может минимизировать риск каждого обновления.

ДляРазвертывание кластера KubernetesЧто касается Сервиса, под «постоянным обновлением» подразумевается только обновление одного модуля за раз и их обновление по одному вместо одновременного отключения всех модулей в рамках службы, чтобы избежать затруднений, связанных с прерыванием работы.

2. Связь между службой, развертыванием, набором реплик, контроллерами репликации и модулем

Для приложения, которое мы хотим развернуть, оно обычно состоит из нескольких абстрактных сервисов. В Куберне,Serviceпоlabel selectorСовпадая с набором модулей, эти модули, как конечные точки услуг, являются объектами, которые фактически несут услуги. Развертывание, планирование и обслуживание количества копий Pod в кластере осуществляются черезDeploymentилиReplicationControllersЭти высокоуровневые абстракции управляются, ниже приведена принципиальная схема:

Рекомендуется для новой версии KubernetesDeploymentВместо ReplicationController то, что на самом деле играет роль в поддержании количества копий Pod в соответствии с концепцией развертывания, скрыто заReplica Set。

Два, команда kubectl Rolling-Update

Теперь давайте посмотрим на пример, чтобы увидеть, как kubectl roll-update выполняет обновление обновлений для модулей Pod в процессе обслуживания. Наш кластер kubernetes имеет две версииNginx：

В этом примере мы перевели Service Pod с nginx 1.10.1 на 1.11.9.

Содержимое нашего файла rc-demo-v0.1.yaml выглядит следующим образом:

Содержимое файла манифеста службы rc-demo-svc.yaml выглядит следующим образом:

Создайте этот сервис:

Вы можете видеть, что все 4 модуля, созданные предыдущим контроллером репликации, помещены в службу rc-demo-svc.

Далее, давайте накатим обновление rc-demo-nginx-v0.1 этого rc, наш новый rc-demo-v0.2.yaml файл манифеста rc выглядит следующим образом:

Существует несколько различий между rc-demo-new.yaml и rc-demo-old.yaml: имя rc, версия изображения и значение переменной окружения RC_DEMO_VER:

Мы начинаем непрерывное обновление, чтобы упростить отслеживание процесса обновления, здесь устанавливаем период обновления равным 10 с, то есть обновляем Pod каждые 10 с:

Из журнала видно, что kubectl roll-update постепенно увеличивает масштаб rc-demo-nginx-v0.2 и в то же время постепенно уменьшает масштабное значение rc-demo-nginx-v0.1, пока не достигнет 0.

В процессе обновления мы продолжали посещать rc-demo-svc, и мы могли видеть статус сосуществования старой и новой версий Pod, и служба не была прервана:

Некоторая обновленная информация о статусе:

В roll_updater.go метод Update использует цикл for для постепенного сокращения реплик старого rc и увеличения реплик нового rc до тех пор, пока новый rc не достигнет желаемого значения, а реплики старого rc не станут равными 0.

Скользящее обновление, реализованное с помощью kubectl rolling-update, имеет много недостатков:
— Реализовано kubectl, обновление может быть прервано по сетевым причинам;
-Для создания нового rc имя не может совпадать с именем rc, подлежащего обновлению, хотя эта проблема невелика, реализовать ее довольно неудобно;
— Откат назад также необходимо выполнить обновление-обновление, просто используйте старую версию файла манифеста rc;
-Катализированное обновление, выполняемое службой, не записывается в кластер, и история скользящего обновления не может отслеживаться позже.

Однако, поскольку контроллер репликации постепенно заменяется абстрактной концепцией развертывания, давайте рассмотрим, как реализовать скользящее обновление развертывания, и преимущества развертывания с развертыванием.

Три, обновление обновления развертывания

Давайте также посмотрим на пример. Мы создаем первую версию файла манифеста развертывания: deploy-demo-v0.1.yaml.

Deployment-demo создает ReplicaSet: deploy-demo-1818355944, который используется для гарантии количества реплик Pod.

Давайте создадим Сервис, который использует модули в развертывании:

Итак, мы видим, что под службой есть четыре модуля, и служба, предоставляемая службой, также работает нормально.

Далее мы обновляем сервис. Для удобства объяснения мы создали файл deploy-demo-v0.2.yaml. На самом деле вам не нужно создавать другой файл. Вы можете изменить его непосредственно в файле deploy-demo-v0.1.yaml выше:

Мы используем файл deploy-demo-v0.2.yaml для обновления модулей в созданных ранее развертываниях:

Команда применения получает и завершает ответ, возвращенный сервером в одно мгновение. Но процесс непрерывного обновления развертывания все еще продолжается:

Мы видим изменения в ReplicaSet во время процесса обновления, и служба не прерывается во время этого процесса, но старая и новая версии кратко чередуются для предоставления услуг:

В конце концов все модули были заменены версией v0.2:

Мы обнаружили, что обе команды создания и применения развертывания содержат параметр –record, который сообщает серверу записи истории обновлений. Вы можете просмотреть историю обновлений развертывания через историю развертывания kubectl:

Если вы не добавите «–record», то история, которую вы получите, будет похожа на этот результат:

В то же время мы увидим, что старый ReplicaSet не был удален:

Эта информация хранится на стороне сервера, что удобно для отката!

Операция отката Pod при развертывании очень проста, и ее можно выполнить, отменив развертывание. Отмена отката откатит Развертывание до предыдущей ревизии в записи (см. Столбец ревизий в выводе истории развертывания выше):

Статус rs снова полностью изменен:

Посмотреть историю обновлений:

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

Источник

Kubernetes: типы Deployment Strategies и Argo Rollouts

Одна из целей, которые мы преследуем внедряя ArgoCD в Kubernetes – использование новых Deployment Strategies для наших приложений.

Ниже рассмотрим типы деплойментов в Kubernetes, как работают Deployment в Kubernetes, и быстрый пример использования Argo Rollouts, который более детально будем рассматривать в следущих постах.

Deployment Strategies и Kubernetes

Кратко рассмотрим стратегии деплоя, имеющиеся в Kubernetes.

Также, Kubernetes позволяет реализовать аналоги Canary и Blue-Green deployments, хотя с ограничениями.

Recreate

Тут всё достаточно просто: при этой стратегии, Kubernetes останавливает все запущенные в Deployment поды, и на их месте запускает новые.

Очевидно, что при таком подходе будет определённый даунтайм : пока остановятся старые поды (см. Pod Lifecycle — Termination of Pods), пока запустятся новые, пока они пройдут все Readiness проверки – приложение будет недоступно для пользователей.

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

Пример такого деплоймента:

Деплоим version: «1.0» :

Оба пода убиваются, и затем создаются новые:

Rolling Update

С RollingUpdate всё немного интереснее: тут Kubernetes запускает новые поды параллельно с запущенными старыми, а затем убивает старые, и оставляет только новые. Таким образом, в процессе деплоя некоторое время одновременно работают две версии приложения – и старое, и новое. Является типом по-умолчанию.

При таком подходе получаем zero downtime, так как в процессе обновления часть подов со старой версией остаётся жива.

Из недостатков – могут быть ситуации, когда такой подход неприменим. Например, если при старте подов выполняются MySQL-миграции, которые меняют схему базы данных таким образом, что предыдущая версия приложения не сможет её использовать.

Пример такого деплоймента:

Источник

Kubernetes Best Practices: 8 практических советов, которые помогут получить от Kubernetes максимум пользы

Kubernetes — сложный инструмент, и, чтобы получить от него полную отдачу, нужно правильно его настроить и использовать.

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

Совет 1: не используйте тег latest при развертывании приложений

При развертывании приложений через Deployment не используйте тег latest в образах контейнеров.

Тег latest — скользящий тег, который всегда указывает на самую последнюю версию образа. Сегодня он указывает на версию v1, а через неделю это может быть версия v2. И в этом кроются две проблемы:

1. Например, мы развернули Deployment, указав тег latest. На момент создания пода этот тег указывал на версию приложения v1. Через некоторое время у приложения вышла версия v2. А еще через некоторое время отказал узел, на котором работал этот под. Kubernetes перезапустит этот под на другом узле.

Когда под перезапускается, он заново перечитывает Deployment-файл. Так как тег latest теперь ссылается на версию v2, то именно ее Kubernetes запустит внутри нового пода. И может оказаться так, что новая версия обратно несовместима или содержит ошибки. Если же вместо тега latest явно указать нужную нам версию v1, то при перезапуске пода все останется как раньше.

2. Другой пример. Мы развернули Deployment, снова указав тег latest в имени образа. В тот момент этот тег ссылался на версию приложения v1, а через некоторое время у приложения вышла версия v2. Затем мы решили изменить Deployment и развернули его новую версию.

Но что-то пошло не так: приложение не запускается или работает с ошибками. Если бы мы указали явно нужную нам версию, мы бы могли использовать команду rollout и откатиться на предыдущую версию стандартными средствами Kubernetes. Но так как тег latest уже ссылается на новую версию приложения, rollout не поможет: Kubernetes снова развернет версию приложения v2.

Поэтому вместо использования тега latest лучше явно указывать нужную версию образа. А потом при необходимости обновлять ее и тестировать, прежде чем выкатывать обновление в продакшен.

Совет 2: используйте пространства имен для разделения ресурсов

Kubernetes позволяет разделять ресурсы кластера на пространства имен, это своего рода отдельные виртуальные кластеры. Рекомендуется разделять Namespace:

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

В небольших кластерах это делать необязательно, но в крупных очень желательно. Разделение по пространствам имен дает несколько преимуществ:

Совет 3: используйте метки и аннотации для классификации объектов

Метки и аннотации — это параметры типа «ключ/значение», которые позволяют добавить метаданные к любым объектам Kubernetes: узлам, подам, сервисам и так далее. Их нужно указывать на всем, что деплоится в кластер.

Метки служат для идентификации объектов, позволяют группировать их и массово ими управлять. Например, вы можете пометить все объекты, относящиеся к одному приложению, окружению или команде.

Пример указания меток в деплойменте:

В этом примере мы помечаем, что данный объект Kubernetes относится к приложению nginx и работает в продакшене.

Можно создавать любые метки, которые вам нужны. Но также есть список меток, которые рекомендуется добавлять ко всем объектам:

Метки упрощают управление инфраструктурой. Самый простой вариант использования — получить список объектов, у которых есть определенные метки. В этом примере мы получаем список подов, которые запущены в продакшене и относятся к фронтенду:

Другой вариант — при развертывании подов можно указать, что их нужно запускать только на узлах с определенной меткой. В этом примере Deployment-файла мы позволяем подам запускаться только на узлах с меткой node=mynode:

Аннотации позволяют хранить любую служебную информацию, которая может быть полезна командам DevOps. Например, в аннотацию пода можно записывать идентификатор создавшего его пайплайна, ссылку на репозиторий с приложением или контакты ответственного разработчика.

Пример указания аннотаций в деплойменте:

Ссылки на документацию по меткам и аннотациям.

Совет 4: устанавливайте запросы и ограничения на ресурсы

Kubernetes позволяет устанавливать для подов запросы и ограничения, которые помогают лучше управлять ресурсами кластера: CPU и RAM. Они указываются в Deployment-файле.

Запросы (requests) — это ресурсы, которые контейнер гарантированно получит. То есть это своего рода минимальные системные требования, которые нужны приложению для работы. Kubernetes всегда планирует размещение подов на узлах так, чтобы обеспечить необходимые запросы для всех подов.

Ограничения (limits) — это максимальные значения выделяемых ресурсов. Kubernetes гарантирует, что приложение никогда не получит больше ресурсов, чем указано в ограничениях.

Если под попытается превысить ресурс, Kubernetes поступит по-разному в зависимости от типа ресурса.

Пример указания запросов и лимитов в деплойменте:

В этом примере приложение гарантированно получит 64 Мб оперативной памяти и 250 миллиядер. Максимальные значения, которые Kubernetes не превысит — 128 Мб памяти и 500 миллиядер.

Механизма запросов и ограничений должно быть достаточно, чтобы корректно управлять ресурсами кластера. Но часто бывают ситуации, когда разработчики забывают указывать requests и limits или указывают их явно высокими, чтобы приложение работало наверняка. В результате Kubernetes может выделять приложениям излишние ресурсы. Поэтому администраторы могут ограничить полнстью пространство имен при помощи ResourceQuota.

ResourceQuota — это аналог limits и requests, но только для целого пространства имен. Это суммарные ограничения, которые действуют на все контейнеры, работающие внутри Namespace. Рассмотрим пример:

Что тут происходит:

Есть несколько вариантов практического применения ResourceQuota. Например, в одном кластере работают две команды разработчиков, у каждой из которых свой Namespace. Можно наложить ограничения, чтобы одна команда не могла занять больше половины ресурсов. Другая хорошая практика: ограничить пространства имен для сред разработки и тестирования, но не ограничивать продуктивную.

Совет 5: не управляйте подами вручную — используйте Deployment

Под — минимальная единица, которой оперирует Kubernetes. При желании можно управлять подами вручную: создавать, запускать и останавливать. Но это не лучший способ, потому что Kubernetes не следит за «ручными» подами. В этом случае пропадают многие возможности автоматизации. Вместо ручного управления подами всегда используйте Deployment.

Вот что плохого в ручном управлении подами:

Совет 6: используйте проверки работоспособности приложений

В Kubernetes есть механизм, который позволяет определять работоспособность ваших приложений. Kubernetes отправляет приложению запрос (HTTP-запрос, TCP-соединение или произвольная команда) и ждет ответа. Если приложение отвечает, что с ним все хорошо, значит, проверка прошла успешно. Если приложение не отвечает или отвечает с ошибкой, значит, проверка работоспособности не прошла. И тогда в зависимости от типа проверки Kubernetes поступает по-разному.

Всего есть три типа проверок:

Совет 7: минимизируйте образ и убирайте ненужные зависимости

Для создания собственных приложений за основу часто берут готовые образы других приложений и сред, они называются родительскими образами. Например, при разработке приложения на Node.js часто используется публичный официальный образ из Docker Hub. Также само приложение может иметь множество зависимостей в виде npm-пакетов.

В Kubernetes рекомендуется минимизировать образы ваших программ и их зависимостей. Это даст несколько преимуществ:

В любом образе или зависимости могут быть уязвимости. Чем меньше зависимостей, тем меньше векторов для возможных атак.

Для хранения образов так или иначе нужно место. Если вы используете облачное хранилище, то чем больше места занимают образы, тем больше вы будете платить. Если вы используете локальное хранилище, то со временем оно закончится и нужно будет докупать диски.

Особенно это актуально для крупных компаний, где много разных команд и приложений. Есть реальные случаи, когда команды создавали образы по 1–2 Гб, хотя «полезного» веса в них было всего на 200–300 Мб. Если каждая команда будет создавать такие огромные образы, то компании понадобится очень много места для их хранения.

Если узел с запущенным приложением упадет, Kubernetes перезапустит его на другом узле. При этом он заново скачает образ. Если образ весит много, приложение будет долго запускаться. Есть большая разница в скорости развертывания образа в 300 Мб и 2 Гб. Это может быть особенно важно, если вашим приложениям важна высокая скорость развертывания.

К тому же если ваш облачный провайдер взимает плату за трафик, то придется платить лишние деньги за скачивание публичных образов из Docker Hub, npm-пакетов или других зависимостей. VK Cloud Solutions (бывш. MCS) предоставляет бесплатный входящий и исходящий трафик при использовании управляемого Kubernetes, но так бывает не всегда.

Один из способов уменьшить образ приложения — правильно выбрать родительский образ. Как правило, для всех популярных образов существует минимум три варианта:

Для примера, стандартный образ Node.js весит более 900 Mб, версия Slim — 160 Mб, а версия Alpine — 112 Mб.

Если вы только начинаете в это погружаться, используйте базовые версии. Если у вас уже есть некоторый опыт, можете попробовать версии Slim или Alpine. Но обязательно протестируйте свое приложение, так как в этих образах может отсутствовать компонент или библиотека, которые вы используете.

Источник