Registro Azure Container funzionalità e limiti dello SKU

Registro Azure Container è disponibile in più SKU. Queste SKU, note anche come piani tariffari o livelli di prezzo, supportano prezzi prevedibili e sono allineate ai diversi modelli di capacità e utilizzo del registro dei contenitori privato in Azure.

Quando si crea un registro, si seleziona un piano tariffario che determina le funzionalità e i limiti del Registro di sistema. Scegliere il piano in linea con i modelli di utilizzo previsti, ad esempio il numero di immagini, le esigenze di archiviazione e i requisiti di prestazioni.

Registro Azure Container offre tre opzioni di Pricing Plan: Basic, Standard e Premium. Ogni SKU offre un set diverso di funzionalità e limiti per soddisfare diversi scenari, dallo sviluppo e dai test ai carichi di lavoro di produzione.

SKU Descrizione
Basic Un punto di ingresso ottimizzato dal punto di vista dei costi per gli sviluppatori che apprendono di Registro Azure Container. I registri di base hanno la maggior parte delle stesse funzionalità dei registri Standard e Premium, come l'integrazione con l'autenticazione di Microsoft Entra , l'eliminazione delle immagini e i webhook . Tuttavia, la velocità effettiva di archiviazione e immagine inclusa è più appropriata per scenari di utilizzo inferiori e alcune funzionalità non sono disponibili.
Standard I registri standard offrono le stesse funzionalità del livello base, con risorse di archiviazione incluse e velocità effettiva di immagine maggiori. I registri standard soddisfano le esigenze di molti scenari di produzione.
Premium I registri Premium offrono il massimo livello di risorse di archiviazione incluse e operazioni simultanee, consentendo scenari con volumi elevati. Oltre a una maggiore velocità effettiva delle immagini, Premium aggiunge funzionalità come la replica geografica per l'elevata disponibilità gestendo un singolo registro in più aree, un collegamento privato con endpoint privati per limitare l'accesso al registro e una maggiore concorrenza delle API e velocità effettiva della larghezza di banda per distribuzioni simultanee su larga scala.

Ogni SKU include una quantità specifica di spazio di archiviazione gratuito, con spazio di archiviazione aggiuntivo disponibile a una tariffa per GB. Ogni SKU ha anche un limite di archiviazione massimo diverso.

Gli SKU Basic, Standard e Premium offrono tutte le stesse funzionalità a livello di codice e le stesse API del piano dati. Traggono vantaggio anche dall'archiviazione immagini gestita interamente da Azure e tutti gli SKU hanno ridondanza della zona abilitata per impostazione predefinita nelle aree supportate. Tuttavia, lo SKU Premium consente una gamma più ampia di funzionalità e presenta limiti più elevati.

Funzionalità e limiti dello SKU

La tabella seguente illustra in dettaglio le funzionalità e i limiti del Registro di sistema degli SKU Basic, Standard e Premium.

Risorsa Base Standard Premium
Spazio di archiviazione incluso1 (GiB) 10 100 500
Limite di archiviazione (TiB) 40 40 100
Dimensioni massime livello immagini (GiB) 195 195 195
Dimensioni massime del manifesto (MiB) 4 4 4
Webhook 2 10 500
Collegamento privato con endpoint privati N/D N/D Supported
• Endpoint privati N/D N/D 200
Regole di rete IP pubblico N/D N/D 200
Accesso alla rete virtuale dell'endpoint servizio N/D N/D Preview
• Regole di rete virtuale N/D N/D 100
Autorizzazioni in ambito repository con assegnazioni di ruolo di Microsoft Entra Supported Supported Supported
Autorizzazioni in ambito repository con token non Microsoft Entra e mappe di ambito Supported Supported Supported
• Token non Microsoft Entra 100 500 50,000
• Mappe di ambito del token non Microsoft Entra 100 500 50,000
• Azioni per la mappatura dell'ambito del token non-Microsoft Entra 500 500 500
• Repository per mappa di ambito del token non Microsoft Entra2 500 500 500
Accesso pull anonimo N/D Supported Supported
Replica geografica N/D N/D Supported
Endpoint dati dedicati N/D N/D Supported
Zone di disponibilità Supported Supported Supported
Attendibilità del contenuto N/D N/D Supported
Chiavi gestite dal cliente N/D N/D Supported
Registri connessi N/D N/D Supported
Streaming degli artefatti N/D N/D Supported
Regole della cache degli artefatti N/D Supported Supported
Configurazione della regola di accesso IP N/D N/D Supported
Criteri di conservazione per manifesti senza tag N/D N/D Supported
Trasferimento artefatto N/D N/D Supported
Criteri di esportazione N/D N/D Supported
Pool di agenti dedicati per Compiti N/D N/D Supported

