Recursos e limites da SKU do Azure Container Registry

Azure Container Registry está disponível em vários SKUs. Estes SKUs, também conhecidos como planos de preços ou níveis, suportam preços previsíveis e alinham-se com diferentes capacidades e padrões de utilização do seu registo privado de contentores no Azure.

Quando cria um registo, seleciona um Plano de Preços que determina as características e limites do seu registo. Escolha o plano que se alinhe com os seus padrões de utilização esperados, como o número de imagens, necessidades de armazenamento e requisitos de desempenho.

Azure Container Registry oferece três opções Plano de Preços: Básica, Padrão e Premium. Cada SKU oferece um conjunto diferente de funcionalidades e limites para acomodar vários cenários, desde desenvolvimento e testes até cargas de trabalho em produção.

SKU Descrição
Basic Um ponto de entrada otimizado em termos de custos para programadores que estão a aprender sobre o Azure Container Registry. Os registos básicos têm a maioria das mesmas capacidades que os registos Standard e Premium, como a integração com a autenticação Microsoft Entra, a eliminação de imagens e webhooks. No entanto, o armazenamento incluído e o rendimento de imagem são mais adequados para cenários de menor uso, e algumas funcionalidades não estão disponíveis.
Standard Os registros padrão oferecem os mesmos recursos do Basic, com maior armazenamento incluído e taxa de transferência de imagem. Os registos padrão satisfazem as necessidades de muitos cenários de produção.
Prémio Os registros Premium fornecem a maior quantidade de armazenamento incluído e operações simultâneas, permitindo cenários de alto volume. Para além de um maior débito de imagem, o Premium adiciona funcionalidades como geo-replicação para alta disponibilidade através da gestão de um único registo em múltiplas regiões, ligação privada com endpoints privados para restringir o acesso ao registo, e maior concorrência da API e débito de largura de banda para implementações concorrentes em larga escala.

Cada SKU inclui uma quantidade específica de armazenamento livre, com armazenamento adicional disponível a uma tarifa por GB. Cada SKU também tem um limite máximo de armazenamento diferente.

Os SKUs Basic, Standard e Premium fornecem todas as mesmas capacidades programáticas e APIs de planos de dados. Todos beneficiam também do armazenamento de imagens gerido inteiramente pelo Azure, e todos os SKUs têm redundância de zonas ativada por defeito nas regiões suportadas. No entanto, o SKU Premium permite uma gama mais ampla de funcionalidades e tem limites mais elevados.

Funcionalidades e limites do SKU

A tabela seguinte detalha as características e os limites do registo dos SKUs Basic, Standard e Premium.

Recurso Básico Standard Premium
Armazenamento incluído1 (GiB) 10 100 500
Limite de armazenamento (TiB) 40 40 100
Tamanho máximo da camada de imagem (GiB) 195 195 195
Tamanho máximo do manifesto (MiB) 4 4 4
Webhooks 2 10 500
Ligação privada com pontos de extremidade privados N/A N/A Supported
• Pontos finais privados N/A N/A 200
Regras de rede IP pública N/A N/A 200
Acesso ao endpoint de serviço na rede virtual (VNet) N/A N/A Prévia
• Regras de rede virtual N/A N/A 100
Permissões de âmbito de repositório com atribuições de funções do Microsoft Entra Supported Supported Supported
Permissões com escopo de repositório usando tokens genéricos e mapas de escopo que não são do Microsoft Entra Supported Supported Supported
• Tokens não-Microsoft Entra 100 500 50,000
• Mapas de escopo de tokens não-Microsoft Entra 100 500 50,000
• Ações por mapa de escopo de tokens não-Microsoft Entra 500 500 500
• Repositórios por mapa de escopo de token do Entra não-Microsoft2 500 500 500
Acesso pull anónimo N/A Supported Supported
Geo-replicação N/A N/A Supported
Endpoints de dados dedicados N/A N/A Supported
Zonas de disponibilidade Supported Supported Supported
Confiança de conteúdo N/A N/A Supported
Chaves gerenciadas pelo cliente N/A N/A Supported
Registos ligados N/A N/A Supported
Streaming de artefactos N/A N/A Supported
Regras de cache de artefactos N/A Supported Supported
Configuração da regra de acesso IP N/A N/A Supported
Política de retenção para manifestos não etiquetados N/A N/A Supported
Transferência de artefactos N/A N/A Supported
Política de exportação N/A N/A Supported
Pools dedicados de agentes para tarefas N/A N/A Supported

