Veelvoorkomende problemen in Azure Container Instances oplossen

  • Artikel

In dit artikel wordt beschreven hoe u veelvoorkomende problemen met het beheren of implementeren van containers in Azure Container Instances kunt oplossen. Zie ook Veelgestelde vragen.

Als u meer ondersteuning nodig hebt, raadpleegt u de beschikbare opties voor Help en ondersteuning in de Azure Portal.

Problemen tijdens de implementatie van containergroepen

Naamconventies

Bij het definiëren van de containerspecificatie moeten bepaalde parameters zich houden aan naamgevingsbeperkingen. Hieronder ziet u een tabel met specifieke vereisten voor eigenschappen van containergroepen. Zie Naamconventies in het Azure Architecture Center en Naamgevingsregels en -beperkingen voor Azure-resources voor meer informatie.

Bereik Lengte Hoofdlettergebruik Geldige tekens Voorgesteld patroon Voorbeeld
Containernaam1 1-63 Kleine letters Alfanumeriek en afbreekstreepje overal behalve het eerste of laatste teken <name>-<role>-container<number> web-batch-container1
Containerpoorten Tussen 1 en 65535 Geheel getal Geheel getal tussen 1 en 65535 <port-number> 443
DNS-naamlabel 5-63 Niet hoofdlettergevoelig Alfanumeriek en afbreekstreepje overal behalve het eerste of laatste teken <name> frontend-site1
Omgevingsvariabele 1-63 Niet hoofdlettergevoelig Alfanumeriek en onderstrepingsteken (_) overal behalve het eerste of laatste teken <name> MY_VARIABLE
Volumenaam 5-63 Kleine letters Alfanumeriek en afbreekstreepjes overal behalve het eerste of laatste teken. Kan geen twee opeenvolgende afbreekstreepjes bevatten. <name> batch-output-volume

1 Beperking ook voor namen van containergroepen wanneer deze niet onafhankelijk van containerinstanties worden opgegeven, bijvoorbeeld met az container create opdrachtimplementaties.

Versie van installatiekopieën van het besturingssysteem wordt niet ondersteund

Als u een afbeelding opgeeft die Azure Container Instances niet ondersteunt, wordt er een OsVersionNotSupported fout geretourneerd. De fout is vergelijkbaar met de volgende, waarbij {0} de naam is van de installatiekopieën die u hebt geprobeerd te implementeren:

{
  "error": {
    "code": "OsVersionNotSupported",
    "message": "The OS version of image '{0}' is not supported."
  }
}

Deze fout treedt meestal op bij het implementeren van Windows-installatiekopieën die zijn gebaseerd op Semi-Annual Channel-release 1709 of 1803, die niet worden ondersteund. Zie Veelgestelde vragen voor ondersteunde Windows-installatiekopieën in Azure Container Instances.

Kan installatiekopie niet ophalen

Als Azure Container Instances uw installatiekopie in eerste instantie niet kan ophalen, probeert de installatiekopie opnieuw. Als de pull-bewerking van de installatiekopie blijft mislukken, mislukt ACI uiteindelijk de implementatie en ziet u mogelijk een Failed to pull image fout.

U kunt dit probleem oplossen door het containerexemplaren te verwijderen en de implementatie opnieuw uit te proberen. Zorg ervoor dat de installatiekopieën in het register aanwezig zijn en dat u de naam van de installatiekopieën correct hebt getypt.

Als de installatiekopie niet kan worden opgehaald, worden gebeurtenissen zoals de volgende weergegeven in de uitvoer van az container show:

