Probleemoplossing voor omgevingscapaciteitsfouten in Azure Container Apps

Wanneer je een nieuwe Azure Container Apps-omgeving aanmaakt, kan provisioning falen door een capaciteitsfout. De foutmelding bevat een link naar dit artikel. Dit artikel legt uit waarom de fout optreedt, wat je direct kunt proberen en hoe je implementaties kunt plannen om de impact van capaciteitsbeperkingen te verminderen.

Waarom de fout optreedt

De fout geeft aan dat de regio die je hebt gekozen beperkte capaciteit heeft voor de beheerde infrastructuur die nodig is om je omgeving te creëren. De vraag kan zelfs in een regio die Container Apps ondersteunt de beschikbare capaciteit overtreffen.

Herstellen na een mislukte provisioningpoging

1. Bevestig de fout. Bekijk de foutgegevens van de mislukte uitrol. Als het bericht naar dit artikel linkt, volg dan deze stappen. Noteer het doelgebied en de volledige foutmelding. Deze richtlijn geldt voor fouten in omgevingsprovisioning van capaciteit, niet voor applicatie-opstart of mislukkingen bij het pullen van images.

2. Probeer een andere ondersteunde regio. Als je vereisten dit toelaten, creëer dan de omgeving in een andere regio. Controleer of de regio je vereiste Container Apps-functies en workloadprofielen ondersteunt, dat je daar voldoende quota hebt, en dat aan je netwerk-, afhankelijkheids- en data-residencyvereisten kan worden voldaan. Zie ondersteunde regio's. Voor een bestaande werklast, zie Azure Container Apps verplaatsen naar een andere regio.

3. Probeer het later opnieuw als je dezelfde regio moet gebruiken. De beschikbare capaciteit kan in de loop van de tijd veranderen, dus een latere poging kan slagen. Wacht tot de huidige provisioning-poging is afgerond voordat je het opnieuw probeert. Voor geautomatiseerde deployments gebruik je een begrensd herkansingsbeleid met toenemende vertragingen in plaats van doorlopende, snelle herkansingen. Er is geen gegarandeerd herkansingsinterval of tijdstip waarop capaciteit beschikbaar komt.

Plan uitrol voor capaciteitsflexibiliteit

Volg de volgende werkwijzen om jezelf meer uitrolmogelijkheden te geven. Geen van hen garandeert dat een provisioning-verzoek slaagt.

Meerdere regio's gebruiken

Identificeer minstens twee regio's die je workload kunnen hosten. Als je vereisten het toelaten, plan dan voor drie of meer regio's om jezelf meer opties te geven als één regio door beperkingen niet beschikbaar is. Valideer de beschikbaarheid van functies, quotum, latency, dataresidentie en afhankelijke diensten in elke kandidaatregio voordat je moet uitrollen.

Voor regionale redundantie deploy je aparte omgevingen en applicaties in meerdere regio's, configureer verkeersroutering en failover, en plan je datareplicatie voor stateful afhankelijkheden. Alleen een lijst met alternatieve regio's levert geen failover op. Zie Aangepaste multiregio-oplossingen voor meer veerkracht.

Levering eerder dan gepland

Maak je omgevingen aan en valideer je omgevingen vóór een lancering, migratie of ander tijdgevoelig evenement. Geef tijd om het opnieuw te proberen of een alternatieve regio te gebruiken in plaats van het aanmaken van de omgeving pas op het laatste moment als afhankelijkheid te laten fungeren.

Vroeg een omgeving creëren reserveert geen capaciteit voor toekomstige schaalvergroting. Houd rekening met de kosten van de middelen die je inzet en de beleidsregels voor de levenscyclus van de omgeving, vooral als een omgeving inactief blijft. Zie Billing in Azure Container Apps.

Probeer buiten kantooruren te provisioneren

Als je schema het toelaat, probeer dan buiten de normale kantooruren voor de doelregio te provisioneren. Probeer bijvoorbeeld een venster tussen 3:00 uur 's ochtends en 5:00 uur in de lokale tijdzone van de doelregio.

Beschouw dit venster als een optie om te proberen, niet als een gegarandeerde periode met beschikbare capaciteit. Azure bedient de wereldwijde vraag, en capaciteitsbeperkingen kunnen buiten lokale kantooruren blijven bestaan.

Redundantievereisten voor zones evalueren

Zone-redundante omgevingen verspreiden infrastructuur over meerdere beschikbaarheidszones binnen een regio. Deze eis beperkt de flexibiliteit in de plaatsing vergeleken met een omgeving die geen zone-redundantie vereist.

Als je beschikbaarheidseisen dat toelaten, overweeg dan een nieuwe omgeving zonder zone-redundantie te creëren en deze aan te vullen met implementaties in andere regio's. Deze optie biedt mogelijk meer flexibiliteit in provisioning, maar garandeert geen beschikbare capaciteit.

Kies zone-redundantie wanneer je de omgeving creëert. Je kunt het niet in- of uitschakelen in een bestaande omgeving; een andere instelling vereist een nieuwe omgeving en heruitrol van je apps. Zie Een zoneredundante container-app maken.

Wanneer u contact moet opnemen met de ondersteuning

Als provisioning geblokkeerd blijft nadat je de relevante opties hebt geprobeerd, of als je vereisten het gebruik van een andere regio of een andere redundantieconfiguratie verhinderen, maak dan een ondersteuning voor Azure-verzoek aan voor Container Apps.

Voeg de abonnements-ID, resourcegroep, omgevingsnaam of resource ID, doelregio, zone-redundantie-instelling, volledige foutmelding, mislukte pogingstijdstempels in UTC en correlatie- of operatie-ID's op indien beschikbaar. Beschrijf de herpogingen en alternatieve regio's die je hebt geprobeerd te gebruiken, samen met eventuele deploymentdeadlines of regionale vereisten.

Een supportverzoek kan helpen bij het onderzoeken van de storing, maar garandeert geen directe capaciteitstoewijzing. Vraag alleen om een quotaverhoging als de gerapporteerde fout ook een quotalimiet identificeert.

Verwante onderwerpen

• Quota voor Azure Container Apps
• Quotumwijzigingen aanvragen voor Azure Container Apps
• Betrouwbaarheid in Azure Container Apps