1 Armazenamento incluído na tarifa diária para cada nível. Pode ser utilizado armazenamento adicional, até ao limite de armazenamento do registo, a uma taxa diária adicional por GiB. Para informações sobre tarifas, consulte preços do Azure Container Registry. Se precisar de armazenamento para além do limite do registo, por favor contacte o Suporte do Azure.

2 Ações individuais decontent/delete, content/read, content/write, metadata/read, metadata/write correspondem ao limite de repositórios por mapa de escopo de token Entra não-Microsoft.

O ACR dispõe também dos seguintes limites de desempenho de extração e envio de imagens.

Limites de taxa de pedidos de API

Para além dos limites de armazenamento e funcionalidades na tabela anterior, o Azure Container Registry aplica limites de taxa de pedidos nas APIs do registo. Os limites de taxa são medidos em pedidos por minuto (r/m) e são determinados pelo SKU do seu registo. Quando a sua taxa de pedidos ultrapassa um limite, o registo devolve um erro HTTP 429 Too Many Requests . A resposta inclui um Retry-After cabeçalho que indica quanto tempo esperar antes de tentar novamente.

Os pedidos são limitados nas seguintes categorias de operação. Cada categoria é definida pelos métodos HTTP usados pelas APIs do plano de dados do registo:

Categoria de operação Métodos HTTP Exemplos
DataplaneRead OBTÉM, CABEÇA, OPÇÕES Obter (puxar) manifestos e camadas de imagem. A obter a localização do blob da camada. Listar manifestos, repositórios e etiquetas. Verificar a existência do digest ou da tag. Outras operações de leitura.
DataplaneWrite COLOCAR, ATUALIZAR, PUBLICAR Empurrar manifestos e camadas de imagem. A enviar tags. Outras operações de escrita.
DataplaneDelete DELETE Apagar imagens, manifestos e etiquetas.
OAuth Autenticação (AuthN) e autorização (AuthZ) Pedidos de autenticação efetuados pelos clientes ao iniciar sessão num servidor de início de sessão do registo, como, por exemplo, a troca de um token de acesso do Microsoft Entra ID, de um token de administrador do registo ou de um token mapeado a âmbito que não seja do Microsoft Entra, por um token de atualização do registo. Pedidos de autorização que os clientes efetuam antes de operações push, pull e de outras operações do plano de dados do registo, como a troca de um token de atualização do registo por um token de acesso ao registo com âmbito definido.
ListReferrers GET Listar os artefactos de referência de um manifesto, como assinaturas e SBOMs.

Os seguintes limites de taxa de pedido são aplicados para cada SKU:

Operação Scope Básico e Standard Premium
DataplaneRead Por registo 10.000 r/m 20.000 r/m
DataplaneRead Por cada identidade, por cada registo 5.000 r/m 10.000 r/m
DataplaneWrite Por registo 2.000 r/m 4.000 r/m
DataplaneWrite Por cada identidade, por cada registo 1.000 r/m 2.000 r/m
DataplaneDelete Por registo 1.000 r/m 4.000 r/m
DataplaneDelete Por cada identidade, por cada registo 500 r/m 2.000 r/m
ListReferrers Por registo 500 r/m 2.000 r/m
ListReferrers Por cada identidade, por cada registo 250 r/m 1.000 r/m
OAuth Por registo 10.000 r/m 20.000 r/m

Nota

Os limites de taxa listados na tabela anterior são máximos aproximados de melhor esforço e não são suportados por um SLA. A taxa de transferência real pode variar entre diferentes registos e ao longo do tempo, dependendo das condições da infraestrutura, dos padrões de tráfego e de outros fatores. Estes números representam as taxas máximas aproximadas de pedidos que pode esperar em condições operacionais típicas, mas o Azure Container Registry não garante estas taxas exatas em todos os momentos.

