Probe di integrità personalizzato per il Gateway applicativo per contenitori

Il Gateway applicativo per contenitori monitora l'integrità di tutte le destinazioni back-end per impostazione predefinita. Man mano che le destinazioni back-end diventano integre o non integre, il Gateway applicativo per contenitori distribuisce il traffico solo agli endpoint integri.

Oltre al monitoraggio del probe di integrità predefinito, è anche possibile personalizzare il probe di integrità in base ai requisiti dell'applicazione. In questo articolo vengono illustrati i probe di integrità predefiniti e personalizzati.

L'ordine e la logica del probe di integrità sono i seguenti:

1. Usare la definizione della risorsa personalizzata HealthCheckPolicy.
2. Se non è presente una risorsa personalizzata HealthCheckPolicy, usare il probe di idoneità
3. Se non è stato definito un probe di idoneità, usare il probe di integrità predefinito

Le proprietà seguenti costituiscono i probe di integrità personalizzati:

Proprietà	Valore predefinito
interval	Frequenza in secondi con cui i probe di integrità devono essere inviati alla destinazione back-end. L'intervallo minimo deve essere > 0 secondi.
timeout	Per quanto tempo (in secondi) la richiesta deve attendere fino a quando non viene contrassegnata come un errore. L'intervallo minimo deve essere > 0 secondi.
healthyThreshold	Numero di probe di integrità prima di contrassegnare l'endpoint di destinazione come integro. L'intervallo minimo deve essere > 0.
port	Numero di porta usato durante il probe della destinazione back-end.
unhealthyThreshold	Numero di probe di integrità che devono non riuscire prima che la destinazione back-end sia etichettata come non integra. L'intervallo minimo deve essere > 0.
grpc	Specificato se il servizio back-end prevede connessioni gRPC. Il valore deve essere {}.
(http)	Specificato se il servizio back-end prevede connessioni HTTP.
(http) host	Nome host specificato nella richiesta alla destinazione back-end.
(http) path	Percorso specifico della richiesta. Se è necessario caricare un singolo file, il percorso potrebbe essere /index.html.
(http -> match) statusCodes	Contiene due proprietà, start e end, che definiscono l'intervallo di codici di stato HTTP validi restituiti dal back-end.
useTLS	Specifica se il controllo integrità deve applicare TLS. Se non specificato, il controllo integrità usa lo stesso protocollo del servizio se per il controllo integrità viene usata la stessa porta. Se la porta è diversa, il controllo integrità è in testo non crittografato.

Probe di integrità predefinito

Il Gateway applicativo per contenitori configura automaticamente un probe di integrità predefinito quando non si definisce una configurazione del probe personalizzata o non si configura un probe di idoneità. Il comportamento di monitoraggio funziona effettuando una richiesta HTTP GET agli indirizzi IP delle destinazioni back-end configurate. Per i probe predefiniti, se la destinazione back-end è configurata per HTTPS, il probe usa HTTPS per testare l'integrità delle destinazioni back-end.

Per altre informazioni sull'implementazione, vedere HealthCheckPolicyConfig nella specifica dell'API.

Quando viene usato il probe di integrità predefinito, vengono usati i valori seguenti per ogni proprietà del probe di integrità:

Proprietà	Valore predefinito
interval	5 secondi
timeout	30 secondi
healthyThreshold	1 probe
unhealthyThreshold	3 probe
port	Il numero di porta usato è definito dal numero di porta back-end nella risorsa Ingresso o dalla porta back-end HttpRoute nella risorsa HttpRoute.
(http) host	localhost
(http) path	/
useTLS	HTTP per HTTP e HTTPS quando si specifica TLS.

¹ HTTPS viene usato quando backendTLSPolicy fa riferimento a un servizio back-end di destinazione (per l'implementazione dell'API gateway) o è specificato IngressExtension con un protocollo backendSetting di HTTPS (per l'implementazione dell'API in ingresso).

Nota

I probe di integrità vengono avviati con il valore User-Agent di Microsoft-Azure-Application-LB/AGC.

Probe di integrità personalizzato

Sia nell'API del gateway che nell'API in ingresso, è possibile definire un probe di integrità personalizzato definendo una risorsa HealthCheckPolicyPolicyPolicy e facendo riferimento a un servizio che i probe di integrità devono controllare. Poiché al servizio fa riferimento una risorsa HTTPRoute o Ingresso con un riferimento di classe al Gateway applicativo per contenitori, per ogni riferimento viene usato il probe di integrità personalizzato.

In questo esempio, il probe di integrità generato dal Gateway applicativo per contenitori invia il nome host contoso.com ai pod che costituiscono test-service. Il protocollo richiesto è http con un percorso /. Viene generato un probe ogni 5 secondi ed è prevista un'attesa di 3 secondi prima di determinare il timeout della connessione. Se viene ricevuta una risposta, un codice di risposta HTTP compreso tra 200 e 299 (inclusi 200 e 299) viene considerato integro, tutte le altre risposte vengono considerate non integre.

kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: HealthCheckPolicy
metadata:
  name: gateway-health-check-policy
  namespace: test-infra
spec:
  targetRef:
    group: ""
    kind: Service
    name: test-service
    namespace: test-infra
  default:
    interval: 5s
    timeout: 3s
    healthyThreshold: 1
    unhealthyThreshold: 1
    port: 8123
    # grpc: {} # defined if probing a gRPC endpoint
    http:
      host: contoso.com
      path: /
      match:
        statusCodes: 
        - start: 200
          end: 299
    useTLS: true
EOF