Standortübergreifendes Hosting mit Application Gateway für Container: Gateway-API

Artikel
03/10/2024

Dieses Dokument hilft Ihnen beim Einrichten einer Beispielanwendung, welche die Ressourcen aus der Gateway-API verwendet, um das Hosten mehrerer Sites auf demselben Kubernetes-Gateway-Ressourcen/Anwendungsgateway für Container-Frontend zu veranschaulichen. Es sind Schritte vorgesehen, um:

Eine Gateway-Ressource mit einem HTTP-Listener zu erstellen.
Zwei HTTPRoute-Ressourcen, die jeweils auf einen eindeutigen Back-End-Dienst verweisen, zu erstellen.

Hintergrund

Application Gateway für Container ermöglicht das Hosting mehrerer Websites, indem Sie mehrere Webanwendungen für denselben Port konfigurieren können. Zwei oder mehr eindeutige Websites können mit eindeutigen Back-End-Diensten gehostet werden. Sehen Sie sich folgendes Beispielszenarien an:

Eine Abbildung des standortübergreifenden Hosting mit Application Gateway für Container.

Voraussetzungen

Wenn Sie die BYO-Bereitstellungsstrategie verwendet haben, stellen Sie sicher, dass Sie Ihr Application Gateway für Containerressourcen und ALB Controller einrichten.
Wenn Sie die Strategie der durch ALB verwalteten Bereitstellung verwendet haben, stellen Sie sicher, dass Ihr ALB-Controller und die Application Gateway für Container-Ressourcen über die benutzerdefinierte ApplicationLoadBalancer-Ressource bereitgestellt werden.
Bereitstellen einer HTTP-Beispielanwendung:
Wenden Sie die folgende Datei „deployment.yaml“ auf Ihrem Cluster an, um eine Beispielwebanwendung zur Veranschaulichung des pfad-, abfrage- und headerbasierten Routings zu erstellen.
```
kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml
```
Mit diesem Befehl wird Folgendes in Ihrem Cluster erstellt:
- Ein Namespace namens test-infra
- Zwei Dienste namens backend-v1 und backend-v2 im test-infra-Namespace
- Zwei Bereitstellungen namens backend-v1 und backend-v2 im test-infra-Namespace

Bereitstellen der erforderlichen Gateway-API-Ressourcen

ALB-verwaltete Bereitstellung
BYO-Bereitstellung (Bring Your Own)

Erstellen eines Gateways

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

Hinweis

Wenn der ALB-Controller die Application Gateway für Container-Ressourcen in ARM erstellt, verwendet er die folgende Benennungskonvention für eine Frontend-Ressource: „fe-<8 zufällig generierte Zeichen>“.

Wenn Sie den Namen des in Azure erstellten Frontends ändern möchten, sollten Sie die BYO-Bereitstellungsstrategie (Bring Your Own) befolgen.

Legen Sie die folgenden Umgebungsvariablen fest.

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'

Erstellen eines Gateways

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

Nachdem die Gatewayressource erstellt wurde, stellen Sie sicher, dass der Status gültig ist, dass der Listener programmiert ist und dem Gateway eine Adresse zugewiesen wird.

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

Beispielausgabe einer erfolgreichen Gateway-Erstellung.

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

Nachdem das Gateway erstellt wurde, erstellen Sie zwei HTTPRoute-Ressourcen für contoso.com und fabrikam.com-Domänennamen. Jede Domäne leitet Datenverkehr an einen anderen Back-End-Dienst weiter.

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

Nachdem die HTTPRoute-Ressource erstellt wurde, stellen Sie sicher, dass sowohl HTTPRoute-Ressourcen akzeptiert als auch die Application Gateway für Container-Ressource programmiert sind.

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

Überprüfen Sie, ob der Status der Application Gateway für Container-Ressource für jede HTTPRoute erfolgreich aktualisiert wurde.

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

Testen des Zugriffs auf die Anwendung

Jetzt können wir über den FQDN, der dem Frontend zugewiesen ist, einige Datenverkehrsdaten an unsere Beispielanwendung senden. Verwenden Sie den folgenden Befehl, um den FQDN abzurufen.

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

Wenn Sie den Servernamen-Indikator mit dem Befehl „curl“ contoso.com für den FQDN des Frontends angeben, wird eine Antwort vom Back-End-v1-Dienst zurückgegeben.

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

Über die Antwort sollten wir Folgendes sehen:

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

Wenn Sie den Servernamen-Indikator mit dem Befehl „curl“ fabrikam.com für den FQDN des Frontends angeben, wird eine Antwort vom Back-End-v1-Dienst zurückgegeben.

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

Über die Antwort sollten wir Folgendes sehen:

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

Herzlichen Glückwunsch, Sie haben ALB Controller installiert, eine Back-End-Anwendung bereitgestellt und den Datenverkehr über verschiedene Hostnamen über Gateway-API auf Application Gateway für Container an zwei verschiedene Back-End-Dienste weitergeleitet.

Share via

Standortübergreifendes Hosting mit Application Gateway für Container: Gateway-API

Hintergrund

Voraussetzungen

Bereitstellen der erforderlichen Gateway-API-Ressourcen

Testen des Zugriffs auf die Anwendung

Zusätzliche Ressourcen