Limites por registo e por identidade

  • Os limites por registo aplicam-se à taxa combinada de pedidos provenientes de todos os clientes e identidades para um único registo.
  • Por identidade por registo aplicam-se limites à taxa de pedidos de uma única identidade para um único registo. Os limites por identidade impedem que um único cliente, como um scanner de vulnerabilidades ou uma implantação mal configurada, consuma toda a capacidade de pedidos de um registo. Os limites por identidade e por registo são monitorizados separadamente para cada registo, pelo que uma identidade que se autentica em múltiplos registos não é sujeita a limitação de forma conjunta entre esses registos.
  • Para um registo que tem acesso anónimo não autenticado ativado, todos os pedidos anónimos (não autenticados) são limitados como uma única identidade para esse único registo.
  • Para um registo que tem a conta de utilizador de administrador ativada, todos os pedidos que se autenticam com credenciais de administrador são limitados como uma única identidade para esse único registo. A conta de administrador tem duas palavras-passe (password e password2), mas ambas partilham a mesma identidade para fins de limitação. Se múltiplos clientes ou fluxos de trabalho de automação se autenticam com credenciais de administrador, todos consomem o mesmo limite de taxa por identidade.
  • Os pedidos de autenticação e autorização OAuth estão sujeitos a limitação apenas por registo, sem limites separados por identidade para cada registo.

Solicitações que contam para múltiplos limites

Alguns pedidos contam para mais do que uma categoria de operações, e um pedido é limitado se algum limite aplicável for ultrapassado. Por exemplo, uma solicitação para listar os referenciadores de um manifest é simultaneamente uma solicitação ListReferrers e uma solicitação DataplaneRead, e consome capacidade de ambos os limites de capacidade. Se o seu registo já esgotou o limite de DataplaneRead, os pedidos dos referers também são limitados, mesmo que o limite dos ListReferrers não tenha sido atingido. Da mesma forma, uma elevada taxa de pedidos de referenciadores reduz a capacidade do DataplaneRead disponível para outras operações de leitura, como transferências de imagens.

Como são aplicados os limites de taxa

Os limites de taxa são aplicados através de um algoritmo de balde de tokens. Cada categoria de operação tem uma reserva de capacidade de pedidos que é reabastecida continuamente ao ritmo indicado na tabela anterior. Esta abordagem foi concebida para suportar cargas de trabalho com picos súbitos:

  • São permitidos períodos curtos acima da taxa estável. Um pico de pedidos, como uma implantação em grande escala que transfere imagens em vários nós ao mesmo tempo, é bem-sucedido desde que haja capacidade disponível no balde.
  • O trânsito sustentado deve manter-se dentro ou abaixo do limite. Se uma rajada esvaziar o bucket, os pedidos subsequentes são rejeitados com 429 Too Many Requests até que a capacidade seja reposta, o que pode fazer com que os pedidos sejam limitados durante até um minuto completo após uma grande rajada.

O valor de Retry-After numa resposta 429 indica o número de segundos restantes até ao fim do atual período de limitação, pelo que vai diminuindo ao longo de pedidos limitados consecutivos, em vez de permanecer fixo. Por exemplo, a primeira resposta limitada pode devolver Retry-After: 60. Se tentar novamente passados 10 segundos e o pedido continuar a ser limitado, a resposta devolve Retry-After: 50. Como o valor é calculado dinamicamente para cada pedido, não assuma uma dependência de um valor fixo Retry-After .

Quando receber uma resposta 429, respeite o cabeçalho Retry-After e implemente lógica de repetição com recuo exponencial. Para mais orientações sobre mitigação, veja Limitação e restrições de largura de banda.

Por vezes, durante um aumento súbito e acentuado a partir de um nível de referência baixo (como um afluxo maciço de pedidos), poderá observar temporariamente uma taxa de transferência inferior aos limites publicados, enquanto a infraestrutura do registo se expande para dar resposta à procura.

Nota

Pode aumentar alguns limites listados nesta tabela contactando Azure Suporte. Pode solicitar, por exemplo, um aumento dos limites de endpoints privados, do desempenho de envio e transmissão de imagem devido a restrições de rendimento ou largura de banda, ou limites gerais de armazenamento.

Para informações sobre preços de cada uma das Azure Container Registry SKUs, consulte Container Registry pricing. Para detalhes sobre preços para transferências de dados, consulte Preços de largura de banda.

Limites de desempenho para pull e push de imagens no registo

A concorrência da API, o débito de largura de banda e o controle de fluxo durante operações de alto volume afetam principalmente o desempenho das operações de pull e push de imagens. O SKU do seu registo, a configuração da rede e a configuração do cliente determinam estes fatores.

Limites de concorrência da API e limites de largura de banda

O seu SKU determina o paralelismo da API e o débito de largura de banda de processamento. SKUs superiores suportam mais operações simultâneas e maior largura de banda para operações no plano de dados, como listar, eliminar, enviar e puxar imagens.