1 Spazio di archiviazione incluso nella tariffa giornaliera per ogni livello. È possibile usare uno spazio di archiviazione aggiuntivo, fino al limite di archiviazione del registro, a una velocità giornaliera aggiuntiva per GiB. Per informazioni sulla tariffa, vedere Registro Azure Container pricing. Se è necessaria una risorsa di archiviazione oltre il limite di archiviazione del Registro di sistema, contattare Azure supporto tecnico.

2 Singole azioni di content/delete, content/read, content/write, metadata/read, metadata/write corrispondono al limite di repository per mappa dell'ambito del token non Microsoft Entra.

ACR prevede anche i seguenti limiti di prestazioni per il pull e il push delle immagini.

Limiti di frequenza delle richieste API

Oltre ai limiti di archiviazione e funzionalità nella tabella precedente, Registro Azure Container applica i limiti di frequenza delle richieste per le API del Registro di sistema. I limiti di frequenza vengono misurati nelle richieste al minuto (r/m) e sono determinati dallo SKU del Registro di sistema. Quando la frequenza delle richieste supera un limite, il Registro di sistema restituisce un errore HTTP 429 Too Many Requests . La risposta include un'intestazione Retry-After che indica il tempo di attesa prima di riprovare.

Le richieste sono soggette a limitazione nelle seguenti categorie operative. Ogni categoria è definita dai metodi HTTP usati dalle API del piano dati del Registro di sistema:

Categoria operazione Metodi HTTP Examples
DataplaneRead GET, HEAD, OPTIONS Recupero (pull) dei manifest e dei layer dell'immagine. Recupero della posizione BLOB del layer. Elenco dei manifest, repository e tag. Verifica dell'esistenza di un digest o di un tag. Altre operazioni di lettura.
DataplaneWrite PUT, PATCH, POST Invio dei manifest e dei layer dell’immagine. Invio dei tag. Altre operazioni di scrittura.
DataplaneDelete ELIMINA Eliminazione di immagini, manifesti e tag.
OAuth Autenticazione (AuthN) e autorizzazione (AuthZ) Le richieste di autenticazione che i client effettuano durante l'accesso a un server di accesso del Registro di sistema, ad esempio lo scambio da un token di accesso Microsoft Entra ID, un token di amministratore del Registro di sistema o un token con ambito non Microsoft Entra mappato, a un token di aggiornamento del Registro di sistema. Richieste di autorizzazione effettuate dai client prima delle operazioni push, pull e di altre operazioni del piano dati del registro, ad esempio per lo scambio di un token di aggiornamento del registro con un token di accesso con ambito del registro.
ListReferrers GET Elenco degli artefatti referenziati da un manifest, come firme e SBOM.

Per ogni SKU vengono applicati i limiti di frequenza delle richieste seguenti:

Operazione Scope Basic e Standard Premium
DataplaneRead Per registro 10.000 r/m 20.000 r/m
DataplaneRead Per identità per il registro 5.000 r/m 10.000 r/m
DataplaneWrite Per registro 2.000 r/m 4.000 r/m
DataplaneWrite Per identità per il registro 1.000 r/m 2.000 r/m
DataplaneDelete Per registro 1.000 r/m 4.000 r/m
DataplaneDelete Per identità per il registro 500 giri/min 2.000 r/m
ListReferrers Per registro 500 giri/min 2.000 r/m
ListReferrers Per identità per il registro 250 r/m 1.000 r/m
OAuth Per registro 10.000 r/m 20.000 r/m

