Anmerkungen für den Azure Application Gateway-Eingangscontroller
Sie können die Kubernetes-Eingangsressource nicht mit beliebigen Schlüssel/Wert-Paaren kommentieren. Der Application Gateway-Eingangsdatencontroller (Application Gateway Ingress Controller, AGIC) basiert auf Anmerkungen zum Programmieren von Azure Application Gateway-Features, die nicht über den Eingangs-YAML konfigurierbar sind. Eingangsanmerkungen werden auf alle HTTP-Einstellungen, Back-End-Pools und Listener angewendet, die von einer Eingangsressource abgeleitet wurden.
Tipp
Weitere Informationen unter Was ist Anwendungsgateway für Container.
Liste unterstützter Anmerkungen
Damit AGIC eine Eingangsressource beobachten kann, muss die Ressource mit kubernetes.io/ingress.class: azure/application-gateway kommentiert werden.
Präfix für Back-End-Pfad
Die folgende Anmerkung ermöglicht es, dass der in einer Eingangsressource angegebene Back-End-Pfad mit dem angegebenen Präfix neu geschrieben wird. Verwenden Sie diese, um Dienste verfügbar zu machen, deren Endpunkte sich von den Endpunktnamen unterscheiden, die Sie verwenden, um einen Dienst in einer Eingangsressource verfügbar zu machen.
Verbrauch
appgw.ingress.kubernetes.io/backend-path-prefix: <path prefix>
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-bkprefix
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-path-prefix: "/test/"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Das vorherigen Beispiel definiert eine Eingangsressource mit Namen go-server-ingress-bkprefix mit einer Anmerkung mit Namen appgw.ingress.kubernetes.io/backend-path-prefix: "/test/". Die Anmerkung weist das Application Gateway an, eine HTTP-Einstellung zu erstellen, bei der es eine Pfadpräfixüberschreibung für den Pfad /hello nach /test/ gibt.
Das Beispiel definiert nur eine Regel. Die Anmerkungen gelten jedoch für die gesamte Eingangsressource. Wenn Sie also mehrere Regeln definieren, richten Sie das Präfix für den Back-End-Pfad für jede der angegebenen Pfade ein. Wenn Sie unterschiedliche Regeln mit unterschiedlichen Pfadpräfixen (sogar für denselben Dienst) wünschen, müssen Sie unterschiedliche Eingangsressourcen definieren.
Back-End-Hostname
Verwenden Sie die folgende Anmerkung, um den Hostnamen anzugeben, den Application Gateway während der Kommunikation mit den Pods verwenden soll.
Verbrauch
appgw.ingress.kubernetes.io/backend-hostname: "internal.example.com"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-timeout
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-hostname: "internal.example.com"
spec:
rules:
- http:
paths:
- path: /hello/
backend:
service:
name: store-service
port:
number: 80
pathType: Exact
Benutzerdefinierter Integritätstest
Sie können Application Gateway kann konfigurieren, dass benutzerdefinierte Integritätstests an den Back-End-Adresspool gesendet werden. Wenn die folgenden Anmerkungen vorhanden sind, erstellt der Kubernetes-Eingangsdatencontroller einen benutzerdefinierten Prüfpunkt, um die Back-End-Anwendung zu überwachen. Der Controller wendet dann die Änderungen auf das Application Gateway an.
health-probe-hostname: Diese Anmerkung ermöglicht einen benutzerdefinierten Hostnamen für den Integritätstest.health-probe-port: Diese Anmerkung konfiguriert einen benutzerdefinierten Port für den Integritätstest.health-probe-path: Diese Anmerkung definiert einen Pfad für den Integritätstest.health-probe-status-code: Diese Anmerkung ermöglicht es dem Integritätstest, unterschiedliche HTTP-Statuscodes zu akzeptieren.health-probe-interval: Diese Anmerkung definiert das Intervall, in dem der Integritätstest ausgeführt wird.health-probe-timeout: Diese Anmerkung definiert, wie lange der Integritätstest auf eine Antwort wartet, bevor der Test fehlschlägt.health-probe-unhealthy-threshold: Diese Anmerkung definiert, wie viele Integritätstests fehlschlagen müssen, damit das Back-End als fehlerhaft gekennzeichnet wird.
Verbrauch
appgw.ingress.kubernetes.io/health-probe-hostname: "contoso.com"
appgw.ingress.kubernetes.io/health-probe-port: 80
appgw.ingress.kubernetes.io/health-probe-path: "/"
appgw.ingress.kubernetes.io/health-probe-status-code: "100-599"
appgw.ingress.kubernetes.io/health-probe-interval: 30
appgw.ingress.kubernetes.io/health-probe-timeout: 30
appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold: 2
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/health-probe-hostname: "contoso.com"
appgw.ingress.kubernetes.io/health-probe-port: 81
appgw.ingress.kubernetes.io/health-probe-path: "/probepath"
appgw.ingress.kubernetes.io/health-probe-status-code: "100-599"
appgw.ingress.kubernetes.io/health-probe-interval: 31
appgw.ingress.kubernetes.io/health-probe-timeout: 31
appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold: 2
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
TLS-Umleitung
Sie können Application Gateway so konfigurieren, dass HTTP-URLs automatisch an Ihre HTTPS-Entsprechungen umgeleitet werden. Wenn diese Anmerkung vorhanden ist und TLS ordnungsgemäß konfiguriert ist, erstellt der Kubernetes-Eingangsdatencontroller eine Routingregel mit einer Umleitungskonfiguration. Der Controller wendet dann die Änderungen auf Ihre Application Gateway-Instanz an. Die erstellte Umleitung ist HTTP 301 Moved Permanently.
Verbrauch
appgw.ingress.kubernetes.io/ssl-redirect: "true"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-redirect
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/ssl-redirect: "true"
spec:
tls:
- hosts:
- www.contoso.com
secretName: testsecret-tls
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Verbindungsausgleich
Verwenden Sie die folgenden Anmerkungen, wenn Sie Verbindungsausgleich verwenden möchten:
connection-draining: Diese Anmerkung gibt an, ob Verbindungsausgleich aktiviert werden soll.connection-draining-timeout: Diese Anmerkung legt ein Zeitlimit fest, nach dem Application Gateway die Anforderungen an den ausgleichenden Back-End-Endpunkt beendet.
Verbrauch
appgw.ingress.kubernetes.io/connection-draining: "true"
appgw.ingress.kubernetes.io/connection-draining-timeout: "60"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-drain
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/connection-draining: "true"
appgw.ingress.kubernetes.io/connection-draining-timeout: "60"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Cookiebasierte Affinität
Verwenden Sie die folgende Anmerkung, um Cookie-basierte Affinität zu ermöglichen.
Verbrauch
appgw.ingress.kubernetes.io/cookie-based-affinity: "true"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-affinity
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/cookie-based-affinity: "true"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Anforderungstimeout
Verwenden Sie die folgende Anmerkung, um das Anforderungszeitlimit in Sekunden anzugeben. Nach der Zeitüberschreitung schlägt Application Gateway eine Anforderung fehl, wenn die Antwort nicht empfangen wurde.
Verbrauch
appgw.ingress.kubernetes.io/request-timeout: "20"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-timeout
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/request-timeout: "20"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Verwenden einer privaten IP-Adresse
Verwenden Sie die folgenden Anmerkung, um anzugeben, ob dieser Endpunkt auf einer private IP-Adresse von Application Gateway verfügbar gemacht werden soll.
Bei einer Application Gateway-Instanz ohne private IP-Adresse werden Eingänge mit appgw.ingress.kubernetes.io/use-private-ip: "true" ignoriert. Die Controllerprotokolle und Eingangsereignisse für diese Eingänge zeigen eine Warnung NoPrivateIP an.
Verbrauch
appgw.ingress.kubernetes.io/use-private-ip: "true"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-privateip
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/use-private-ip: "true"
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Überschreiben des Front-End-Ports
Verwenden Sie die folgende Anmerkung, um einen Frontend-Listener so zu konfigurieren, dass andere Ports als 80 für HTTP und 443 für HTTPS verwendet werden.
Wenn sich der Port innerhalb des autorisierten Bereichs des Application Gateway befindet (1 bis 64999), wird der Listener für diesen spezifischen Port erstellt. Wenn Sie in der Anmerkung einen ungültigen Port oder keinen Port festlegen, verwendet die Konfiguration den Standardwert 80 oder 443.
Verbrauch
appgw.ingress.kubernetes.io/override-frontend-port: "port"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-overridefrontendport
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/override-frontend-port: "8080"
spec:
rules:
- http:
paths:
- path: /hello/
backend:
service:
name: store-service
port:
number: 80
pathType: Exact
Hinweis
Externe Anforderung müssen auf http://somehost:8080 anstelle von http://somehost zielen.
Back-End-Protokoll
Verwenden Sie folgendes, um das Protokoll anzugeben, das Application Gateway verwenden soll, wenn es mit den Pods kommuniziert. Zulässige Protokolle sind HTTP und HTTPS.
Obwohl selbstsignierte Zertifikate auf Application Gateway unterstützt werden, unterstützt AGIC derzeit nur HTTPS, wenn Pods ein Zertifikat verwenden, das von einer bekannten Zertifizierungsstelle signiert ist.
Verwenden Sie nicht Port 80 mit HTTPS und Port 443 mit HTTP für die Pods.
Verwendung
appgw.ingress.kubernetes.io/backend-protocol: "https"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-timeout
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-protocol: "https"
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 443
Hostnamenerweiterung
Sie können Application Gateway so konfigurieren, dass mehrere Hostnamen akzeptiert werden. Verwenden Sie die Anmerkung hostname-extension, um mehrere Hostnamen zu definieren, einschließlich Platzhalter-Hostnamen. Diese Aktion fügt die Hostnamen an den FQDN an, der in den Eingangsinformationen spec.rules.host des Front-End-Listeners definiert ist, sodass er als Mehrwebsite-Listener konfiguriert ist.
Verbrauch
appgw.ingress.kubernetes.io/hostname-extension: "hostname1, hostname2"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-multisite
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/hostname-extension: "hostname1, hostname2"
spec:
rules:
- host: contoso.com
http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 443
Das vorherige Beispiel konfiguriert den Listener so, dass Datenverkehr für die Hostnamen hostname1.contoso.com und hostname2.contoso.com angenommen wird.
WAF-Richtlinie für Pfad
Verwenden Sie die folgende Anmerkung, um eine vorhandene WAF (Web Application Firewall)-Richtlinie an die Listenerpfade für einen Host innerhalb einer Kubernetes-Eingangsressource anzufügen, die kommentiert wird. Die WAF-Richtlinie wird sowohl auf /ad-server- als auch /auth-URLs angewendet.
Verbrauch
appgw.ingress.kubernetes.io/waf-policy-for-path: "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/SampleRG/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/AGICWAFPolcy"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ad-server-ingress
namespace: commerce
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/waf-policy-for-path: "/subscriptions/abcd/resourceGroups/rg/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/adserver"
spec:
rules:
- http:
paths:
- path: /ad-server
backend:
service:
name: ad-server
port:
number: 80
pathType: Exact
- path: /auth
backend:
service:
name: auth-server
port:
number: 80
pathType: Exact
Application Gateway-SSL-Zertifikat
Sie können das SSL-Zertifikat für Application Gateway konfigurieren, entweder über eine lokale PFX-Zertifikatdatei oder über einen Verweis auf eine Azure Key Vault-Geheimnis-ID ohne Versionsangabe. Wenn die Anmerkung mit einem Zertifikatnamen vorhanden ist und das Zertifikat in Application Gateway vorinstalliert ist, erstellt der Kubernetes-Eingangsdatencontroller eine Routingregel mit einem HTTPS-Listener und wendet die Änderungen auf Ihre Application Gateway-Instanz an. Sie können im Falle einer SSL-Umleitung auch die Anmerkung appgw-ssl-certificate zusammen mit einer Anmerkung ssl-redirect verwenden.
Hinweis
Die Anmerkung appgw-ssl-certificate wird ignoriert, wenn die TLS-Spezifikation im Eingang gleichzeitig definiert ist. Wenn Sie unterschiedliche Zertifikate mit unterschiedlichen Hosts wünschen (Beendigung mehrerer TLS-Zertifikate), müssen Sie unterschiedliche Eingangsressourcen definieren.
Verbrauch
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-certificate
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Application Gateway-SSL-Profil
Sie können pro Listener ein SSL-Profil für die Application Gateway-Instanz konfigurieren. Wenn die Anmerkung mit einem Profilnamen vorhanden ist und das Profil im Application Gateway vorinstalliert ist, erstellt der Kubernetes-Eingangsdatencontroller eine Routingregel mit einem HTTPS-Listener und wendet die Änderungen auf Ihre Application Gateway-Instanz an.
Verbrauch
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
appgw.ingress.kubernetes.io/appgw-ssl-profile: "SampleSSLProfile"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-certificate
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
appgw.ingress.kubernetes.io/appgw-ssl-profile: "SampleSSLProfile"
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Vertrauenswürdiges Stammzertifikat für Application Gateway
Sie können jetzt Ihre eigenen Stammzertifikate für Application Gateway so konfigurieren, dass sie über AGIC als vertrauenswürdig eingestuft werden. Sie können die Anmerkung appgw-trusted-root-certificate zusammen mit der Anmerkung backend-protocol verwenden, um die End-to-End-SSL-Verschlüsselung anzugeben. Wenn Sie mehrere Stammzertifikate angeben, trennen Sie diese durch ein Komma. Beispiel: name-of-my-root-cert1,name-of-my-root-cert2.
Verbrauch
appgw.ingress.kubernetes.io/backend-protocol: "https"
appgw.ingress.kubernetes.io/appgw-trusted-root-certificate: "name-of-my-root-cert1"
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-certificate
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-protocol: "https"
appgw.ingress.kubernetes.io/appgw-trusted-root-certificate: "name-of-my-root-cert1"
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Regelsatz zum erneuten Generieren
Verwenden Sie die folgenden Anmerkung, um der entsprechenden Anforderungsroutingregel einen vorhandenen Regelsatz zum erneuten Generieren zuweisen.
Verbrauch
appgw.ingress.kubernetes.io/rewrite-rule-set: <rewrite rule set name>
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-bkprefix
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/rewrite-rule-set: add-custom-response-header
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 8080
Benutzerdefinierte Ressource für Rewrite-Regelsatz
Hinweis
Der Release von Application Gateway für Container bringt verschiedene Änderungen in den Bereichen Leistung, Resilienz und Features. Ziehen Sie den Einsatz von Application Gateway für Container für Ihre nächste Bereitstellung in Betracht.
Sie finden URL-Rewrite-Regeln für Application Gateway für Container in diesem Artikel zur Gateway-API und diesem Artikel zur Eingangs-API. Sie finden Header-Rewrite-Regeln für Application Gateway für Container in diesem Artikel zur Gateway-API.
Mit Application Gateway können Sie ausgewählten Inhalt von Anforderungen und Antworten erneut generieren. Mit diesem Feature können Sie URLs übersetzen, Abfragezeichenfolgenparameter ändern und Anforderungs- und Antwortheader ändern. Sie können dieses Feature auch verwenden, um Bedingungen hinzuzufügen, die sicherstellen, dass die URL oder die angegebenen Kopfzeilen nur dann erneut generiert werden, wenn bestimmte Bedingungen erfüllt sind. Die benutzerdefinierte Ressource für Rewrite-Regelsatz macht dieses Feature in AGIC verfügbar.
HTTP-Header ermöglichen einem Client und Server das Übergeben von zusätzlichen Informationen mit einer Anforderung oder Antwort. Durch das erneute Generieren dieser Header können Sie wichtige Aufgaben erfüllen, wie das Hinzufügen von sicherheitsbezogenen Headerfeldern (z. B. HSTS oder X-XSS-Protection), das Entfernen von Antwort-Headerfeldern, die vertrauliche Informationen preisgeben könnten, und das Entfernen von Portinformationen aus X-Forwarded-For-Headern.
Mit der URL-Rewrite-Funktionalität können Sie Folgendes tun:
- Hostnamen, Pfad und Abfragezeichenfolge der Anforderungs-URL erneut generieren.
- Wählen Sie aus, ob Sie die URL aller Anforderungen erneut generieren wollen, oder nur für Anforderungen, die einer oder mehreren von Ihnen festgelegten Bedingungen entsprechen. Diese Bedingungen basieren auf den Anforderungs- und Antworteigenschaften (Anforderungsheader, Antwortheader und Servervariablen).
- Wählen Sie aus, ob die Anforderung basierend auf der ursprünglichen URL oder der erneut generierten URL geroutet werden soll.
Hinweis
Dieses Feature wird seit 1.6.0-rc1 unterstützt. Verwenden Sie appgw.ingress.kubernetes.io/rewrite-rule-set. Dies ermöglicht die Verwendung eines vorhandenen Rewrite-Regelsatzes für Application Gateway.
Verbrauch
appgw.ingress.kubernetes.io/rewrite-rule-set-custom-resource
Beispiel
apiVersion: appgw.ingress.azure.io/v1beta1
kind: AzureApplicationGatewayRewrite
metadata:
name: my-rewrite-rule-set-custom-resource
spec:
rewriteRules:
- name: rule1
ruleSequence: 21
conditions:
- ignoreCase: false
negate: false
variable: http_req_Host
pattern: example.com
actions:
requestHeaderConfigurations:
- actionType: set
headerName: incoming-test-header
headerValue: incoming-test-value
responseHeaderConfigurations:
- actionType: set
headerName: outgoing-test-header
headerValue: outgoing-test-value
urlConfiguration:
modifiedPath: "/api/"
modifiedQueryString: "query=test-value"
reroute: false
Regelpriorität
Die folgende Anmerkung ermöglicht es dem Application Gateway-Eingangsdatencontroller, die Priorität der zugeordneten Anforderungsroutingregeln explizit festzulegen.
Verbrauch
appgw.ingress.kubernetes.io/rule-priority:
Beispiel
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-rulepriority
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/rule-priority: 10
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 8080
Im vorherigen Beispiel wird eine Priorität von 10 für die Anforderungsroutingregel festgelegt.