Реестр контейнеров Azure: возможности и ограничения SKU

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

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

Реестр контейнеров Azure предлагает три варианта плана тарификации: "Базовый", "Стандартный" и "Премиум". Каждый SKU предлагает различные функции и ограничения, чтобы соответствовать различным сценариям, от разработки программного обеспечения и тестирования до производственных нагрузок.

Каждый SKU включает определенный объем бесплатного хранилища, с дополнительной памятью, доступной по тарифу на ГБ. Каждый номер SKU также имеет другой максимальный предел хранения.

SKU "Базовый", "Стандартный" и "Премиум" предоставляют одинаковые программатические возможности и API для плоскости данных. Они также используют преимущества хранилища образов, полностью управляемого Azure, а для всех SKU по умолчанию включена зональная избыточность в поддерживаемых регионах. Однако номер SKU уровня "Премиум" обеспечивает более широкий спектр функций и имеет более высокие ограничения.

Возможности и ограничения SKU

В следующей таблице приведены сведения о функциях и ограничениях реестра номеров SKU "Базовый", "Стандартный" и "Премиум".

¹ Хранилище включено в ежедневный тариф для каждого уровня. Может использоваться дополнительное хранилище, при этом взимается дополнительная плата в день за каждый ГиБ до достижения предела хранилища для реестра. Сведения о тарифах см. в разделе Цены на службу Реестр контейнеров Azure. Если вам требуется хранилище, превышающее ограничение хранилища реестра, обратитесь в службу поддержки Azure.

² Отдельные действия из content/delete, content/read, content/write, metadata/read, metadata/write соответствуют ограничению количества репозиториев на карту области действия маркера, не относящегося к Microsoft Entra.

ACR также имеет следующие ограничения производительности при загрузке и отправке образов.

Ограничения частоты запросов API

Помимо ограничений хранилища и компонентов в предыдущей таблице, Реестр контейнеров Azure применяет ограничения частоты запросов к API реестра. Ограничения скорости измеряются в запросах в минуту (r/m) и определяются номером SKU реестра. Если скорость запроса превышает ограничение, реестр возвращает ошибку HTTP 429 Too Many Requests . Ответ содержит заголовок, указывающий Retry-After время ожидания перед повторным повтором.

Для запросов действуют ограничения в следующих категориях операций. Каждая категория определяется методами HTTP, используемыми API плоскости данных реестра:

Для каждого номера SKU применяются следующие ограничения скорости запросов:

Ограничения для каждого реестра и идентификатора

• Для каждого реестра действуют ограничения на совокупную частоту запросов от всех клиентов и идентификаторов, обращающихся к одному реестру.
• Ограничения для каждой учетной записи и каждого реестра применяются к частоте запросов от одной учетной записи к одному реестру. Лимиты для каждой идентификационной сущности не позволяют одному клиенту, например сканеру уязвимостей или развертыванию с неверной конфигурацией, исчерпать всю пропускную способность реестра по запросам. Ограничения для одних и тех же учетных данных в каждом реестре отслеживаются отдельно, поэтому учетные данные, которые проходят аутентификацию в нескольких реестрах, не подвергаются общему ограничению для всех этих реестров сразу.
• Для реестра с поддержкой анонимного доступа к запросу на вытягивание все анонимные (не прошедшие проверку подлинности) запросы регулируются в качестве единого удостоверения для этого единого реестра.
• Для реестра с включенной учетной записью администратора все запросы, прошедшие проверку подлинности с учетными данными администратора , регулируются как единое удостоверение для этого единого реестра. У учетной записи администратора есть два пароля (password и password2), но для ограничения частоты запросов оба пароля имеют общий идентификатор. Если несколько клиентов или рабочих процессов автоматизации проходят проверку подлинности с помощью учетных данных администратора, они используют один и тот же сегмент ограничения скорости идентификации.
• Запросы на проверку подлинности и авторизацию OAuth ограничиваются только на уровне реестра, без отдельных ограничений для каждой учетной записи в каждом реестре.

Запросы, засчитываемые в счёт нескольких лимитов

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

Применение ограничений скорости

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

• Короткие всплески выше устойчивой скорости разрешены. Всплеск запросов, например при крупномасштабном развертывании, которое одновременно загружает образы на множество узлов, обрабатывается успешно, пока в бакете остается запас емкости.
• Постоянный трафик не должен превышать предел. Если всплеск опустошает бакет, последующие запросы отклоняются с 429 Too Many Requests до тех пор, пока емкость не восстановится, из-за чего скорость запросов может ограничиваться в течение вплоть до целой минуты после крупного всплеска.