Note

I limiti di velocità elencati nella tabella precedente sono massimi approssimativi basati sul criterio del best effort e non sono coperti da un SLA. La velocità effettiva effettiva può variare tra registri e nel tempo a seconda delle condizioni dell'infrastruttura, dei modelli di traffico e di altri fattori. Questi numeri rappresentano le percentuali massime massime approssimative che è possibile prevedere in condizioni operative tipiche, ma Registro Azure Container non garantisce queste tariffe esatte in qualsiasi momento.

Limiti per ogni registro e per ogni identità

  • I limiti per registro si applicano alla frequenza di richiesta combinata da tutti i client e le identità a un singolo registro.
  • I limiti per identità per registro si applicano alla frequenza delle richieste da una singola identità a un singolo registro. I limiti per identità impediscono a un singolo client, ad esempio uno scanner di vulnerabilità o una distribuzione non configurata correttamente, di utilizzare l'intera capacità di richiesta di un Registro di sistema. I limiti per identità e per registro sono monitorati separatamente per ciascun registro, quindi un'identità che si autentica in più registri non è soggetta a limitazione della velocità congiuntamente tra tali registri.
  • Per un registro con accesso pull anonimo non autenticato abilitato, tutte le richieste anonime (non autenticate) vengono limitate insieme come singola identità per tale singolo registro.
  • Per un registro con l'account utente amministratore abilitato, tutte le richieste che eseguono l'autenticazione con le credenziali di amministratore vengono limitate insieme come singola identità per tale singolo registro. L'account amministratore ha due password (password e password2), ma entrambe le password condividono la stessa identità a scopo di limitazione. Se più client o flussi di lavoro di automazione eseguono l'autenticazione con le credenziali di amministratore, usano tutti lo stesso bucket di limiti di frequenza per identità.
  • Le richieste di autenticazione e autorizzazione OAuth vengono limitate solo per registro, senza limiti separati per identità e per registro.

Richieste conteggiate ai fini di più limiti

Alcune richieste vengono conteggiate su più di una categoria di operazioni e una richiesta viene limitata se viene superato un limite applicabile. Ad esempio, una richiesta per ottenere l'elenco dei referrer di un manifest è sia una richiesta ListReferrers sia una richiesta DataplaneRead e consuma capacità da entrambi i limiti. Se il registro ha già esaurito il limite DataplaneRead, anche le richieste di referrer vengono limitate, anche se il limite listReferrers non è stato raggiunto. Analogamente, un numero elevato di richieste dei referrer riduce la capacità di DataplaneRead disponibile per altre operazioni di lettura, ad esempio il prelievo di immagini.

Modalità di applicazione dei limiti di frequenza

I limiti di frequenza vengono applicati usando un algoritmo del bucket di token. Ogni categoria di operazioni ha un bucket di capacità di richiesta che viene ricaricata continuamente alla velocità illustrata nella tabella precedente. Questo approccio è progettato per tollerare carichi di lavoro con picchi improvvisi:

  • Sono consentiti picchi brevi al di sopra del tasso costante. Un picco di richieste, ad esempio una distribuzione su larga scala che scarica immagini da molti nodi contemporaneamente, va a buon fine finché nel bucket è disponibile capacità.
  • Il traffico sostenuto deve rimanere al limite o al di sotto. Se un picco svuota il bucket, le richieste successive vengono rifiutate con 429 Too Many Requests finché la capacità non si ripristina, il che può comportare la limitazione della frequenza delle richieste fino a un minuto intero dopo un picco elevato.

