Teilen über

Anmerkungen für den Azure Application Gateway-Eingangscontroller

Sie können die Kubernetes-Eingangsressource mit beliebigen Schlüssel-Wert-Paaren kommentieren. Der Application Gateway-Eingangscontroller (Application Gateway Ingress Controller, AGIC) nutzt Anmerkungen zum Programmieren von Azure Application Gateway-Features, die nicht über die Eingangs-YAML konfiguriert werden können. Eingangsanmerkungen werden auf alle HTTP-Einstellungen, Back-End-Pools und Listener angewendet, die von einer Eingangsressource abgeleitet wurden.

Tipp

Ziehen Sie Application Gateway für Container für Ihre Kubernetes-Eingangslösung in Betracht. Weitere Informationen finden Sie unter Schnellstart: Bereitstellen des ALB-Controllers von Application Gateway für Container.

Liste unterstützter Anmerkungen

Damit AGIC eine Eingangsressource beobachten kann, muss die Ressource kommentiert werden. Dies muss mit kubernetes.io/ingress.class: azure/application-gateway erfolgen.

Anmerkungsschlüssel Werttyp Standardwert Zulässige Werte
appgw.ingress.kubernetes.io/backend-path-prefix string nil
appgw.ingress.kubernetes.io/backend-hostname string nil
appgw.ingress.kubernetes.io/health-probe-hostname string 127.0.0.1
appgw.ingress.kubernetes.io/health-probe-port int32 80
appgw.ingress.kubernetes.io/health-probe-path string /
appgw.ingress.kubernetes.io/health-probe-status-codes string 200-399
appgw.ingress.kubernetes.io/health-probe-interval int32 30 (Sekunden)
appgw.ingress.kubernetes.io/health-probe-timeout int32 30 (Sekunden)
appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold int32 3
appgw.ingress.kubernetes.io/ssl-redirect bool false
appgw.ingress.kubernetes.io/connection-draining bool false
appgw.ingress.kubernetes.io/connection-draining-timeout int32 (Sekunden) 30
appgw.ingress.kubernetes.io/use-private-ip bool false
appgw.ingress.kubernetes.io/override-frontend-port bool false
appgw.ingress.kubernetes.io/cookie-based-affinity bool false
appgw.ingress.kubernetes.io/request-timeout int32 (Sekunden) 30
appgw.ingress.kubernetes.io/use-private-ip bool false
appgw.ingress.kubernetes.io/backend-protocol string http http, https
appgw.ingress.kubernetes.io/hostname-extension string nil
appgw.ingress.kubernetes.io/waf-policy-for-path string nil
appgw.ingress.kubernetes.io/appgw-ssl-certificate string nil
appgw.ingress.kubernetes.io/appgw-ssl-profile string nil
appgw.ingress.kubernetes.io/appgw-trusted-root-certificate string nil
appgw.ingress.kubernetes.io/rewrite-rule-set string nil
appgw.ingress.kubernetes.io/rewrite-rule-set-custom-resource
appgw.ingress.kubernetes.io/rule-priority int32 nil

Präfix für Back-End-Pfad

Die folgende Anmerkung ermöglicht die erneute Generierung des in einer Eingangsressource angegebenen Back-End-Pfads mit dem angegebenen Präfix. Verwenden Sie dies, um Dienste bereitzustellen, deren Endpunkte sich von den Endpunkten unterscheiden, die Sie zum Bereitstellen eines Diensts in einer Eingangsressource verwenden.

Verwendung

appgw.ingress.kubernetes.io/backend-path-prefix: <path prefix>

Beispiel

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-bkprefix
  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

Im vorherigen Beispiel wird eine Eingangsressource mit dem Namen go-server-ingress-bkprefix und einer Anmerkung mit dem Namen appgw.ingress.kubernetes.io/backend-path-prefix: "/test/" definiert. Die Anmerkung weist Application Gateway an, eine HTTP-Einstellung zu erstellen, bei der es eine Außerkraftsetzung des Pfadpräfix für den Pfad /hello nach /test/ gibt.

Im Beispiel wird nur eine Regel definiert. Die Anmerkungen gelten jedoch für die gesamte Eingangsressource. Wenn Sie mehrere Regeln definieren, richten Sie das Präfix für den Back-End-Pfad für jeden angegebenen Pfad ein. Wenn Sie verschiedene Regeln mit verschiedenen Pfadpräfixen verwenden möchten (auch für den gleichen Dienst), müssen Sie verschiedene 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.

Verwendung

appgw.ingress.kubernetes.io/backend-hostname: "internal.example.com"

Beispiel

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-timeout
  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 das Anwendungsgateway so konfigurieren, dass benutzerdefinierte Gesundheitsprüfungen an den Adresspool des Backends gesendet werden. Wenn die folgenden Anmerkungen vorhanden sind, erstellt der Kubernetes-Eingangscontroller einen benutzerdefinierten Test, um die Back-End-Anwendung zu überwachen. Der Controller wendet anschließend 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-codes: Diese Anmerkung ermöglicht dem Integritätstest die Annahme verschiedener HTTP-Statuscodes.
  • 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.

