Konfigurera liveavsökningar

Containerbaserade program kan köras under längre tidsperioder, vilket resulterar i brutna tillstånd som kan behöva repareras genom att containern startas om. Azure Container Instances stöder liveness-avsökningar så att du kan konfigurera dina containrar i containergruppen så att de startas om om viktiga funktioner inte fungerar. Liveness-avsökningen fungerar som en Kubernetes liveness-avsökning.

Den här artikeln beskriver hur du distribuerar en containergrupp som innehåller en liveness-avsökning som visar automatisk omstart av en simulerad container med feltillstånd.

Azure Container Instances stöder också beredskapsavsökningar, som du kan konfigurera för att säkerställa att trafiken endast når en container när den är redo för den.

YAML-distribution

Skapa en liveness-probe.yaml fil med följande kodfragment. Den här filen definierar en containergrupp som består av en NGINX-container som så småningom blir felaktig.

apiVersion: 2019-12-01
location: eastus
name: livenesstest
properties:
  containers:
  - name: mycontainer
    properties:
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      command:
        - "/bin/sh"
        - "-c"
        - "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
      ports: []
      resources:
        requests:
          cpu: 1.0
          memoryInGB: 1.5
      livenessProbe:
        exec:
            command:
                - "cat"
                - "/tmp/healthy"
        periodSeconds: 5
  osType: Linux
  restartPolicy: Always
tags: null
type: Microsoft.ContainerInstance/containerGroups

Kör följande kommando för att distribuera den här containergruppen med ovanstående YAML-konfiguration:

az container create --resource-group myResourceGroup --name livenesstest -f liveness-probe.yaml

Startkommando

Distributionen innehåller en command egenskap som definierar ett startkommando som körs när containern först börjar köras. Den här egenskapen accepterar en matris med strängar. Det här kommandot simulerar att containern går in i ett feltillstånd.

Först startas en bash-session och en fil som anropas healthy i /tmp katalogen skapas. Den försätts sedan i viloläge i 30 sekunder innan du tar bort filen och anger sedan en vilotid på 10 minuter:

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"

Liveness-kommando

Den här distributionen definierar ett livenessProbe som stöder ett exec liveness-kommando som fungerar som liveness-kontroll. Om det här kommandot avslutas med ett värde som inte är noll, avlivas containern och startas om, vilket signalerar att healthy filen inte kunde hittas. Om det här kommandot avslutas med slutkod 0 utförs ingen åtgärd.

Egenskapen periodSeconds anger att kommandot liveness ska köras var 5:e sekund.

Verifiera liveness-utdata

Inom de första 30 sekunderna finns filen healthy som skapades av startkommandot. När liveness-kommandot söker efter healthy filens existens returnerar statuskoden 0, vilket signalerar att den lyckas, så ingen omstart sker.

Efter 30 sekunder cat /tmp/healthy börjar kommandot att misslyckas, vilket gör att fel och dödande händelser inträffar.

Dessa händelser kan visas från Azure-portalen eller Azure CLI.

Händelse som inte är felfri i portalen

Genom att visa händelserna i Azure-portalen utlöses händelser av typen Unhealthy när liveness-kommandot misslyckas. Den efterföljande händelsen är av typen Killing, vilket betyder att en container tas bort så att en omstart kan påbörjas. Antalet omstarter för containern ökar varje gång den här händelsen inträffar.

Omstarter slutförs på plats så att resurser som offentliga IP-adresser och nodspecifikt innehåll bevaras.

Räknare för omstart av portal

Om liveness-avsökningen kontinuerligt misslyckas och utlöser för många omstarter, går containern in i en exponentiell fördröjning av säkerhetskopieringen.

Liveness-avsökningar och omstartsprinciper

Omstartsprinciper ersätter omstartsbeteendet som utlöses av liveness-avsökningar. Om du till exempel anger en restartPolicy = Neveroch en liveness-avsökning startas containergruppen inte om på grund av en misslyckad liveness-kontroll. Containergruppen följer i stället containergruppens omstartsprincip Neverför .

Nästa steg

Uppgiftsbaserade scenarier kan kräva en liveness-avsökning för att aktivera automatiska omstarter om en förutsättningsfunktion inte fungerar korrekt. Mer information om hur du kör aktivitetsbaserade containrar finns i Köra containerbaserade uppgifter i Azure Container Instances.