Compartir a través de

Ruta de acceso, encabezado y enrutamiento de cadenas de consulta con Puerta de enlace de aplicaciones para contenedores: API de puerta de enlace

  • Artículo

Este documento le ayuda a configurar una aplicación de ejemplo que usa los recursos de la API de puerta de enlace para demostrar el enrutamiento del tráfico basado en una ruta de acceso URL, una cadena de consulta y un encabezado. Se proporcionan pasos para:

  • Crear un recurso de puerta de enlace con un agente de escucha HTTPS.
  • Crear un recurso HTTPRoute que haga referencia a un servicio back-end.
  • Usar HTTPRouteMatch para realizar matches en esa ruta basada una ruta de acceso, un encabezado y una cadena de consulta.

Fondo

Puerta de enlace de aplicaciones para contenedores permite el enrutamiento de tráfico basado en una ruta de acceso de URL, una cadena de consulta y un encabezado. Consulte el siguiente escenario de ejemplo:

Ilustración que muestra el enrutamiento de rutas, encabezados y cadenas de consulta con Puerta de enlace de aplicaciones para contenedores.

Requisitos previos

  1. Si sigue la estrategia de implementación BYO, asegúrese de configurar los recursos de puerta de enlace de aplicaciones para contenedores y el controlador de ALB.

  2. Si sigue la estrategia de implementación administrada de ALB, asegúrese de que ha aprovisionado el controlador de ALB y los recursos de puerta de enlace de aplicaciones para contenedores a través del recurso personalizado ApplicationLoadBalancer.

  3. Implementar aplicación HTTP de ejemplo: aplique el siguiente archivo deployment.yaml en el clúster para crear una aplicación web de ejemplo para mostrar la ruta de acceso, la consulta y el enrutamiento basado en encabezados.

    kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yaml

    Este comando crea lo siguiente en el clúster:

    • un espacio de nombres denominado test-infra
    • dos servicios llamados backend-v1 y backend-v2 en el espacio de nombres test-infra
    • dos implementaciones llamadas backend-v1 y backend-v2 en el espacio de nombres test-infra

Implementación de los recursos necesarios de la API de puerta de enlace

Cree una puerta de enlace:

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: gateway-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-namespace: alb-test-infra
    alb.networking.azure.io/alb-name: alb-test
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: http-listener
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
EOF

Nota:

Cuando el controlador de ALB cree los recursos de Puerta de enlace de aplicaciones para contenedores en ARM, usará las siguientes convenciones de nomenclatura para un recurso de frontend: fe-<8 caracteres generados aleatoriamente>

Si desea cambiar el nombre del frontend creado en Azure, considere la posibilidad de seguir la estrategia Traiga su propia implementación.

Una vez creado el recurso de puerta de enlace, asegúrese de que el estado sea válido, de que el cliente de escucha se haya programado y de que se haya asignado una dirección a la puerta de enlace.

kubectl get gateway gateway-01 -n test-infra -o yaml

Salida de ejemplo de la creación correcta de la puerta de enlace.

status:
  addresses:
  - type: Hostname
    value: xxxx.yyyy.alb.azure.com
  conditions:
  - lastTransitionTime: "2023-06-19T21:04:55Z"
    message: Valid Gateway
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted
  - lastTransitionTime: "2023-06-19T21:04:55Z"
    message: Application Gateway For Containers resource has been successfully updated.
    observedGeneration: 1
    reason: Programmed
    status: "True"
    type: Programmed
  listeners:
  - attachedRoutes: 0
    conditions:
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: ""
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: Listener is accepted
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: Application Gateway For Containers resource has been successfully updated.
      observedGeneration: 1
      reason: Programmed
      status: "True"
      type: Programmed
    name: https-listener
    supportedKinds:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute

Una vez creada la puerta de enlace, cree un elemento HTTPRoute para definir dos coincidencias diferentes y un servicio predeterminado al que enrutar el tráfico.

La manera en que se leen las reglas siguientes es esta:

  1. Si la ruta de acceso es /bar, el tráfico se enruta al servicio backend-v2 en el puerto 8080.
  2. Si la solicitud contiene un encabezado HTTP con el nombre magic y el valor foo, la dirección URL contiene una cadena de consulta que define el nombre excelente con un valor de ejemplo Y la ruta de acceso es /some/thing, la solicitud se envía a backend-v2 en el puerto 8080.
  3. De lo contrario, todas las demás solicitudes se enrutan al servicio backend-v1 en el puerto 8080.
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-route
  namespace: test-infra
spec:
  parentRefs:
  - name: gateway-01
    namespace: test-infra
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /bar
    backendRefs:
    - name: backend-v2
      port: 8080
  - matches:
    - headers:
      - type: Exact
        name: magic
        value: foo
      queryParams:
      - type: Exact
        name: great
        value: example
      path:
        type: PathPrefix
        value: /some/thing
      method: GET
    backendRefs:
    - name: backend-v2
      port: 8080
  - backendRefs:
    - name: backend-v1
      port: 8080
EOF

Una vez creado el recurso HTTPRoute, asegúrese de que la ruta se haya aceptado y el recurso de Puerta de enlace de aplicaciones para contenedores se haya programado.

kubectl get httproute http-route -n test-infra -o yaml

Compruebe que el estado del recurso de Puerta de enlace de aplicaciones para contenedores se haya actualizado correctamente.

status:
  parents:
  - conditions:
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: ""
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: Route is Accepted
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: Application Gateway For Containers resource has been successfully updated.
      observedGeneration: 1
      reason: Programmed
      status: "True"
      type: Programmed
    controllerName: alb.networking.azure.io/alb-controller
    parentRef:
      group: gateway.networking.k8s.io
      kind: Gateway
      name: gateway-01
      namespace: test-infra

Prueba de acceso a la aplicación

Ahora, estamos listos para enviar tráfico a nuestra aplicación de ejemplo mediante el FQDN asignado al frontend. Utilice el siguiente comando para obtener el FQDN.

fqdn=$(kubectl get gateway gateway-01 -n test-infra -o jsonpath='{.status.addresses[0].value}')

Mediante el comando curl, podemos validar tres escenarios diferentes:

Enrutamiento basado en rutas de acceso

En este escenario, la solicitud de cliente enviada a http://frontend-fqdn/bar se enruta al servicio backend-v2.

Ejecute el siguiente comando:

curl http://$fqdn/bar

Observe que el contenedor que atiende la solicitud es backend-v2.

Cadena de consulta + encabezado + enrutamiento de ruta de acceso

En este escenario, la solicitud de cliente enviada a http://frontend-fqdn/some/thing?great=example con una parte de la clave o valor de encabezado de "magic: foo" se enruta al servicio backend-v2.

Ejecute el siguiente comando:

curl http://$fqdn/some/thing?great=example -H "magic: foo"

Observe que el contenedor que atiende la solicitud es backend-v2.

Ruta predeterminada

Si no se cumple ninguno de los dos primeros escenarios, Puerta de enlace de aplicaciones para contenedores enruta todas las demás solicitudes al servicio backend-v1.

Ejecute el siguiente comando:

curl http://$fqdn/

Observe que el contenedor que atiende la solicitud es backend-v1.

Enhorabuena, ha instalado el controlador de ALB, ha implementado una aplicación de back-end y enrutado el tráfico a la aplicación mediante la API de puerta de enlace de Puerta de enlace de aplicaciones para contenedores.