Características y límites de SKU de Azure Container Registry

Azure Container Registry está disponible en varias SKU. Estas referencias, también conocidas como planes de precios o niveles, admiten precios predecibles y se alinean con diferentes patrones de uso y capacidad del registro de contenedores privado en Azure.

Al crear un registro, seleccione un plan de precios que determine las características y los límites del registro. Elija el plan que se alinea con los patrones de uso esperados, como el número de imágenes, las necesidades de almacenamiento y los requisitos de rendimiento.

Azure Container Registry ofrece tres opciones de Pricing Plan: Básico, Estándar y Premium. Cada SKU ofrece un conjunto diferente de características y límites para dar cabida a varios escenarios, desde el desarrollo y las pruebas hasta las cargas de trabajo de producción.

Cada SKU incluye una cantidad específica de almacenamiento gratuito, con almacenamiento adicional disponible a una tarifa por GB. Cada SKU también tiene un límite de almacenamiento máximo diferente.

Las SKU Básicas, Estándar y Premium proporcionan las mismas funcionalidades de programación y API del plano de datos. También se benefician de almacenamiento de imágenes administrado íntegramente por Azure, y todas las SKU tienen redundancia de zona habilitada de forma predeterminada en las regiones admitidas. Sin embargo, la SKU Premium permite una gama más amplia de características y tiene límites más altos.

Características y límites de SKU

En la tabla siguiente se detallan las características y los límites del Registro de las SKU Básicas, Estándar y Premium.

¹ Almacenamiento incluido en la tarifa diaria para cada nivel. Se puede usar más almacenamiento, hasta el límite que imponga el almacenamiento del registro, con una tarifa diaria por GiB adicional. Para obtener información sobre tarifas, consulte los precios de Azure Container Registry. Si necesita almacenamiento más allá del límite de almacenamiento del Registro, póngase en contacto con Azure soporte técnico.

² Las acciones individuales de content/delete, content/read, content/write, metadata/read, metadata/write corresponden al límite de repositorios por mapa de ámbito de tokens que no sean de Microsoft Entra.

ACR también tiene los siguientes límites de rendimiento de extracción e inserción de imágenes.

Límites de velocidad de solicitudes de API

Además de los límites de almacenamiento y características de la tabla anterior, Azure Container Registry aplica los límites de velocidad de solicitudes en las API del Registro. Los límites de tasa se miden en solicitudes por minuto (r/m) y dependen de la SKU del registro. Cuando la tasa de solicitudes supera un límite, el registro devuelve un error HTTP 429 Too Many Requests . La respuesta incluye un Retry-After encabezado que indica cuánto tiempo se debe esperar antes de volver a intentarlo.

Las solicitudes se limitan en las siguientes categorías de operación. Cada categoría se define mediante los métodos HTTP utilizados por las API del plano de datos del Registro:

Se aplican los siguientes límites de velocidad de solicitud para cada SKU:

Límites por registro y por identidad

• Los límites por registro se aplican a la tasa de solicitudes combinada de todos los clientes e identidades a un único registro.
• Los límites por identidad por registro se aplican a la tasa de solicitudes de una sola identidad a un único registro. Los límites por identidad impiden que un único cliente, como un analizador de vulnerabilidades o una implementación mal configurada, consuma toda la capacidad de solicitud de un registro. Los límites por identidad y por registro se aplican por separado a cada registro, por lo que una identidad que se autentica en varios registros no se limita de forma conjunta entre ellos.
• En el caso de un registro que tenga habilitado el acceso de extracción anónimo no autenticado , todas las solicitudes anónimas (no autenticadas) se limitan como una sola identidad para ese registro único.
• Para un registro que tenga habilitada la cuenta de usuario administrador , todas las solicitudes que se autentican con credenciales de administrador se limitan como una única identidad para ese registro único. La cuenta de administrador tiene dos contraseñas (password y password2), pero ambas contraseñas comparten la misma identidad con fines de limitación. Si varios clientes o flujos de trabajo de automatización se autentican con credenciales de administrador, todos consumen el mismo cubo de límite de velocidad por identidad.
• Las solicitudes de autenticación y autorización de OAuth solo están sujetas a límites por registro, sin límites independientes por identidad dentro de cada registro.

