Erneutes generieren der URL für Application Gateway für Container – Gateway-API
Application Gateway für Container ermöglicht es Ihnen, die URL einer Clientanforderung erneut zu generieren, einschließlich des Hostnamens und/oder des Pfads der Anforderungen. Wenn Application Gateway für Container die Anforderung an das Back-End-Ziel initiiert, enthält die Anforderung die neu generierte URL, um die Anforderung zu initiieren.
Nutzungsdetails
URL-Rewrites benutzen Filter, die von der Kubernetes-Gateway-API definiert sind.
Hintergrund
Das URL-Rewrite ermöglicht es Ihnen, eine eingehende Anforderung in eine andere URL zu übersetzen, wenn sie in ein Back-End-Ziel initiiert wird.
Die folgende Abbildung zeigt ein Beispiel für eine Anforderung, die für contoso.com/shop bestimmt ist und in contoso.com/ecommerce umgeschrieben wird. Die Anforderung wird vom Anwendungsgateway für Container an das Back-End-Ziel initiiert:
Voraussetzungen
Wenn Sie der BYO-Bereitstellungsstrategie folgen, stellen Sie sicher, dass Sie Ihr Application Gateway für Containerressourcen und ALB-Controller eingerichtet haben.
Wenn Sie der vom ALB verwalteten Bereitstellungsstrategie folgen, stellen Sie sicher, dass Sie den ALB-Controller und die Application Gateway für Containerressourcen über die benutzerdefinierte ApplicationLoadBalancer-Ressource bereitstellen.
Bereitstellen einer Beispiel-HTTP-Anwendung
Wenden Sie die folgende Datei „deployment.yaml“ auf Ihrem Cluster an, um ein Beispiel-TLS-Zertifikat einzusetzen und die Umleitungsfunktionen zu demonstrieren.
kubectl apply -f kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/https-scenario/ssl-termination/deployment.yaml
Mit diesem Befehl wird Folgendes in Ihrem Cluster erstellt:
- Ein Namespace namens
test-infra
- Ein Dienst, der im Namespace
echo
alstest-infra
bezeichnet wird - Eine Bereitstellung, die im Namespace
echo
alstest-infra
bezeichnet wird - Ein Geheimnis, das im Namespace
listener-tls-secret
alstest-infra
bezeichnet wird
- Ein Namespace namens
Bereitstellen der erforderlichen Gateway-API-Ressourcen
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.
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 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-Ressource für contoso.com
. In diesem Beispiel wird sichergestellt, dass der Datenverkehr, der an contoso.com/shop
gesendet wird, als contoso.com/ecommerce
an das Back-End-Ziel initiiert wird.
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: rewrite-example
namespace: test-infra
spec:
parentRefs:
- name: gateway-01
hostnames:
- "contoso.com"
rules:
- matches:
- path:
type: PathPrefix
value: /shop
filters:
- type: URLRewrite
urlRewrite:
path:
type: ReplacePrefixMatch
replacePrefixMatch: /ecommerce
backendRefs:
- name: backend-v1
port: 8080
- backendRefs:
- name: backend-v2
port: 8080
EOF
Wenn die HTTPRoute-Ressource erstellt wird, stellen Sie sicher, dass sowohl HTTPRoute-Ressourcen akzeptiert als auch die Application Gateway für Container-Ressource programmiert sind.
kubectl get httproute rewrite-example -n test-infra -o yaml
Überprüfen Sie, ob die Application Gateway for Containers-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 Servernamensindikator mit dem Befehl curl angeben, sollte contoso.com/shop
eine Antwort vom Back-End-v1-Dienst zurückgeben, in welcher der angeforderte Pfad zum Back-End-Ziel als contoso.com/ecommerce
angezeigt wird.
fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com/shop
Über die Antwort sollten wir Folgendes sehen:
{
"path": "/ecommerce",
"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 Servernamenindikator mithilfe des Curl-Befehls angeben, sollte contoso.com
eine Antwort vom Back-End-v2-Dienst zurückgeben.
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": [
"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 Filterung verwendet, um die angeforderte URL des Clients neu zu generieren, bevor der Datenverkehr auf das Ziel für Application Gateway für Container festgelegt wird.