Os fatores seguintes afetam a concorrência da API e a largura de banda durante o pull e push de imagens:

  • Número e tamanho das camadas de imagem
  • Reutilização de camadas entre imagens no registo
  • Chamadas adicionais de API necessárias para cada operação
  • Escala das implementações concorrentes, como implementações do Kubernetes que obtêm imagens através de múltiplos nós simultaneamente

Os seguintes fatores do ambiente do cliente afetam o desempenho:

  • Docker daemon ou configuração Podman para operações concorrentes
  • Configuração de execução de contentores, como definições de concorrência do CRI-O, ou containerd
  • Configuração do cluster ou configurações do plano de dados do cluster

Os seguintes fatores de rede afetam o desempenho:

  • A largura de banda e a latência da rede nos saltos da rede dos clientes para o registo
  • Configuração da rede do lado do cliente, como regras de firewall e definições de proxy
  • Distância geográfica ao registo ou à réplica mais próxima, se geo-replicada

Para mais informações sobre operações de API que ocorrem durante o push e pull de imagens, consulte a documentação Docker HTTP API V2 . Para ajuda na resolução de problemas, consulte Solucionar problemas de desempenho do registo.

Regulamentação e restrições de largura de banda

Durante períodos de elevado volume de pedidos, pode encontrar uma limitação de taxa com erro HTTP 429 Too many requests ou largura de banda reduzida. Para mitigar estes problemas:

  • Implemente lógica de novas tentativas com recuo exponencial e variação aleatória.
  • Reduzir a taxa de pedidos simultâneos.
  • Espaçar as implementações em grande escala para reduzir transferências simultâneas de imagens em vários nós.
  • Se estiver a experienciar limitação após um aumento súbito do tráfego devido a uma linha base anteriormente baixa, pode temporariamente ver uma redução do débito enquanto a infraestrutura do registo se expande para satisfazer a procura.

Nota

Se experienciar uma restrição persistente da API ou uma largura de banda lenta, considere atualizar o SKU do seu registo para um superior. Também pode contactar suporte do Azure para solicitar um aumento do limite.

Mostrar uso do registro

A informação de utilização ajuda-o a tomar decisões sobre a alteração do SKU quando a sua lista de registos se aproxima do limite e ajuda a gerir o consumo.

Para obter uma visão geral do consumo atual de armazenamento e outros recursos do seu registo, comparado com os limites do SKU desse registo, consulte a página Visão Geral do seu registo no portal Azure. Também pode usar APIs como az acr show-usage (CLI do Azure), Get-AzContainerRegistryUsage (Azure PowerShell), ou Registries - List Usages (REST API).

Nota

A utilização de armazenamento do registo pode não refletir todas as operações recentes do registo. Monitorizar a métrica do registo StorageUsed para dados atualizados.

Dependendo do SKU do seu registo, a informação de utilização inclui alguns ou todos os seguintes elementos, juntamente com o limite nesse SKU:

Num registo geo-replicado, o uso de armazenamento é mostrado para a região de origem. Multiplica pelo número de réplicas para obter o total de armazenamento.

Alterar SKU de registo

Pode alterar o SKU de um registo no portal Azure ou usando CLI do Azure ou Azure PowerShell. Podes mover-te livremente entre SKUs desde que o SKU para o qual estás a mudar tenha a capacidade máxima de armazenamento necessária.

Quando alteras o SKU de um registo, não há tempo de inatividade nem impacto nas operações do registo. No entanto, se passar do Premium para um SKU mais baixo, as funcionalidades específicas do Premium ficam desativadas. Em alguns casos, é necessário remover recursos relacionados com estas funcionalidades antes de poder mudar de SKUS. Por exemplo, deve eliminar quaisquer geo-replicações ou registos ligados antes de poder mudar de Premium para Standard ou Basic.

Para alterar SKUs no portal do Azure, vá ao seu registo de contentores. No menu de serviço, em Definições, selecione Propriedades. Muda a opção do plano de preços e depois seleciona Guardar.

Para alterar SKUs usando o CLI do Azure, use o comando az acr update. Por exemplo, para mudar para Premium:

az acr update --name myContainerRegistry --sku Premium

Para alterar SKUs usando Azure PowerShell, use o cmdlet Update-AzContainerRegistry. Por exemplo, para mudar para Premium:

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

Conteúdo relacionado

Para informações sobre as próximas funcionalidades Azure Container Registry, consulte o Roadmap no GitHub.

  • Last updated on