Verwendung

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-codes: "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
  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-codes: "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 das Application Gateway konfigurieren, um HTTP-URLs automatisch an ihre HTTPS-Entsprechungen umzuleiten. Wenn diese Anmerkung vorhanden ist und TLS ordnungsgemäß konfiguriert ist, erstellt der Kubernetes-Eingangscontroller eine Routenplanungsregel mit einer Umleitungskonfiguration. Der Controller wendet anschließend die Änderungen auf Ihre Application Gateway-Instanz an. Die erstellte Umleitung ist HTTP 301 Moved Permanently.

Verwendung

appgw.ingress.kubernetes.io/ssl-redirect: "true"

Beispiel

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-redirect
  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 den Verbindungsausgleich verwenden möchten:

  • connection-draining: Diese Anmerkung gibt an, ob der Verbindungsausgleich aktiviert werden soll.
  • connection-draining-timeout: Diese Anmerkung gibt ein Timeout anzugeben, nach dem Application Gateway die Anforderungen an den Back-End-Ausgleichsendpunkt beendet.

Verwendung

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
  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

Verwenden Sie die folgende Anmerkung, um die Cookie-basierte Affinität zu ermöglichen.

Verwendung

appgw.ingress.kubernetes.io/cookie-based-affinity: "true"

Beispiel

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-affinity
  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

Zeitüberschreitung bei der Anforderung

Verwenden Sie die folgende Anmerkung, um das Anforderungstimeout in Sekunden anzugeben. Nach dem Timeout kennzeichnet Application Gateway eine Anforderung als fehlgeschlagen, wenn keine Antwort empfangen wurde.

Verwendung

appgw.ingress.kubernetes.io/request-timeout: "20"

Beispiel

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-timeout
  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 folgende Anmerkung, um anzugeben, ob dieser Endpunkt für private Application Gateway-IP-Adressen bereitgestellt werden soll.

Im Fall von Application Gateway-Instanzen, die nicht über eine private IP-Adresse verfügen, werden eingehende Daten mit appgw.ingress.kubernetes.io/use-private-ip: "true" ignoriert. Die Controllerprotokolle und Eingangsereignisse für diese eingehenden Daten zeigen die Warnung NoPrivateIP an.

Verwendung

appgw.ingress.kubernetes.io/use-private-ip: "true"

Beispiel

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-privateip
  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

Außerkraftsetzung des Front-End-Ports

Verwenden Sie die folgende Anmerkung, um einen Front-End-Listener für die Verwendung anderer Ports als 80 für HTTP und 443 für HTTPS zu konfigurieren.

Wenn sich der Port innerhalb des autorisierten Application Gateway-Bereichs 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 Standardport 80 oder 443.

Verwendung

appgw.ingress.kubernetes.io/override-frontend-port: "port"

Beispiel

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-overridefrontendport
  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 Anforderungen müssen an http://somehost:8080 anstelle von http://somehost gerichtet werden.

Back-End-Protokoll

Verwenden Sie Folgendes, um das Protokoll anzugeben, das Application Gateway verwenden soll, wenn es mit den Pods kommuniziert. Die unterstützten Protokolle sind HTTP und HTTPS.

Obwohl selbstsignierte Zertifikate auf Application Gateway unterstützt werden, unterstützt AGIC derzeit HTTPS nur, 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
  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 für die Annahme mehrerer Hostnamen konfigurieren. Verwenden Sie die Anmerkung hostname-extension, um mehrere Hostnamen zu definieren, einschließlich Platzhalterhostnamen. Diese Aktion fügt die Hostnamen an den FQDN an, der in den Eingangsinformationen für spec.rules.host des Front-End-Listeners definiert ist. Auf diese Weise wird er als Multisite-Listener konfiguriert.

Verwendung

appgw.ingress.kubernetes.io/hostname-extension: "hostname1, hostname2"

Beispiel

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-multisite
  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

Im vorherigen Beispiel wird der Listener für die Annahme von Datenverkehr für die Hostnamen hostname1.contoso.com und hostname2.contoso.com konfiguriert.

WAF-Richtlinie für Pfad

Verwenden Sie die folgende Anmerkung, um eine vorhandene Web Application Firewall (WAF)-Richtlinie an die Listenpfade für einen Host innerhalb einer Kubernetes-Eingangsressource anzufügen, die kommentiert wird. Die WAF-Richtlinie wird sowohl auf /ad-server- als auch auf /auth-URLs angewendet.

