Hospedaje multisitio con Application Gateway para contenedores: API de puerta de enlace

Este documento le ayuda a configurar una aplicación de ejemplo que usa los recursos de la API de puerta de enlace para demostrar cómo hospedar varios sitios en el mismo recurso de Puerta de enlace de Kubernetes o Application Gateway para contenedores front-end. Se proporcionan pasos para:

Cree un recurso de puerta de enlace con un agente de escucha HTTP.
Cree dos recursos HTTPRoute que hacen referencia a un servicio back-end único.

Contexto

Application Gateway for Containers permite el hospedaje multisitio al permitirle configurar más de una aplicación web en el mismo puerto. Se pueden hospedar dos o más sitios únicos mediante servicios back-end únicos. Consulte el siguiente escenario de ejemplo:

Ilustración que muestra el hospedaje multisitio con Application Gateway for Containers.

Prerrequisitos

Si ha usado la estrategia de implementación byO, asegúrese de configurar application Gateway para los recursos de Contenedores y el controlador ALB.
Si usó la estrategia de implementación administrada de ALB, asegúrese de aprovisionar el controlador ALB y los recursos de Application Gateway for Containers mediante el recurso personalizado ApplicationLoadBalancer.
Implementación de una 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

Implementación administrada de ALB
Traiga su propia implementación (BYO)

Creación de una puerta de enlace

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
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 ALB crea los recursos de Application Gateway for Containers en Azure Resource Manager, usa la siguiente convención de nomenclatura para un recurso de front-end: fe-<eight randomly generated characters>.

Si desea cambiar el nombre del recurso de front-end creado en Azure, considere la posibilidad de seguir la estrategia de implementación bring-your-own.

Establecimiento de las siguientes variables de entorno

RESOURCE_GROUP='<resource group name of the Application Gateway For Containers resource>'
RESOURCE_NAME='alb-test'

RESOURCE_ID=$(az network alb show --resource-group $RESOURCE_GROUP --name $RESOURCE_NAME --query id -o tsv)
FRONTEND_NAME='frontend'

Creación de una puerta de enlace

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-id: $RESOURCE_ID
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: http-listener
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
  addresses:
  - type: alb.networking.azure.io/alb-frontend
    value: $FRONTEND_NAME
EOF

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 dos recursos HTTPRoute para contoso.com los nombres de dominio y fabrikam.com . Cada dominio reenvía el tráfico a un servicio back-end diferente.

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: contoso-route
  namespace: test-infra
spec:
  parentRefs:
  - name: gateway-01
  hostnames:
  - "contoso.com"
  rules:
  - backendRefs:
    - name: backend-v1
      port: 8080
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: fabrikam-route
  namespace: test-infra
spec:
  parentRefs:
  - name: gateway-01
  hostnames:
  - "fabrikam.com"
  rules:
  - backendRefs:
    - name: backend-v2
      port: 8080
EOF

Una vez creado el recurso HTTPRoute, asegúrese de que los recursos HTTPRoute muestran Aceptado y application Gateway para contenedores está programado.

kubectl get httproute contoso-route -n test-infra -o yaml
kubectl get httproute fabrikam-route -n test-infra -o yaml

Compruebe que el estado del recurso Application Gateway for Containers se ha actualizado correctamente para cada HTTPRoute.

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 front-end. Utilice el siguiente comando para obtener el FQDN.

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

Si especifica el indicador de nombre de servidor mediante el comando curl, contoso.com para el FQDN de front-end, devuelve una respuesta del servicio backend-v1.

fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com

Mediante la respuesta deberíamos ver:

{
 "path": "/",
 "host": "contoso.com",
 "method": "GET",
 "proto": "HTTP/1.1",
 "headers": {
  "Accept": [
   "*/*"
  ],
  "User-Agent": [
   "curl/7.81.0"
  ],
  "X-Forwarded-For": [
   "xxx.xxx.xxx.xxx"
  ],
  "X-Forwarded-Proto": [
   "http"
  ],
  "X-Request-Id": [
   "dcd4bcad-ea43-4fb6-948e-a906380dcd6d"
  ]
 },
 "namespace": "test-infra",
 "ingress": "",
 "service": "",
 "pod": "backend-v1-5b8fd96959-f59mm"
}

Si especifica el indicador de nombre de servidor mediante el comando curl, fabrikam.com para el FQDN de front-end, devuelve una respuesta del servicio backend-v1.

fqdnIp=$(dig +short $fqdn)
curl -k --resolve fabrikam.com:80:$fqdnIp http://fabrikam.com

Mediante la respuesta deberíamos ver:

{
 "path": "/",
 "host": "fabrikam.com",
 "method": "GET",
 "proto": "HTTP/1.1",
 "headers": {
  "Accept": [
   "*/*"
  ],
  "User-Agent": [
   "curl/7.81.0"
  ],
  "X-Forwarded-For": [
   "xxx.xxx.xxx.xxx"
  ],
  "X-Forwarded-Proto": [
   "http"
  ],
  "X-Request-Id": [
   "adae8cc1-8030-4d95-9e05-237dd4e3941b"
  ]
 },
 "namespace": "test-infra",
 "ingress": "",
 "service": "",
 "pod": "backend-v2-594bd59865-ppv9w"
}

Enhorabuena, ha instalado ALB Controller, ha implementado una aplicación back-end y enrutado el tráfico a dos servicios back-end diferentes a través de diferentes nombres de host a través de la API de puerta de enlace en Application Gateway for Containers.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2025-08-13