Udostępnij za pośrednictwem

Sondy kondycji w usłudze Azure Container Apps

  • Artykuł

Sondy kondycji usługi Azure Container Apps umożliwiają środowisku uruchomieniowemu usługi Container Apps regularne sprawdzanie stanu aplikacji kontenera.

Sondy można skonfigurować wyłącznie przy użyciu protokołu TCP lub HTTP(S).

Usługa Container Apps obsługuje następujące sondy:

Sonda opis
Uruchamianie Sprawdza, czy aplikacja została pomyślnie uruchomiona. Ta kontrola jest oddzielona od sondy aktualności i jest wykonywana w początkowej fazie uruchamiania aplikacji.
Liveness (Żywość) Sprawdza, czy aplikacja jest nadal uruchomiona i odpowiada.
Gotowość Sprawdza, czy replika jest gotowa do obsługi żądań przychodzących.

Pełną listę specyfikacji sondy obsługiwanych w usłudze Azure Container Apps można znaleźć w temacie Specyfikacje interfejsu API REST platformy Azure.

Sondy HTTP

Sondy HTTP umożliwiają zaimplementowanie logiki niestandardowej w celu sprawdzenia stanu zależności aplikacji przed raportowaniem stanu dobrej kondycji.

Skonfiguruj punkty końcowe sondy kondycji, aby odpowiadały przy użyciu kodu stanu HTTP większego lub równego 200 i mniejszego niż 400 , aby wskazać powodzenie. Każdy inny kod odpowiedzi poza tym zakresem wskazuje błąd.

W poniższym przykładzie pokazano, jak zaimplementować punkt końcowy aktualności w języku JavaScript.

const express = require('express');
const app = express();

app.get('/liveness', (req, res) => {
  let isSystemStable = false;
  
  // check for database availability
  // check filesystem structure
  //  etc.

  // set isSystemStable to true if all checks pass

  if (isSystemStable) {
    res.status(200); // Success
  } else {
    res.status(503); // Service unavailable
  }
})

Sondy TCP

Sondy TCP czekają na nawiązanie połączenia z serwerem, aby wskazać powodzenie. Sonda kończy się niepowodzeniem, jeśli nie może nawiązać połączenia z aplikacją.

Ograniczenia

  • Można dodać tylko jeden z każdego typu sondy dla kontenera.
  • exec sondy nie są obsługiwane.
  • Wartości portów muszą być liczbami całkowitymi; nazwane porty nie są obsługiwane.
  • Usługa gRPC nie jest obsługiwana.

Przykłady

Poniższa lista kodu pokazuje, jak można zdefiniować sondy kondycji dla kontenerów.

Symbole ... zastępcze oznaczają pominięty kod. Aby uzyskać szczegółowe informacje na temat szablonu usługi ARM, zapoznaj się ze specyfikacją interfejsu API szablonu arm usługi Container Apps.

{
  ...
  "containers":[
    {
      "image":"nginx",
      "name":"web",
      "probes": [
        {
          "type": "liveness",
          "httpGet": {
            "path": "/health",
            "port": 8080,
            "httpHeaders": [
              {
                "name": "Custom-Header",
                "value": "liveness probe"
              }]
          },
          "initialDelaySeconds": 7,
          "periodSeconds": 3
        },
        {
          "type": "readiness",
          "tcpSocket": {
            "port": 8081
          },
          "initialDelaySeconds": 10,
          "periodSeconds": 3
        },
        {
          "type": "startup",
          "httpGet": {
            "path": "/startup",
            "port": 8080,
            "httpHeaders": [
              {
                "name": "Custom-Header",
                "value": "startup probe"
              }]
          },
          "initialDelaySeconds": 3,
          "periodSeconds": 3
        }]
    }]
  ...
}

Opcjonalne failureThreshold ustawienie definiuje liczbę prób wykonania sondy przez usługę Container Apps, jeśli wykonanie zakończy się niepowodzeniem. Próby, które przekraczają failureThreshold ilość, powodują różne wyniki dla każdego typu sondy.

Konfiguracja domyślna

Jeśli ruch przychodzący jest włączony, następujące sondy domyślne są automatycznie dodawane do głównego kontenera aplikacji, jeśli żaden z nich nie jest zdefiniowany dla każdego typu.

Typ sondy Wartości domyślne
Uruchamianie Protokół: TCP
Port: port docelowy ruchu przychodzącego
Limit czasu: 3 sekundy
Okres: 1 sekunda
Opóźnienie początkowe: 1 sekunda
Próg powodzenia: 1
Próg niepowodzenia: 240
Liveness (Żywość) Protokół: TCP
Port: port docelowy ruchu przychodzącego
Gotowość Protokół: TCP
Port: port docelowy ruchu przychodzącego
Limit czasu: 5 sekund
Okres: 5 sekund
Opóźnienie początkowe: 3 sekundy
Próg powodzenia: 1
Próg niepowodzenia: 48

Jeśli używasz aplikacji kontenera w trybie wielu poprawek, po wdrożeniu poprawki poczekaj, aż sondy gotowości wskażą powodzenie przed przeniesieniem ruchu do tej poprawki. W trybie pojedynczej poprawki ruch jest przesuwany automatycznie, gdy sonda gotowości zwróci stan powodzenia.

Stan poprawki jest wyświetlany jako w złej kondycji, jeśli którakolwiek z jego replik zakończy się niepowodzeniem, nawet jeśli wszystkie inne repliki w wersji są w dobrej kondycji. Usługa Container Apps ponownie uruchamia replikę, dopóki nie zostanie ponownie w dobrej kondycji lub próg awarii zostanie przekroczony. Jeśli próg niepowodzenia zostanie przekroczony, spróbuj ponownie uruchomić poprawkę, ale może to oznaczać, że poprawka nie jest poprawnie skonfigurowana.

Jeśli uruchomienie aplikacji zajmuje dłuższy czas (co jest powszechne w języku Java), często trzeba dostosować sondy, aby kontener nie ulegał awarii.

W poniższym przykładzie pokazano, jak skonfigurować sondy aktualności i gotowości w celu wydłużenia czasu uruchamiania.

"probes": [
       {
        "type": "liveness",
        "failureThreshold": 3,
        "periodSeconds": 10,
        "successThreshold": 1,
        "tcpSocket": {
          "port": 80
        },
        "timeoutSeconds": 1
       },
       {
         "type": "readiness",
         "failureThreshold": 48,
         "initialDelaySeconds": 3,
         "periodSeconds": 5,
         "successThreshold": 1,
         "tcpSocket": {
           "port": 80
          },
          "timeoutSeconds": 5
       }]

Następne kroki

Rejestrowanie aplikacji