Verwendung

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
  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 über eine lokale PFX-Zertifikatdatei oder über einen Verweis auf eine Azure Key Vault-Geheimnis-ID ohne Versionsangabe konfigurieren. Wenn die Anmerkung einen Zertifikatnamen enthält und das Zertifikat in Application Gateway vorinstalliert ist, erstellt der Kubernetes-Eingangscontroller eine Routenplanungsregel mit einem HTTPS-Listener und wendet die Änderungen auf Ihre Application Gateway-Instanz an. Sie können im Fall einer SSL-Umleitung die appgw-ssl-certificate-Anmerkung auch zusammen mit einer ssl-redirect-Anmerkung verwenden.

Hinweis

Die appgw-ssl-certificate-Anmerkung wird ignoriert, wenn im Eingang gleichzeitig die TLS-Spezifikation definiert ist. Wenn Sie verschiedene Zertifikate für verschiedene Hosts verwenden möchten (Beendigung mehrerer TLS-Zertifikate), müssen Sie verschiedene Eingangsressourcen definieren.

Verwendung

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
  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 einen Profilnamen enthält und das Profil in Application Gateway vorinstalliert ist, erstellt der Kubernetes-Eingangscontroller eine Routenplanungsregel mit einem HTTPS-Listener und wendet die Änderungen auf Ihre Application Gateway-Instanz an.

Verwendung

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
  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 Application Gateway-Stammzertifikat

Sie können jetzt Ihre eigenen Application Gateway-Stammzertifikate so konfigurieren, dass sie über AGIC als vertrauenswürdig eingestuft werden. Sie können die appgw-trusted-root-certificate-Anmerkung zusammen mit der backend-protocol-Anmerkung verwenden, um eine End-to-End-SSL-Verschlüsselung anzugeben. Wenn Sie mehrere Stammzertifikate angeben, müssen Sie diese durch ein Komma trennen, beispielsweise name-of-my-root-cert1,name-of-my-root-cert2.

Verwendung

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
  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 folgende Anmerkung, um der entsprechenden Anforderungsroutingregel einen vorhandenen Regelsatz zum erneuten Generieren zuzuweisen.

Verwendung

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
  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 Regelsatz zum erneuten Generieren

Hinweis

Die Veröffentlichung von Application Gateway für Container führt verschiedene Änderungen in den Bereichen Leistung, Resilienz und Features ein. Sie sollten für Ihre nächste Bereitstellung die Verwendung von Application Gateway für Container in Betracht ziehen.

Sie finden die URL-Neugenerierungsregeln für Application Gateway für Container in diesem Artikel zur Gateway-API und diesem Artikel zur Eingangs-API. Sie finden die Header-Neugenerierungsregeln für Application Gateway für Container in diesem Artikel zur Gateway-API.

Mit Application Gateway können Sie ausgewählte Inhalte von Anforderungen und Antworten neu generieren. Mit diesem Feature können Sie URLs übersetzen, Zeichenfolgenparameter ändern und Anforderungs- und Antwortheader modifizieren. Sie können dieses Feature auch für das Hinzufügen von Bedingungen verwenden, um sicherzustellen, dass die URL oder die angegebenen Header nur dann neu generiert werden, wenn bestimmte Bedingungen erfüllt werden. Die benutzerdefinierte Ressource für den Regelsatz zum erneuten Generieren 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 ausführen, wie das Hinzufügen sicherheitsbezogener Headerfelder (z. B. HSTS oder X-XSS-Protection), das Entfernen von Antwortheaderfeldern, die vertrauliche Informationen offenlegen könnten, und das Entfernen von Portinformationen aus X-Forwarded-For-Headern.

Sie können mittels der URL-Rewrite-Funktion Folgendes ausführen:

  • Generieren Sie Hostname, Pfad und Abfragezeichenfolge der Anforderungs-URL neu.
  • Legen Sie fest, ob Sie die URLs aller Anforderungen oder nur die URLs von Anforderungen neu generieren möchten, die einer oder mehreren von Ihnen festgelegten Bedingungen entsprechen. Diese Bedingungen basieren auf den Anforderungs- und Antworteigenschaften (Anforderungsheader, Antwortheader und Servervariablen).
  • Legen Sie fest, ob die Anforderung basierend auf der ursprünglichen URL oder basierend auf der neu generierten URL geroutet werden soll.

Hinweis

Dieses Feature wird ab 1.6.0-rc1 unterstützt. Verwenden Sie appgw.ingress.kubernetes.io/rewrite-rule-set, was die Verwendung eines vorhandenen Rewrite-Regelsatzes für Application Gateway ermöglicht.

Verwendung

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 dem Application Gateway-Eingangscontroller die ausdrückliche Festlegung der Prioritäten der verknüpften Anforderungsroutenplanungsregeln.

Verwendung

appgw.ingress.kubernetes.io/rule-priority:

Beispiel

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-rulepriority
  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 die Priorität 10 für die Anforderungsroutenplanungsregel festgelegt.

Nächste Schritte

  • Last updated on