Il valore Retry-After in una risposta 429 indica il numero di secondi rimanenti fino al termine del periodo di limitazione in corso, quindi il valore diminuisce da una richiesta limitata consecutiva alla successiva anziché rimanere fisso. Ad esempio, la prima risposta soggetta a limitazione potrebbe restituire Retry-After: 60. Se si riprova 10 secondi dopo e la richiesta è ancora soggetta a limitazione, la risposta restituita sarà Retry-After: 50. Poiché il valore viene calcolato in modo dinamico per ogni richiesta, non accettare una dipendenza da un valore fisso Retry-After .

Quando si riceve una risposta 429, rispettare l'intestazione Retry-After e implementare una logica di ritentativo con backoff esponenziale. Per altre indicazioni sulla mitigazione, vedere Limitazioni e vincoli di larghezza di banda.

Occasionalmente, durante un picco improvviso e marcato a partire da un livello di partenza basso (ad esempio un improvviso afflusso massiccio di richieste), potresti osservare temporaneamente una capacità effettiva di elaborazione inferiore ai limiti pubblicati, mentre l'infrastruttura del registro si espande per soddisfare la domanda.

Note

Alcuni limiti in questa tabella possono essere aumentati contattando Azure supporto tecnico. Le richieste di aumento sono supportate per:

  • Limiti di archiviazione del Registro di sistema
  • Numero massimo di endpoint privati (connessioni collegamento privato) per ogni registro
  • Limiti delle prestazioni di push e pull delle immagini, inclusi la limitazione della velocità, la larghezza di banda e i limiti della frequenza delle richieste dell'API del piano dati

I limiti seguenti sono fissi e non possono essere aumentati tramite una richiesta di supporto:

  • Regole di rete IP pubbliche massime
  • Numero massimo di regole di rete virtuale dell'endpoint di servizio
  • Numero massimo di token non di Microsoft Entra
  • Numero massimo di mapping dell'ambito di token non Microsoft Entra
  • Azioni massime per mappa di ambito del token non appartenenti a Microsoft Entra
  • Repository massimi per mappa di ambito del token non appartenenti a Microsoft Entra

Per informazioni sui prezzi per ognuno degli SKU Registro Azure Container, vedere Container Registry pricing. Per informazioni dettagliate sui prezzi per i trasferimenti di dati, vedere Prezzi della larghezza di banda.

Limiti delle prestazioni di pull e push delle immagini del registro

Le prestazioni di pull e push delle immagini sono influenzate principalmente dalla concorrenza dell'API, dalla velocità effettiva della larghezza di banda e dalla limitazione durante operazioni con volumi elevati. Lo SKU del Registro di sistema, la configurazione di rete e la configurazione client determinano questi fattori.

Limiti di concorrenza dell'API e larghezza di banda effettiva

Lo SKU determina la concorrenza API e la velocità effettiva della larghezza di banda. Gli SKU più elevati supportano operazioni simultanee e una maggiore larghezza di banda per operazioni del piano dati, ad esempio l'elenco, l'eliminazione, il push e il pull delle immagini.

I fattori seguenti influiscono sulla concorrenza API e sulla velocità effettiva della larghezza di banda durante il pull e il push delle immagini:

  • Numero e dimensioni dei livelli immagine
  • Riutilizzo dei layer tra immagini nel registro
  • Chiamate API aggiuntive necessarie per ogni operazione
  • Scalabilità delle distribuzioni simultanee, ad esempio distribuzioni Kubernetes che eseguono il pull simultaneo di immagini tra più nodi

I fattori di ambiente client seguenti influiscono sulle prestazioni:

  • Configurazione del daemon Docker o podman per operazioni simultanee
  • Configurazione del runtime del contenitore, ad esempio containerd o impostazioni di concorrenza di CRI-O
  • Impostazioni del piano dati del cluster o della configurazione del cluster

I fattori di rete seguenti influiscono sulle prestazioni:

  • Larghezza di banda e latenza di rete per gli hop di rete dai client al Registro di sistema
  • Configurazione di rete lato client, ad esempio regole del firewall e impostazioni proxy
  • Distanza geografica dal registro o dalla replica più vicina se replicato geograficamente