"events": [
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "Pulling",
    "type": "Normal"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "Failed to pull image \"mcr.microsoft.com/azuredocs/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
    "name": "Failed",
    "type": "Warning"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:20+00:00",
    "lastTimestamp": "2017-12-21T22:57:16+00:00",
    "message": "Back-off pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

Fout 'Resource niet beschikbaar'

Vanwege de wisselende regionale resourcebelasting in Azure kan het volgende foutbericht worden weergegeven wanneer u probeert een containerinstantie te implementeren:

The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.

Deze fout geeft aan dat vanwege de zware belasting in de regio waarin u wilt implementeren, de resources die zijn opgegeven voor uw container op dat moment niet kunnen worden toegewezen. Gebruik een of meer van de volgende oplossingsstappen om uw probleem op te lossen.

  • Controleer of uw containerimplementatie-instellingen binnen de parameters vallen die zijn gedefinieerd in Beschikbaarheid van regio's voor Azure Container Instances
  • Lagere CPU- en geheugeninstellingen voor de container opgeven
  • Implementeren in een andere Azure-regio
  • Op een later tijdstip implementeren

Problemen tijdens runtime van containergroep

Container is geïsoleerd opnieuw opgestart zonder expliciete gebruikersinvoer

Er zijn twee algemene categorieën voor de reden waarom een containergroep opnieuw kan worden opgestart zonder expliciete gebruikersinvoer. Ten eerste kunnen containers opnieuw worden opgestart als gevolg van een crash van het toepassingsproces. De ACI-service raadt het toepassen van waarneembaarheidsoplossingen aan, zoals Application Insights SDK, metrische gegevens van containergroepen en logboeken van containergroepen , om te bepalen waarom de toepassing problemen heeft ondervonden. Ten tweede kunnen klanten te maken hebben met herstarts die zijn geïnitieerd door de ACI-infrastructuur vanwege onderhoudsbeurtenissen. Als u de beschikbaarheid van uw toepassing wilt verhogen, voert u meerdere containergroepen uit achter een toegangsonderdeel, zoals een Application Gateway of Traffic Manager.

Container wordt voortdurend afgesloten en opnieuw gestart (geen langlopend proces)

Containergroepen zijn standaard ingesteld op het beleid vooropnieuw opstarten van Altijd, zodat containers in de containergroep altijd opnieuw worden opgestart nadat ze zijn voltooid. Mogelijk moet u dit wijzigen in OnFailure of Nooit als u van plan bent om op taken gebaseerde containers uit te voeren. Als u OnFailure opgeeft en nog steeds continu opnieuw wordt opgestart, is er mogelijk een probleem met de toepassing of het script dat in uw container wordt uitgevoerd.

Bij het uitvoeren van containergroepen zonder langlopende processen ziet u mogelijk herhaalde afsluitingen en opnieuw opstarten met installatiekopieën zoals Ubuntu of Alpine. Verbinding maken via EXEC werkt niet, omdat de container geen proces heeft dat deze actief blijft. U kunt dit probleem oplossen door een startopdracht zoals de volgende toe te voegen aan de implementatie van de containergroep om de container actief te houden.

## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"

## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image mcr.microsoft.com/windows/servercore:ltsc2019
 --command-line "ping -t localhost"

De Container Instances-API en Azure Portal bevatten een restartCount eigenschap. Als u het aantal herstarts voor een container wilt controleren, kunt u de opdracht az container show in de Azure CLI gebruiken. In de volgende voorbeelduitvoer (die voor de beknoptheid is afgekapt), ziet u de restartCount eigenschap aan het einde van de uitvoer.

...
 "events": [
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:06+00:00",
     "lastTimestamp": "2017-11-13T21:20:06+00:00",
     "message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   }
 ],
 "previousState": null,
 "restartCount": 0
...
}

Notitie

De meeste containerinstallatiekopieën voor Linux-distributies stellen een shell in, zoals bash, als de standaardopdracht. Omdat een shell op zichzelf geen langlopende service is, worden deze containers onmiddellijk afgesloten en in een herstartlus terechtgekomen wanneer deze zijn geconfigureerd met het standaardbeleid Altijd opnieuw opstarten.

Het starten van de container duurt lang

De drie belangrijkste factoren die bijdragen aan de opstarttijd van de container in Azure Container Instances zijn:

Windows-installatiekopieën hebben aanvullende overwegingen.

Grootte van afbeelding

Als het lang duurt voordat uw container is gestart, maar uiteindelijk lukt, kijkt u eerst naar de grootte van de containerinstallatiekopieën. Omdat Azure Container Instances uw containerinstallatiekopie op aanvraag ophaalt, is de opstarttijd die u ziet, rechtstreeks gerelateerd aan de grootte ervan.

U kunt de grootte van uw containerinstallatiekopieën bekijken met behulp van de docker images opdracht in de Docker CLI:

docker images

REPOSITORY                                    TAG       IMAGE ID        CREATED          SIZE
mcr.microsoft.com/azuredocs/aci-helloworld    latest    7367f3256b41    15 months ago    67.6MB

De sleutel tot het klein houden van afbeeldingsgrootten is ervoor te zorgen dat uw uiteindelijke installatiekopie niets bevat dat niet vereist is tijdens runtime. Een manier om dit te doen, is met builds met meerdere fasen. Builds met meerdere fasen maken het eenvoudig om ervoor te zorgen dat de uiteindelijke installatiekopie alleen de artefacten bevat die u nodig hebt voor uw toepassing en niet de extra inhoud die tijdens het bouwen was vereist.

Locatie van afbeelding

Een andere manier om de impact van de pull van de installatiekopie op de opstarttijd van uw container te verminderen, is door de containerinstallatiekopie te hosten in Azure Container Registry in dezelfde regio waar u containerinstanties wilt implementeren. Dit verkort het netwerkpad dat de containerinstallatiekopieën moeten afleggen, waardoor de downloadtijd aanzienlijk wordt verkort.

Afbeeldingen in cache

Azure Container Instances maakt gebruik van een cachemechanisme om de opstarttijd van containers te versnellen voor installatiekopieën die zijn gebouwd op algemene Windows-basisinstallatiekopieën, waaronder nanoserver:1809, servercore:ltsc2019en servercore:1809. Veelgebruikte Linux-installatiekopieën, zoals ubuntu:1604 en alpine:3.6 , worden ook opgeslagen in de cache. Vermijd het gebruik van de latest tag voor zowel Windows- als Linux-installatiekopieën. Raadpleeg de best practices voor installatiekopieën van Container Registry voor hulp. Gebruik de API Afbeeldingen in cache weergeven voor een actuele lijst met afbeeldingen en tags in de cache.