Solicitudes que cuentan con varios límites

Algunas solicitudes se contabilizan en más de una categoría de operaciones, y la solicitud se restringe si se supera cualquiera de los límites aplicables. Por ejemplo, una solicitud para listar las referencias de un manifiesto es a la vez una solicitud de tipo ListReferrers y una solicitud de tipo DataplaneRead, y consume capacidad de los dos límites. Si el registro ya ha agotado su límite de DataplaneRead, las solicitudes de referencia también se limitan, incluso si no se ha alcanzado el límite de ListReferrers. Del mismo modo, una alta tasa de solicitudes de referentes reduce la capacidad de DataplaneRead disponible para otras operaciones de lectura, como la extracción de imágenes.

Aplicación de los límites de velocidad

Los límites de velocidad se aplican mediante un algoritmo de cubo de tokens. Cada categoría de operación tiene un cubo de capacidad de solicitud que se rellena continuamente a la velocidad que se muestra en la tabla anterior. Este enfoque está diseñado para tolerar cargas de trabajo con picos:

• Se permiten ráfagas cortas por encima de la velocidad constante. Un pico de solicitudes, como un despliegue a gran escala que descarga imágenes en muchos nodos al mismo tiempo, tiene éxito siempre que siga habiendo capacidad en el contenedor.
• El tráfico sostenido debe permanecer en o por debajo del límite. Si una ráfaga vacía el depósito, las solicitudes posteriores se rechazan con 429 Too Many Requests hasta que la capacidad se recupere, lo que puede hacer que las solicitudes queden limitadas durante hasta un minuto completo después de una ráfaga grande.

El valor de Retry-After en una respuesta 429 indica el número de segundos restantes hasta que finaliza el periodo de limitación actual, por lo que va disminuyendo en las solicitudes consecutivas sujetas a limitación en lugar de mantenerse fijo. Por ejemplo, la primera respuesta con limitación de velocidad podría devolver Retry-After: 60. Si lo intenta de nuevo 10 segundos después y la solicitud sigue limitada por frecuencia, la respuesta devuelve Retry-After: 50. Dado que el valor se calcula dinámicamente para cada solicitud, no tome una dependencia en un valor fijo Retry-After .

Cuando reciba una respuesta 429, respete el encabezado Retry-After e implemente una lógica de reintento con retroceso exponencial. Para obtener más instrucciones de mitigación, consulte Limitación y restricciones de ancho de banda.

En ocasiones, durante un aumento repentino y agresivo desde un nivel de referencia bajo (por ejemplo, un caso de “thundering herd”), es posible que observe temporalmente un rendimiento inferior a los límites publicados mientras la infraestructura del registro se amplía horizontalmente para satisfacer la demanda.

Para obtener información sobre los precios de cada una de las SKU de Azure Container Registry, consulte precios de Container Registry. Para más información sobre los precios de las transferencias de datos, consulte Precios de ancho de banda.

Límites de rendimiento en la extracción e inserción de imágenes del registro

El rendimiento de extracción e inserción de imágenes se ve afectado principalmente por la simultaneidad de las API, el rendimiento de ancho de banda y la limitación durante las operaciones de gran volumen. La SKU del Registro, la configuración de red y la configuración del cliente determinan estos factores.

Límites de concurrencia y capacidad de ancho de banda de la API

El SKU determina la concurrencia de API y el rendimiento de ancho de banda. Las SKU más altas admiten más operaciones simultáneas y mayor ancho de banda para las operaciones del plano de datos, como enumerar, eliminar, insertar y extraer imágenes.

Los siguientes factores afectan la concurrencia de API y el ancho de banda durante las operaciones de pull y push de imágenes:

• Número y tamaño de las capas de imagen
• Reutilización de capas entre imágenes en el Registro
• Llamadas API adicionales necesarias para cada operación
• Escala de implementaciones concurrentes, como implementaciones de Kubernetes que descargan imágenes en varios nodos a la vez.

