Skonfiguruj sondy aktywnoś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 liveness, dzięki czemu można skonfigurować kontenery w grupie kontenerów do ponownego uruchomienia, jeśli przestanie działać kluczowa funkcjonalność. Sonda żywotności działa jak sonda żywotności Kubernetes.

W tym artykule wyjaśniono, jak wdrożyć grupę kontenerów, która zawiera sondę żywotności, demonstrując automatyczne ponowne uruchamianie niesprawnego symulowanego kontenera.

Azure Container Instances obsługuje również sondy sprawdzające gotowość, które można skonfigurować, aby zapewnić, że ruch dociera do kontenera tylko wtedy, gdy jest gotowy na jego obsługę.

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

Uruchom 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 katalogu /tmp. 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 polecenie sprawdzające żywotność exec, działające jako kontrola żywotności. Jeśli to polecenie zakończy działanie z wartością niezerową, kontener zostanie zatrzymany i uruchomiony ponownie, czego przyczyną jest brak pliku healthy. 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, że polecenie liveness powinno być wykonywane co 5 sekund.

Weryfikowanie danych wyjściowych transmisji na żywo

Przez pierwsze 30 sekund istnieje plik healthy utworzony poleceniem start. Gdy polecenie liveness sprawdza istnienie pliku healthy, kod stanu zwraca 0, co sygnalizuje powodzenie, więc ponowne uruchomienie nie jest konieczne.

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 na portalu Azure, zdarzenia typu Unhealthy są wyzwalane po niepowodzeniu komendy 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 powoduje zbyt wiele ponownych uruchomień, kontener wchodzi w wykładniczy czas opóźnienia.

Sondy gotowości i polityki 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 stosuje się do swojej polityki ponownego uruchamiania Never.

Następne kroki

Scenariusze oparte na zadaniach mogą wymagać sondy żywotności, aby umożliwić automatyczne ponowne uruchomienie, jeśli funkcja wstępna 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).