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.
Mit Application Gateway für Container können Sie HTTP-Header von Clientanforderungen und -antworten von Back-End-Zielen umschreiben.
Nutzungsdetails
Headerumschreibungen benutzen Filter, die von der Kubernetes-Gateway-API definiert sind.
Hintergrund
Headerumschreibungen ermöglichen es Ihnen, die Anforderungs- und Antwortkopfzeilen zu und von Ihren Back-End-Zielen zu ändern.
Die folgende Abbildung zeigt eine Anforderung mit einem bestimmten Benutzer-Agent, der in einen vereinfachten Wert namens SearchEngine-BingBot umgeschrieben wird, wenn die Anforderung vom Application Gateway für Container an das Back-End-Ziel initiiert wird:
Voraussetzungen
Wenn Sie die BYO-Bereitstellungsstrategie befolgen, stellen Sie sicher, dass Sie Ihre Application Gateway für Container-Ressourcen und Ihren ALB Controller einrichten
Wenn Sie die vom ALB verwaltete Bereitstellungsstrategie befolgen, stellen Sie sicher, dass dem ALB-Controller das Application Gateway für Containerressourcen über die benutzerdefinierte ApplicationLoadBalancer-Ressource bereitgestellt wird.
Stellen Sie eine Beispiel-HTTP-Anwendung bereit, wenden Sie die folgende Datei „deployment.yaml“ auf Ihrem Cluster an, um eine Beispielwebanwendung zum Veranschaulichen der Headerumschreibung zu erstellen.
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-infraNamespace
- 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 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, 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: IPAddress
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, die auf den Hostnamen contoso.com lauscht und den Wert des Benutzer-Agents für SearchEngine-BingBot überschreibt.
In diesem Beispiel suchen wir nach dem vom Bing-Suchmodul verwendeten Benutzer-Agent und vereinfachen den Header zu SearchEngine-BingBot für eine einfachere Back-End-Analyse.
In diesem Beispiel wird auch das Hinzufügen eines neuen Headers namens AGC-Header-Add mit einem Wert von AGC-value veranschaulicht und ein Anforderungsheader namens client-custom-header entfernt.
Tipp
In diesem Beispiel können wir zwar den HTTPHeaderMatch „Genau“ für eine Zeichenkettenübereinstimmung verwenden, dennoch wird eine Demonstration in regulären Ausdrücken zur Illustration weiterer Fähigkeiten verwendet.
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: header-rewrite-route
namespace: test-infra
spec:
parentRefs:
- name: gateway-01
namespace: test-infra
hostnames:
- "contoso.com"
rules:
- matches:
- headers:
- name: user-agent
value: Mozilla/5\.0 AppleWebKit/537\.36 \(KHTML, like Gecko; compatible; bingbot/2\.0; \+http://www\.bing\.com/bingbot\.htm\) Chrome/
type: RegularExpression
filters:
- type: RequestHeaderModifier
requestHeaderModifier:
set:
- name: user-agent
value: SearchEngine-BingBot
add:
- name: AGC-Header-Add
value: AGC-value
remove: ["client-custom-header"]
backendRefs:
- name: backend-v2
port: 8080
- backendRefs:
- name: backend-v1
port: 8080
EOF
Hinweis
Das Ändern der Host Kopfzeile wird mit einer requestHeaderModifier Regel nicht unterstützt. Verwenden Sie einen Host, um den für das Back-End-Ziel angegebenen Wert außer Kraft zu setzen.
Nachdem die HTTPRoute-Ressource erstellt wurde, stellen Sie sicher, dass die Route Akzeptiert ist und die Ressource „Application Gateway für Container“ programmiert ist.
kubectl get httproute header-rewrite-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, einigen 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}')
Wenn Sie den Server-Namensindikator mit dem curl-Befehl contoso.com für den FQDN des Frontends angeben, sollte die Ausgabe eine Antwort vom Backend-v1-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": [
"dcd4bcad-ea43-4fb6-948e-a906380dcd6d"
]
},
"namespace": "test-infra",
"ingress": "",
"service": "",
"pod": "backend-v1-5b8fd96959-f59mm"
}
Die Angabe eines Benutzer-Agent-Headers mit dem Wert `` sollte eine Antwort vom Back-End-Dienst von SearchEngine-BingBot zurückgeben:
fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com -H "user-agent: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/"
Ü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-5b8fd96959-f59mm"
}
Die Angabe eines client-custom-header-Headers mit dem Wert moo sollte von der Anforderung entfernt werden, wenn das Application Gateway für Container die Verbindung mit dem Back-End-Dienst initiiert:
fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com -H "client-custom-header: moo"
Ü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": [
"kd83nc84-4325-5d22-3d23-237dd4e3941b"
]
},
"namespace": "test-infra",
"ingress": "",
"service": "",
"pod": "backend-v2-5b8fd96959-f59mm"
}
Herzlichen Glückwunsch, Sie haben ALB Controller installiert, eine Back-End-Anwendung bereitgestellt und die Kopfzeilenwerte über die Gateway-API auf Application Gateway für Container bereitgestellt.