Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieses Dokument hilft Ihnen beim Einrichten einer Beispielanwendung, die die Ressourcen aus der Gateway-API verwendet, um das Datenverkehrsrouting basierend auf URL-Pfad, Abfragezeichenfolge und Header zu veranschaulichen. Es sind Schritte vorgesehen:
- Erstellen Sie eine Gateway Ressource mit einem HTTPS-Listener.
- Erstellen Sie eine HTTPRoute Ressource, die auf einen Back-End-Dienst verweist.
- Verwenden Sie HTTPRouteMatch , um diese Route basierend auf Pfad, Header und Abfragezeichenfolge auszuführen
matches.
Hintergrund
Das Anwendungsgateway für Container ermöglicht das Datenverkehrsrouting basierend auf URL-Pfad, Abfragezeichenfolge und Header. Sehen Sie sich folgendes Beispielszenario an:
Voraussetzungen
Wenn Sie die BYO-Bereitstellungsstrategie anwenden, stellen Sie sicher, dass Sie Ihr Application Gateway für Containerressourcen und ALB-Controller eingerichtet haben.
Wenn Sie die vom ALB verwaltete Bereitstellungsstrategie ausführen, stellen Sie sicher, dass Sie Ihren ALB-Controller bereitgestellt und das Application Gateway für Containerressourcen über die benutzerdefinierte ApplicationLoadBalancer-Ressource bereitgestellt haben.
Wenden Sie die Datei "deployment.yaml" auf Ihrem Cluster an, um eine HTTP-Beispielanwendung bereitzustellen, die pfad-, abfrage- und headerbasiertes Routing veranschaulicht.
kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yamlMit diesem Befehl wird Folgendes in Ihrem Cluster erstellt:
- ein Namespace namens
test-infra - Zwei Dienste namens
backend-v1undbackend-v2imtest-infra-Namespace - Zwei Bereitstellungen namens
backend-v1undbackend-v2imtest-infra-Namespace
- ein Namespace namens
Bereitstellen der erforderlichen Gateway-API-Ressourcen
Erstellen eines Gateways:
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
Hinweis
Wenn der ALB-Controller das Anwendungsgateway für Containerressourcen in Azure Resource Manager erstellt, verwendet er die folgende Benennungskonvention für eine Frontend-Ressource: fe-<eight randomly generated characters>
Wenn Sie den Namen der in Azure erstellten Frontend-Ressource ändern möchten, sollten Sie die Bring-Your-Own-Bereitstellungsstrategie beachten.
Nachdem die Gatewayressource erstellt wurde, stellen Sie sicher, dass der Status gültig ist, der Listener programmiert ist und dem Gateway eine Adresse zugewiesen wird.
kubectl get gateway gateway-01 -n test-infra -o yaml
Beispielausgabe einer erfolgreichen Gatewayerstellung.
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 eine HTTPRoute, um zwei verschiedene Übereinstimmungen und einen Standarddienst zu definieren, an den Datenverkehr weitergeleitet werden soll.
Die Art und Weise, wie die folgenden Regeln gelesen werden, sind wie folgt:
- Wenn der Pfad /bar lautet, wird der Datenverkehr an den Back-End-v2-Dienst am Port 8080 weitergeleitet.
- Wenn die Anforderung einen HTTP-Header mit dem Namen magic und dem Wert foo enthält, die URL eine Abfragezeichenfolge mit dem Namen great und dem Wert example enthält UND der Pfad /some/thing ist, wird die Anforderung an backend-v2 an Port 8080 gesendet.
- Andernfalls werden alle anderen Anforderungen an den Back-End-v1-Dienst am Port 8080 weitergeleitet.
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
Tipp
Das Anwendungsgateway für Container unterstützt den regulären Ausdrucksabgleich für headers-, queryParams- und path-Regeln mithilfe der Regular Expression 2 (RE2)-Syntax. Weitere Informationen finden Sie in der Gateway-API-Spezifikation.
Nachdem die HTTPRoute-Ressource erstellt wurde, stellen Sie sicher, dass die Route akzeptiert wurde und das Anwendungsgateway für Container-Ressource programmiert wurde.
kubectl get httproute http-route -n test-infra -o yaml
Überprüfen Sie, ob der Status der Ressource „Application Gateway for Containers“ 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 Sie über den FQDN, der dem Front-End zugewiesen ist, Datenverkehr an die 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}')
Mithilfe des Curl-Befehls können wir drei verschiedene Szenarien überprüfen:
Routing auf Pfadbasis
In diesem Szenario wird die gesendete http://frontend-fqdn/bar Clientanforderung an den Back-End-v2-Dienst weitergeleitet.
Führen Sie den folgenden Befehl aus:
curl http://$fqdn/bar
Beachten Sie, dass der Container, der die Anforderung bedient, back-end-v2 ist.
Abfragezeichenfolge + Header + Pfadrouting
In diesem Szenario wird die Clientanforderung, die mit einem Headerschlüssel/Wertteil von "magic: foo" an http://frontend-fqdn/some/thing?great=example gesendet wird, an den Back-End-v2-Dienst weitergeleitet.
Führen Sie den folgenden Befehl aus:
curl http://$fqdn/some/thing?great=example -H "magic: foo"
Beachten Sie, dass der Container, der die Anforderung bedient, back-end-v2 ist.
Standardroute
Wenn keines der ersten beiden Szenarien erfüllt ist, leitet Das Anwendungsgateway für Container alle anderen Anforderungen an den Back-End-v1-Dienst weiter.
Führen Sie den folgenden Befehl aus:
curl http://$fqdn/
Beachten Sie, dass der Container, der die Anforderung bedient, back-end-v1 ist.
Herzlichen Glückwunsch, Sie haben ALB Controller installiert, eine Back-End-Anwendung bereitgestellt und den Datenverkehr über die Gateway-API für Container an die Anwendung weitergeleitet.