Sondeo de estado personalizado para la Puerta de enlace de aplicaciones para contenedores de Azure

Puerta de enlace de aplicaciones para contenedores supervisa el estado de todos los destinos de back-end de forma predeterminada. A medida que los destinos de back-end se vuelven correctos o incorrectos, Puerta de enlace de aplicaciones para contenedores solo distribuye el tráfico a puntos de conexión correctos.

Aparte del uso de la supervisión del sondeo de estado, también puede personalizar el sondeo de estado para adaptarlo a las necesidades de su aplicación. En este artículo se describen los sondeos de estado predeterminados y personalizados.

El orden y la lógica del sondeo de estado son los siguientes:

1. Use la definición del recurso personalizado (CR) HealthCheckPolicy.
2. Si no hay ninguna CR de HealthCheckPolicy, use el sondeo de preparación.
3. Si no hay ningún sondeo de preparación definido, use el sondeo de estado predeterminado.

Las siguientes propiedades componen sondeos de estado personalizados:

Propiedad	Valor predeterminado
interval	la frecuencia con la que se deben enviar sondeos de estado en segundos al destino de back-end. El intervalo mínimo debe ser de > 0 segundos.
timeout	cuánto tiempo en segundos la solicitud debe esperar hasta que se marque como un error. El intervalo mínimo debe ser de > 0 segundos.
healthyThreshold	el número de sondeos de estado antes de marcar el punto de conexión de destino como en buen estado. El intervalo mínimo debe ser > 0.
unhealthyThreshold	el número de sondeos de estado que producirán errores antes de que el destino de back-end se deba etiquetar como incorrecto. El intervalo mínimo debe ser > 0.
(http) host	el nombre de host especificado en la solicitud al destino de back-end.
(http) ruta de acceso	la ruta de acceso específica de la solicitud. Si se debe cargar un solo archivo, la ruta de acceso podría ser /index.html.
(http - coincidencia >) statusCodes	Contiene dos propiedades, start y end, que definen el intervalo de códigos de estado HTTP válidos devueltos desde el back-end.

Sondeo de estado predeterminado

Puerta de enlace de aplicaciones para contenedores configura automáticamente un sondeo de estado predeterminado cuando no se define una configuración de sondeo personalizada ni se configura un sondeo de preparación. El comportamiento de supervisión funciona mediante la realización de una solicitud HTTP GET a las direcciones IP de los destinos back-end configurados. En el caso de los sondeos predeterminados, si el destino de back-end está configurado para HTTPS, el sondeo usa HTTPS para probar el estado de los destinos de back-end.

Para obtener más detalles de implementación, consulte HealthCheckPolicyConfig en la especificación de la API.

Cuando se usa el sondeo de estado predeterminado, se usan los siguientes valores para cada propiedad de sondeo de estado:

Propiedad	Valor predeterminado
interval	5 segundos
timeout	30 segundos
healthyThreshold	1 sondeo
unhealthyThreshold	3 sondeos
port	El número de puerto utilizado se define mediante el número de puerto de back-end en el recurso de entrada o el puerto back-end httpRoute en el recurso HttpRoute.
protocolo	HTTP para HTTP y HTTPS cuando se especifica TLS
(http) host	localhost
(http) ruta de acceso	/

Nota:

Los sondeos de estado se inician con el valor User-Agent de Microsoft-Azure-Application-LB/AGC.

Sondeo de estado personalizado

Tanto en la API de puerta de enlace como en la API de entrada, se puede definir un sondeo de estado personalizado definiendo un recurso HealthCheckPolicyPolicy y haciendo referencia a un servicio con el que deben comprobarse los sondeos de estado. A medida que un recurso HTTPRoute o de entrada hace referencia al servicio con una referencia de clase a Puerta de enlace de aplicaciones para contenedores, el sondeo de estado personalizado se usa para cada referencia.

En este ejemplo, el sondeo de estado emitido por Puerta de enlace de aplicaciones para contenedores envía el nombre de host contoso.com a los pods que componen el test-service. La ruta de acceso de la solicitud es /, se emite un sondeo cada 5 segundos y se espera 3 segundos antes de determinar que el tiempo de espera de la conexión se ha agotado. Si se recibe una respuesta, un código de respuesta HTTP entre 200 y 299 (incluidos 200 y 299) se considera correcto. Todas las demás respuestas se consideran incorrectas.

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
    protocol: HTTP
    http:
      host: contoso.com
      path: /
      match:
        statusCodes: 
        - start: 200
          end: 299
EOF