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 den föregående YAML-konfigurationen:
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 icke-nollvärde avlivas containern och startas om, vilket signalerar att healthy
det inte gick att hitta filen. 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.
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.
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 = Never
och en liveness-avsökning startar inte containergruppen om på grund av en misslyckad liveness-kontroll. Containergruppen följer i stället containergruppens omstartsprincip Never
för .
Nästa steg
Aktivitetsbaserade 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.