Los siguientes factores de entorno de cliente afectan al rendimiento:

• Configuración del demonio de Docker o de Podman para operaciones simultáneas
• Configuración del entorno de ejecución de contenedores, como la configuración de containerd o la simultaneidad en contenedores CRI-O
• Configuración del clúster o configuración del plano de datos del clúster

Los siguientes factores de red afectan al rendimiento:

• Ancho de banda de red y latencia para los saltos de red de los clientes al registro
• Configuración de red del lado cliente, como reglas de firewall y configuración de proxy
• Distancia geográfica al registro o a la réplica más cercana si se replica geográficamente

Para más información sobre las operaciones de API que se producen durante la inserción y extracción de imágenes, consulte la documentación de La API HTTP de Docker V2 . Para obtener ayuda para solucionar problemas, consulte Solución de problemas de rendimiento del Registro.

Regulación y restricciones de ancho de banda

Durante períodos de gran volumen de solicitudes, puede experimentar limitaciones con un error HTTP 429 Too many requests o un bajo rendimiento de ancho de banda. Para mitigar estos problemas:

• Implementación de lógica de reintentos con retroceso exponencial y vibración.
• Reduzca la tasa de solicitudes simultáneas.
• Espacie las implementaciones a gran escala para reducir las extracciones simultáneas de imágenes en varios nodos.
• Si experimenta una limitación de velocidad tras un aumento repentino del tráfico desde un nivel previamente bajo, es posible que temporalmente observe un rendimiento inferior mientras la infraestructura del registro se escala horizontalmente para satisfacer la demanda.

Visualización de la utilización del registro

La información de uso le ayuda a tomar decisiones sobre cómo cambiar la SKU cuando el registro se aproxima a un límite y le ayuda a administrar el consumo.

Para obtener una instantánea del consumo actual de almacenamiento y otros recursos por parte de su registro, en comparación con los límites de la SKU de ese registro, consulte la página Overview de su registro en el portal de Azure. También puede usar API como az acr show-usage (CLI de Azure), Get-AzContainerRegistryUsage (Azure PowerShell) o Registries- List Usages (API REST).

Dependiendo del SKU de tu registro, la información de uso puede incluir algunos o todos los siguientes elementos, junto con el límite de ese SKU.

• Almacenamiento consumido en bytes
• Número de webhooks
• Número de replicaciones geográficas (incluye la réplica principal)
• Número de puntos de conexión privados
• Número de reglas de acceso IP
• Número de reglas de red virtual

En un registro con replicación geográfica, se muestra el uso del almacenamiento para la región principal. Multiplique por el número de réplicas para la cantidad total de almacenamiento.

Cambio de la SKU del Registro

Puede cambiar la SKU de un registro en el portal de Azure o mediante CLI de Azure o Azure PowerShell. Puede moverse libremente entre SKU siempre que la SKU a la que cambie tenga la capacidad de almacenamiento máxima necesaria.

Al cambiar la SKU de un registro, no hay ningún tiempo de inactividad ni impacto en las operaciones del Registro. Sin embargo, si pasa de Premium a una SKU inferior, se deshabilitan las características específicas de Premium. En algunos casos, debe quitar recursos relacionados con estas características para poder cambiar las SKU. Por ejemplo, debe eliminar las replicaciones geográficas o los registros conectados para poder cambiar de Premium a Estándar o Básico.

Para cambiar las SKU en el portal de Azure, vaya al registro de contenedor. En el menú del servicio, en Configuración, seleccione Propiedades. Cambie la opción plan de precios y, a continuación, seleccione Guardar.

Para cambiar las SKU mediante el CLI de Azure, use el comando az acr update. Por ejemplo, para cambiar a Premium:

az acr update --name myContainerRegistry --sku Premium

Para cambiar las SKU mediante Azure PowerShell, use el cmdlet Update-AzContainerRegistry. Por ejemplo, para cambiar a Premium:

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

Contenido relacionado

Para obtener información sobre las próximas características de Azure Container Registry, consulte Roadmap en GitHub.