Per altre informazioni sulle operazioni API eseguite durante il push e il pull delle immagini, vedere la documentazione dell'API HTTP Docker V2 . Per informazioni sulla risoluzione dei problemi, vedere Risolvere i problemi relativi alle prestazioni del Registro di sistema.

Limitazione della velocità e vincoli di larghezza di banda

Durante i periodi di volume elevato delle richieste, è possibile che si verifichi un throttling con un errore HTTP 429 Too many requests o una ridotta velocità di trasmissione della larghezza di banda. Per attenuare questi problemi:

  • Implementare la logica di ripetizione dei tentativi con backoff esponenziale e jitter.
  • Ridurre la frequenza delle richieste simultanee.
  • Differire le distribuzioni su larga scala per ridurre il prelievo simultaneo delle immagini tra più nodi.
  • Se si verifica una limitazione della velocità dopo un improvviso aumento del traffico rispetto a livelli in precedenza bassi, potresti riscontrare temporaneamente una capacità effettiva inferiore mentre l'infrastruttura del registro viene ampliata per soddisfare la domanda.

Note

Se si riscontrano limitazioni persistenti dell'API o un basso throughput della larghezza di banda, è consigliabile aggiornare lo SKU del registro a un valore superiore. È anche possibile contattare il supporto di Azure per richiedere un aumento del limite.

Mostra l'utilizzo del registro

Le informazioni sull'utilizzo consentono di prendere decisioni sulla modifica dello SKU quando il Registro di sistema si avvicina a un limite e consente di gestire l'utilizzo.

Per ottenere uno snapshot del consumo corrente di archiviazione e altre risorse del Registro di sistema, rispetto ai limiti per lo SKU del Registro di sistema, controllare la pagina Overview del Registro di sistema nel portale di Azure. È anche possibile usare API come az acr show-usage (interfaccia della riga di comando di Azure), Get-AzContainerRegistryUsage (Azure PowerShell) o Registries - List Usages (API REST).

Note

L'utilizzo dell'archiviazione del registro potrebbe non riflettere tutte le operazioni recenti del registro. Monitorare la metrica del registro di sistema StorageUsed per ottenere dati aggiornati.

A seconda dello SKU del registro, le informazioni sull'utilizzo includono alcune o tutte le seguenti voci, insieme al limite previsto per quello SKU:

In un registro con replica geografica, l'utilizzo dell'archiviazione viene visualizzato per l'area principale. Moltiplicare per il numero di repliche per la quantità totale di spazio di archiviazione.

Modificare lo SKU del Registro di sistema

È possibile modificare lo SKU di un Registro di sistema nel portale di Azure oppure usando interfaccia della riga di comando di Azure o Azure PowerShell. È possibile spostarsi liberamente tra SKU purché lo SKU a cui si sta passando abbia la capacità di archiviazione massima necessaria.

Quando si modifica lo SKU di un Registro di sistema, non si verifica alcun tempo di inattività o impatto sulle operazioni del Registro di sistema. Tuttavia, se si passa da Premium a uno SKU inferiore, le funzionalità specifiche di Premium sono disabilitate. In alcuni casi, è necessario rimuovere le risorse correlate a queste funzionalità prima di poter cambiare SKU. Ad esempio, è necessario eliminare tutte le repliche geografiche o i registri connessi prima di passare da Premium a Standard o Basic.

Per modificare gli SKU nel portale di Azure, passare al registro container. Nel menu del servizio, in Impostazioni, selezionare Proprietà. Modificare l'opzione piano tariffario e quindi selezionare Salva.

Per modificare gli SKU usando il interfaccia della riga di comando di Azure, usare il comando az acr update. Ad esempio, per passare al registro Premium:

az acr update --name myContainerRegistry --sku Premium

Per modificare gli SKU usando Azure PowerShell, usare il cmdlet Update-AzContainerRegistry. Ad esempio, per passare al registro Premium:

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

Contenuti correlati

Per informazioni sulle funzionalità di Registro Azure Container in arrivo, vedere la Roadmap su GitHub.

  • Last updated on