Notitie

Het gebruik van installatiekopieën op basis van Windows Server 2019 in Azure Container Instances bevindt zich nog in de preview-fase.

Windows-containers vertragen netwerkgereedheid

Bij de eerste aanmaak hebben Windows-containers mogelijk maximaal 30 seconden (of langer, in zeldzame gevallen) geen binnenkomende of uitgaande connectiviteit. Als uw containertoepassing een internetverbinding nodig heeft, voegt u logica voor vertraging en opnieuw proberen toe om 30 seconden internetverbinding tot stand te brengen. Na de eerste installatie moeten containernetwerken op de juiste manier worden hervat.

Kan geen verbinding maken met de onderliggende Docker-API of bevoegde containers uitvoeren

Azure Container Instances biedt geen directe toegang tot de onderliggende infrastructuur die als host fungeert voor containergroepen. Dit omvat toegang tot de containerruntime, indelingstechnologie en het uitvoeren van bevoegde containerbewerkingen. Raadpleeg de REST-referentiedocumentatie om te zien welke bewerkingen worden ondersteund door ACI. Als er iets ontbreekt, dient u een aanvraag in op de ACI-feedbackforums.

Het IP-adres van de containergroep is mogelijk niet toegankelijk vanwege niet-overeenkomende poorten

Azure Container Instances biedt nog geen ondersteuning voor poorttoewijzing, zoals bij normale Docker-configuratie. Als u merkt dat het IP-adres van een containergroep niet toegankelijk is wanneer u denkt dat dit wel het geval is, moet u ervoor zorgen dat u de containerinstallatiekopie hebt geconfigureerd om te luisteren naar dezelfde poorten die u beschikbaar maakt in uw containergroep met de ports eigenschap .

Als u wilt controleren of Azure Container Instances kunt luisteren op de poort die u hebt geconfigureerd in uw containerinstallatiekopieën, test u een implementatie van de aci-helloworld installatiekopieën die de poort beschikbaar maakt. Voer ook de aci-helloworld app uit zodat deze luistert op de poort. aci-helloworld accepteert een optionele omgevingsvariabele PORT om de standaardpoort 80 te overschrijven waarop wordt geluisterd. Als u bijvoorbeeld poort 9000 wilt testen, stelt u de omgevingsvariabele in wanneer u de containergroep maakt:

  1. Stel de containergroep in om poort 9000 beschikbaar te maken en geef het poortnummer door als de waarde van de omgevingsvariabele. Het voorbeeld is opgemaakt voor de Bash-shell. Als u liever een andere shell gebruikt, zoals PowerShell of opdrachtprompt, moet u de variabeletoewijzing dienovereenkomstig aanpassen.

    az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'

  2. Zoek het IP-adres van de containergroep in de opdrachtuitvoer van az container create. Zoek naar de waarde van ip.

  3. Nadat de container is ingericht, bladert u naar het IP-adres en de poort van de containertoepassing in uw browser, bijvoorbeeld: 192.0.2.0:9000.

    Het bericht 'Welkom bij Azure Container Instances!' wordt weergegeven door de web-app.

  4. Wanneer u klaar bent met de container, verwijdert u deze met de az container delete opdracht :

    az container delete --resource-group myResourceGroup --name mycontainer

Problemen tijdens implementaties van vertrouwelijke containergroepen

Beleidsfouten tijdens het gebruik van aangepast CCE-beleid

Aangepast CCE-beleid moet worden gegenereerd met de Azure CLI confcom-extensie. Voordat u het beleid genereert, moet u ervoor zorgen dat alle eigenschappen die zijn opgegeven in uw ARM-sjabloon geldig zijn en overeenkomen met wat u verwacht te worden weergegeven in een beleid voor vertrouwelijke computing. Enkele eigenschappen die moeten worden gevalideerd, zijn de containerinstallatiekopieën, omgevingsvariabelen, volumekoppelingen en containeropdrachten.

Ontbrekende hash in beleid

De Azure CLI-confcom-extensie maakt gebruik van in de cache opgeslagen installatiekopieën op uw lokale computer die mogelijk niet overeenkomen met de installatiekopieën die extern beschikbaar zijn. Dit kan ertoe leiden dat de lagen niet overeenkomen wanneer het beleid wordt gevalideerd. Zorg ervoor dat u oude installatiekopieën verwijdert en de meest recente containerinstallatiekopieën naar uw lokale omgeving haalt. Zodra u zeker weet dat u de nieuwste SHA hebt, moet u het CCE-beleid opnieuw genereren.

Proces/container beëindigd met afsluitcode: 139

Deze afsluitcode treedt op vanwege beperkingen met de ubuntu versie 22.04-basisinstallatiekopie. Het wordt aanbevolen om een andere basisinstallatiekopieën te gebruiken om dit probleem op te lossen.

Volgende stappen

Meer informatie over het ophalen van containerlogboeken en -gebeurtenissen om fouten in uw containers op te sporen.