Значение Retry-After в ответе 429 указывает на количество секунд, оставшихся до окончания текущего периода ограничения запросов, поэтому при последовательных запросах, к которым применяется ограничение, это значение уменьшается, а не остается неизменным. Например, первый ответ с ограничением скорости может возвращать Retry-After: 60. Если повторить попытку через 10 секунд и запрос по-прежнему регулируется, ответ возвращается Retry-After: 50. Так как значение вычисляется динамически для каждого запроса, не принимает зависимость от фиксированного Retry-After значения.

При получении ответа 429 учитывайте значение заголовка Retry-After и реализуйте логику повторных попыток с экспоненциальной задержкой. Дополнительные рекомендации по устранению рисков см. в разделе "Регулирование" и "Ограничения пропускной способности".

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

Сведения о ценах на каждый из вариантов SKU Реестр контейнеров Azure см. в разделе Container Registry pricing. Дополнительные сведения о ценах на передачу данных см. в разделе "Цены на пропускную способность".

Ограничения производительности загрузки и передачи образа реестра

Параллелизм API, пропускная способность и ограничение во время операций с большим объемом в основном влияют на производительность получения и загрузки изображений. SKU реестра, конфигурация сети и конфигурация клиента определяют эти факторы.

Ограничения пропускной способности и параллелизма API

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

Следующие факторы влияют на параллелизм API и пропускную способность во время извлечения и отправки изображений:

• Число и размер слоев изображений
• Повторное использование слоев между изображениями в реестре
• Дополнительные вызовы API, необходимые для каждой операции
• Масштаб параллельных развертываний, таких как развертывания Kubernetes, извлекающих образы на нескольких узлах одновременно

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

• Управляющая программа Docker или конфигурация Podman для параллельных операций
• Конфигурация выполнения контейнера, например параметры параллелизма containerd или CRI-O
• Параметры конфигурации кластера или уровня данных кластера

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

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

Дополнительные сведения об операциях API, происходящих во время отправки и извлечения образа, см. в документации по API Docker HTTP версии 2 . Сведения об устранении неполадок см. в разделе "Устранение неполадок с производительностью реестра".

Ограничения регулирования и пропускной способности

В периоды большого объема запросов может возникнуть ограничение с ошибкой HTTP 429 Too many requests или низкой пропускной способностью. Чтобы устранить эти проблемы, выполните следующие действия.

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

Отображение использования реестра

Сведения об использовании помогают принимать решения об изменении номера SKU , когда реестр приближается к ограничению, и помогает управлять потреблением.

Чтобы получить снимок состояния текущего потребления хранилища и других ресурсов реестра по сравнению с ограничениями SKU этого реестра, посмотрите страницу Overview реестра на портале Azure. Вы также можете использовать ТАКИЕ API, как az acr show-usage (Azure CLI), Get-AzContainerRegistryUsage (Azure PowerShell) или Registries — List Usages (REST API).

В зависимости от SKU реестра, сведения об использовании могут включать некоторую или всю нижеперечисленную информацию, а также ограничения в этом SKU.

• Используемое хранилище в байтах
• Количество вебхуков
• Количество георепликации (включает домашнюю реплику)
• Количество частных конечных точек
• Количество правил доступа к IP-адресам
• Количество правил виртуальной сети

В геореплицированном реестре для домашнего региона отображается использование хранилища. Умножьте количество реплик для общего объема хранилища.

Изменение номера SKU реестра

Номер SKU реестра можно изменить на портале Azure или с помощью Azure CLI или Azure PowerShell. Вы можете свободно перемещаться между SKU, если SKU, на который вы переключаетесь, имеет требуемую максимальную емкость хранилища.

При изменении номера SKU реестра отсутствуют время простоя и влияние на его операции. Однако при переходе с уровня "Премиум" на более низкий номер SKU функции, относящиеся к категории "Премиум", отключены. В некоторых случаях необходимо удалить ресурсы, связанные с этими функциями, прежде чем переключать SKU. Например, необходимо удалить все георепликации или подключенные реестры, прежде чем переходить с уровня "Премиум" на "Стандартный" или "Базовый".

Чтобы изменить номера SKU на портале Azure, перейдите в реестр контейнеров. В меню службы в разделе "Параметры" выберите "Свойства". Измените параметр ценового плана и нажмите кнопку "Сохранить".

Чтобы изменить номера SKU с помощью Azure CLI, используйте команду az acr update. Например, чтобы переключиться на Premium, выполните приведенные ниже действия.

az acr update --name myContainerRegistry --sku Premium

Чтобы изменить SKU с помощью Azure PowerShell, используйте командлет Update-AzContainerRegistry. Например, чтобы переключиться на Premium, выполните приведенные ниже действия.

Update-AzContainerRegistry -ResourceGroupName myResourceGroup -Name myContainerRegistry -Sku Premium

Связанный контент

Дополнительные сведения о предстоящих функциях Реестр контейнеров Azure см. в GitHub Roadmap.