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 nie działają funkcje krytyczne. 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 przy użyciu powyższej konfiguracji 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 niezerową wartością, 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 = Neverliveness i , grupa kontenerów nie zostanie uruchomiona ponownie 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).