Konfigurowanie sond żywotności
Aplikacje konteneryzowane mogą być uruchamiane przez dłuższy czas, co może powodować konieczność naprawy uszkodzonych stanów przez ponowne uruchomienie kontenera. Usługa Azure Container Instances obsługuje sondy na żywo, dzięki czemu można skonfigurować kontenery w grupie kontenerów do ponownego uruchomienia, jeśli funkcje krytyczne nie działają. Sonda liveness zachowuje się jak sonda liveness platformy Kubernetes.
W tym artykule wyjaśniono, jak wdrożyć grupę kontenerów, która zawiera sondę aktualności, demonstrując automatyczne ponowne uruchamianie symulowanego kontenera w złej kondycji.
Usługa Azure Container Instances obsługuje również sondy gotowości, które można skonfigurować w celu zapewnienia, że ruch dociera do kontenera tylko wtedy, gdy jest gotowy.
Wdrażanie YAML
liveness-probe.yaml
Utwórz plik przy użyciu następującego fragmentu kodu. Ten plik definiuje grupę kontenerów składającą się z kontenera NGINX, który ostatecznie stanie się w złej kondycji.
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
Uruchom następujące polecenie, aby wdrożyć tę grupę kontenerów z poprzednią konfiguracją YAML:
az container create --resource-group myResourceGroup --name livenesstest -f liveness-probe.yaml
Uruchomienie — Polecenie
Wdrożenie zawiera właściwość definiującą command
polecenie początkowe uruchamiane po pierwszym uruchomieniu kontenera. Ta właściwość akceptuje tablicę ciągów. To polecenie symuluje, że kontener wchodzi w stan złej kondycji.
Najpierw uruchamia sesję powłoki bash i tworzy plik o nazwie healthy
w /tmp
katalogu. Następnie spanie przez 30 sekund przed usunięciem pliku, a następnie wprowadza 10-minutowy sen:
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
Liveness, polecenie
To wdrożenie definiuje element livenessProbe
, który obsługuje exec
polecenie liveness, które działa jako kontrola aktualności. Jeśli to polecenie zakończy działanie z wartością niezerową, kontener zostanie zabity i uruchomiony ponownie, co oznacza healthy
, że nie można odnaleźć pliku. Jeśli to polecenie zakończy się pomyślnie z kodem zakończenia 0, nie zostanie podjęta żadna akcja.
Właściwość periodSeconds
wyznacza polecenie liveness powinno być wykonywane co 5 sekund.
Weryfikowanie danych wyjściowych transmisji na żywo
W ciągu pierwszych 30 sekund healthy
plik utworzony przez polecenie start istnieje. Gdy polecenie liveness sprawdza healthy
istnienie pliku, kod stanu zwraca wartość 0, sygnalizując powodzenie, więc ponowne uruchomienie nie występuje.
Po 30 sekundach cat /tmp/healthy
polecenie zaczyna wieść się niepowodzeniem, powodując wystąpienie zdarzeń w złej kondycji i zabijanie.
Te zdarzenia można wyświetlić w witrynie Azure Portal lub w interfejsie wiersza polecenia platformy Azure.
Wyświetlając zdarzenia w witrynie Azure Portal, zdarzenia typu Unhealthy
są wyzwalane po niepowodzeniu polecenia liveness. Kolejne zdarzenie jest typu Killing
, oznaczając usunięcie kontenera, aby można było rozpocząć ponowne uruchomienie. Liczba ponownych uruchomień kontenera zwiększa się za każdym razem, gdy wystąpi to zdarzenie.
Ponowne uruchomienia są wykonywane w miejscu, więc zasoby, takie jak publiczne adresy IP i zawartość specyficzna dla węzła, są zachowywane.
Jeśli sonda liveness stale kończy się niepowodzeniem i wyzwala zbyt wiele ponownych uruchomień, kontener wprowadza wykładnicze opóźnienie wycofywania.
Sondy liveness i zasady ponownego uruchamiania
Zasady ponownego uruchamiania zastępują zachowanie ponownego uruchamiania wyzwalane przez sondy aktualności. Jeśli na przykład ustawisz sondę restartPolicy = Never
liveness i , grupa kontenerów nie zostanie ponownie uruchomiona z powodu nieudanego sprawdzania aktualności. Zamiast tego grupa kontenerów jest zgodna z zasadami ponownego uruchamiania grupy kontenerów .Never
Następne kroki
Scenariusze oparte na zadaniach mogą wymagać sondy aktualności w celu włączenia automatycznych ponownych uruchomień, jeśli funkcja wymagań wstępnych nie działa prawidłowo. Aby uzyskać więcej informacji na temat uruchamiania kontenerów opartych na zadaniach, zobacz Run containerized tasks in Azure Container Instances (Uruchamianie konteneryzowanych zadań w usłudze Azure Container Instances).