Udostępnij za pomocą


Hostowanie wielu witryn za pomocą usługi Application Gateway dla kontenerów — API bramy

Ten dokument ułatwia skonfigurowanie przykładowej aplikacji wykorzystującej zasoby z interfejsu API Gateway w celu zademonstrowania hostowania wielu witryn na tym samym zasobie Kubernetes Gateway / Application Gateway for Containers. Podano kroki, aby:

  • Utwórz zasób Gateway z jednym odbiornikiem HTTP.
  • Utwórz dwa zasoby usługi HTTPRoute , które odwołują się do unikatowej usługi zaplecza.

Kontekst

Usługa Application Gateway dla kontenerów umożliwia hostowanie wielu witryn, umożliwiając skonfigurowanie więcej niż jednej aplikacji internetowej na tym samym porcie. Co najmniej dwie unikatowe witryny mogą być hostowane przy użyciu unikatowych usług zaplecza. Zobacz następujący przykładowy scenariusz:

Rysunek przedstawiający hostowanie w wielu lokacjach za pomocą usługi Application Gateway dla kontenerów.

Wymagania wstępne

  1. Jeśli użyto strategii wdrażania BYO, upewnij się, że skonfigurujesz Application Gateway for Containers i kontroler ALB.

  2. Jeśli użyłeś strategii wdrażania zarządzanego ALB, upewnij się, że aprowizowany jest zarówno Kontroler ALB, jak i zasoby usługi Application Gateway for Containers, za pośrednictwem niestandardowego zasobu ApplicationLoadBalancer.

  3. Wdróż przykładową aplikację HTTP:
    Zastosuj następujący plik deployment.yaml w klastrze, aby utworzyć przykładową aplikację internetową w celu zademonstrowania routingu opartego na ścieżkach, zapytaniach i nagłówkach.

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

    To polecenie tworzy w klastrze następujące elementy:

    • Przestrzeń nazw o nazwie test-infra
    • Dwie usługi o nazwie backend-v1 i backend-v2 w test-infra przestrzeni nazw
    • Dwa wdrożenia o nazwie backend-v1 i backend-v2 w przestrzeni nazw o nazwie test-infra

Wdróż wymagane zasoby Gateway API

  1. Tworzenie bramy
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

Uwaga / Notatka

Gdy kontroler usługi ALB tworzy zasoby usługi Application Gateway for Containers w usłudze Azure Resource Manager, używa następującej konwencji nazewnictwa dla zasobu frontonu: fe-<eight randomly generated characters>.

Jeśli chcesz zmienić nazwę zasobu interfejsu frontowego utworzonego w Azure, rozważ zastosowanie strategii wdrożenia 'bring-your-own'.

Po utworzeniu zasobu bramy upewnij się, że stan jest prawidłowy, nasłuchiwacz jest zaprogramowany, a do bramy przypisano adres.

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

Przykładowy wynik pomyślnie utworzonej bramy.

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

Po utworzeniu bramy utwórz dwa zasoby HTTPRoute dla contoso.com i fabrikam.com nazw domen. Każda domena przekazuje ruch do innej usługi zaplecza.

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

Po utworzeniu zasobu usługi HTTPRoute upewnij się, że oba zasoby usługi HTTPRoute zawierają wartość Zaakceptowane , a zasób Application Gateway for Containers jest zaprogramowany.

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

Sprawdź, czy stan zasobu usługi Application Gateway dla kontenerów został pomyślnie zaktualizowany dla każdej usługi 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

Testowanie dostępu do aplikacji

Teraz jesteśmy gotowi wysłać ruch do naszej przykładowej aplikacji za pośrednictwem FQDN przypisanego do frontend. Użyj następującego polecenia, aby uzyskać pełną nazwę domeny (FQDN).

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

Jeśli określisz wskaźnik nazwy serwera przy użyciu polecenia curl, contoso.com dla nazwy FQDN frontonu zwraca odpowiedź z usługi backend-v1.

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

W odpowiedzi powinniśmy zobaczyć:

{
 "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"
}

Jeśli określisz wskazanie nazwy serwera przy użyciu polecenia curl dla nazwy FQDN frontend, zwraca ono odpowiedź z usługi backend-v1.

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

W odpowiedzi powinniśmy zobaczyć:

{
 "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"
}

Gratulacje, zainstalowano kontroler ALB, wdrożono aplikację zaplecza i skierowano ruch do dwóch różnych usług zaplecza przy użyciu różnych nazw hostów za pomocą interfejsu API bramy na Application Gateway for Containers.