Erweiterter NGINX-Eingangsdatencontroller und Eingangskonfigurationen mit dem Add-On für Anwendungsrouting

Das Anwendungsrouting-Add-On unterstützt zwei Möglichkeiten zum Konfigurieren von Eingangsdatencontrollern und Eingangsobjekten:

• Konfiguration des NGINX-Eingangsdatencontrollers wie das Erstellen mehrerer Controller, das Konfigurieren privater Lastenausgleichsgeräte und das Festlegen statischer IP-Adressen.
• Konfiguration pro Eingangsressource über Anmerkungen.

Voraussetzungen

Ein AKS-Cluster mit dem Anwendungsrouting-Add-On

Herstellen einer Verbindung mit dem AKS-Cluster

Zum Herstellen der Verbindung mit dem Kubernetes-Cluster von Ihrem lokalen Computer aus verwenden Sie den Kubernetes-Befehlszeilenclient kubectl. Mit dem Befehl az aks install-cli können Sie ihn lokal installieren. Wenn Sie Azure Cloud Shell verwenden, ist kubectl bereits installiert.

Konfigurieren Sie kubectl, um mithilfe des az aks get-credentials-Befehls eine Verbindung mit Ihrem Kubernetes-Cluster herzustellen.

az aks get-credentials -resource-group <ResourceGroupName> --name <ClusterName>

Konfiguration des NGINX-Eingangsdatencontrollers

Das Anwendungsrouting-Add-On verwendet eine benutzerdefinierte Ressourcendefinition (CRD) namens NginxIngressController von Kubernetes, um NGINX-Eingangsdatencontroller zu konfigurieren. Sie können weitere Eingangsdatencontroller erstellen oder vorhandene Konfigurationen ändern.

Hier ist ein Verweis auf Eigenschaften, die Sie zum Konfigurieren einer NginxIngressController einstellen können.

Eigenschaft	Beschreibung
ingressClassName	Der Name des IngressClass, der für den NGINX-Eingangscontroller verwendet wird. Der Standardwert ist der Name des NginxIngressController falls nicht angegeben.
controllerNamePrefix	Ein Name, der zum Präfix der verwalteten NGINX-Eingangscontrollerressourcen verwendet wird. Wird standardmäßig auf nginx festgelegt.
loadBalancerAnnotations	Ein Satz Anmerkungen, um das Verhalten des NGINX-Eingangsdatencontrollerdiensts zu steuern, indem Lastenausgleichsanmerkungen festgelegt werden.
Skalierung	Konfigurationsoptionen für die Skalierung des NGINX-Eingangscontrollers.
scaling.minReplicas	Der untere Grenzwert für die Anzahl der Replikate des IngressControllers. Standardmäßig werden 2 Pods verwendet.
scaling.maxReplicas	Die obere Grenze für die Anzahl der Replikate des IngressControllers. Standardmäßig werden 100 Pods verwendet.
scaling.threshold	Definiert, wie schnell die NGINX Ingress Controller-Pods je nach Workload skaliert werden sollen. Rapid bedeutet, dass der Ingress Controller schnell und aggressiv skaliert wird, um plötzliche und signifikante Datenverkehrsspitzen zu verarbeiten. Steady priorisiert die Kosteneffizienz mit weniger Replikaten, die mehr Arbeit verarbeiten. Balanced ist eine gute Mischung zwischen den beiden, die für die meisten Anwendungsfälle geeignet ist. Wenn nicht angegeben, geht dieses Feld standardmäßig auf Balanced.
defaultBackendService	Der Kubernetes-Dienst, mit dem der NGINX-Eingangscontroller standardmäßig alle URL-Pfade verarbeitet und hostet, die der Ingress-NGINX-Controller nicht versteht (d. h. alle Anforderungen, die nicht einem Ingress zugeordnet sind). Der Controller leitet Datenverkehr an den ersten Port des Diensts. Wenn nicht angegeben, verwendet dies das standardmäßige Back-End, das integriert ist.
defaultBackendService.namespace	Der Namespace des Diensts.
defaultBackendService.name	Der Name des Diensts.
defaultSSLCertificate	Der geheime Schlüssel, auf den diese Eigenschaft verweist, enthält das Standardzertifikat, das beim Zugriff auf den Standard-Back-End-Dienst verwendet werden soll. Wenn diese Eigenschaft nicht bereitgestellt wird, verwendet NGINX ein selbstsigniertes Zertifikat. Wenn der tls: Abschnitt für einen Ingress nicht festgelegt ist, stellt NGINX das Standardzertifikat bereit, erzwingt jedoch keine HTTPS-Umleitung.
defaultSSLCertificate.forceSSLRedirect	Erzwingt eine Umleitung für Ingresse, die keinen tls: Abschnitt angeben.
defaultSSLCertificate.keyVaultURI	Der Azure Key Vault-URI, in dem das standardmäßige SSL-Zertifikat gefunden werden kann. Das Add-On muss für die Verwendung des Schlüsseltresors konfiguriert werden.
defaultSSLCertificate.secret	Konfiguriert den Namen und den Namespace, in dem sich der standardmäßige SSL-Schlüssel im Cluster befindet.
defaultSSLCertificate.secret.name	Name des Geheimnisses.
defaultSSLCertificate.secret.namespace	Namespace des Geheimnisses.

Häufig verwendete Konfigurationen

Steuern der Standardkonfiguration des NGINX-Eingangsdatencontrollers (Vorschau)

Hinweis

Die Steuerung der NGINX-Eingangsdatencontrollerkonfiguration beim Aktivieren des Add-Ons ist in API 2024-06-02-preview, Kubernetes-Version 1.30 oder höher, und Version 7.0.0b5 oder höher der Azure CLI-Erweiterung aks-preview verfügbar. Informationen zum Überprüfen Ihrer AKS-Clusterversion finden Sie unter Überprüfen auf verfügbare AKS-Clusterupgrades.

Wenn Sie das Anwendungsrouting-Add-On mit NGINX aktivieren, wird ein Eingangsdatencontroller namens default im app-routing-namespace erstellt, der mit einem öffentlichen Azure-Lastenausgleich konfiguriert ist. Dieser Eingangsdatencontroller verwendet einen Eingangsklassennamen von webapprouting.kubernetes.azure.com.

Sie können auch steuern, ob der Standardwert eine öffentliche oder eine interne IP erhält oder ob sie überhaupt erstellt wird, wenn das Add-On aktiviert wird.

Hier sind die möglichen Konfigurationsoptionen:

• None: Der Standardmäßige Nginx-Eingangscontroller wird nicht erstellt und wird nicht gelöscht, wenn er bereits vorhanden ist. Benutzer sollten die benutzerdefinierte Standardressource NginxIngressController bei Bedarf manuell löschen.
• Internal: Der Standardmäßige Nginx-Eingangscontroller wird mit einem internen Lastenausgleich erstellt. Alle Anmerkungen ändern sich in der NginxIngressController benutzerdefinierten Ressource, um sie extern zu machen, werden überschrieben.
• External: Der standardmäßige Nginx-Eingangscontroller, der mit einem externen Lastenausgleich erstellt wurde. Alle Anmerkungen für die NginxIngressController benutzerdefinierte Ressource, um sie intern zu machen, werden überschrieben.
• AnnotationControlled (Standard): Der Standardmäßige Nginx-Eingangscontroller wird mit einem externen Lastenausgleich erstellt. Benutzer können die benutzerdefinierte Standardressource NginxIngressController bearbeiten, um Anmerkungen zum Lastenausgleich zu konfigurieren.

Azure-Befehlszeilenschnittstelle

Steuern der Standardkonfiguration des Eingangsdatencontrollers beim Erstellen des Clusters

Um das Anwendungsrouting in einem neuen Cluster zu aktivieren, verwenden Sie den Befehl az aks create und geben Sie die Flags --enable-app-routing und --app-routing-default-nginx-controller an. Sie müssen den <DefaultIngressControllerType> auf eine der zuvor beschriebenen Konfigurationsoptionen festlegen.

az aks create \
--resource-group <ResourceGroupName> \
--name <ClusterName> \
--location <Location> \
--enable-app-routing \
--app-routing-default-nginx-controller <DefaultIngressControllerType>

Aktualisieren der Standardkonfiguration des Eingangsdatencontrollers auf einem vorhandenen Cluster

Um die Standardkonfiguration des Eingangsdatencontrollers für das Anwendungsrouting in einem vorhandenen Cluster zu aktualisieren, verwenden Sie den Befehl az aks approuting update, und geben Sie das Flag --nginx an. Sie müssen den <DefaultIngressControllerType> auf eine der zuvor beschriebenen Konfigurationsoptionen festlegen.

az aks approuting update --resource-group <ResourceGroupName> --name <ClusterName> --nginx <DefaultIngressControllerType>

Bicep

Das webAppRouting Profil verfügt über eine optionale nginx Konfiguration mit einer defaultIngressControllerType Eigenschaft. Sie müssen die Eigenschaft defaultIngressControllerType auf eine der zuvor beschriebenen Konfigurationsoptionen festlegen.

"ingressProfile": {
  "webAppRouting": {
    "nginx": {
        "defaultIngressControllerType": "None|Internal|External|AnnotationControlled"
    }
}

Erstellen eines weiteren öffentlich zugänglichen NGINX-Eingangsdatencontrollers

So erstellen Sie einen anderen NGINX-Eingangsdatencontroller mit einem öffentlich zugänglichen Azure Load Balancer:

1. Kopieren Sie das folgende YAML-Manifest in eine neue Datei namens nginx-public-controller.yaml, und speichern Sie die Datei auf Ihrem lokalen Computer.

   apiVersion: approuting.kubernetes.azure.com/v1alpha1
   kind: NginxIngressController
   metadata:
     name: nginx-public
   spec:
     ingressClassName: nginx-public
     controllerNamePrefix: nginx-public
   

2. Erstellen Sie die Ressourcen des NGINX-Eingangsdatencontrollers mithilfe des Befehls kubectl apply.

   kubectl apply -f nginx-public-controller.yaml
   

   In der folgenden Beispielausgabe sehen Sie die erstellten Ressourcen:

   nginxingresscontroller.approuting.kubernetes.azure.com/nginx-public created
   

Erstellen eines internen NGINX-Eingangsdatencontrollers mit einer privaten IP-Adresse

So erstellen Sie einen NGINX-Eingangsdatencontroller mit einem internen Azure Load Balancer mit einer privaten IP-Adresse:

1. Kopieren Sie das folgende YAML-Manifest in eine neue Datei namens nginx-internal-controller.yaml, und speichern Sie die Datei auf Ihrem lokalen Computer.

   apiVersion: approuting.kubernetes.azure.com/v1alpha1
   kind: NginxIngressController
   metadata:
     name: nginx-internal
   spec:
     ingressClassName: nginx-internal
     controllerNamePrefix: nginx-internal
     loadBalancerAnnotations: 
       service.beta.kubernetes.io/azure-load-balancer-internal: "true"
   

2. Erstellen Sie die Ressourcen des NGINX-Eingangsdatencontrollers mithilfe des Befehls kubectl apply.

   kubectl apply -f nginx-internal-controller.yaml
   

   In der folgenden Beispielausgabe sehen Sie die erstellten Ressourcen:

   nginxingresscontroller.approuting.kubernetes.azure.com/nginx-internal created
   

Erstellen eines NGINX-Eingangsdatencontrollers mit einer statischen IP-Adresse

So ersten Sie einen NGINX-Eingangsdatencontroller mit einer statischen IP-Adresse im Azure Load Balancer:

1. Erstellen Sie mithilfe des Befehls az group create eine Azure-Ressourcengruppe.

   az group create --name myNetworkResourceGroup --location eastus
   

2. Verwenden Sie den Befehl az network public ip create, um eine statische öffentliche IP-Adresse zu erstellen.

   az network public-ip create \
       --resource-group myNetworkResourceGroup \
       --name myIngressPublicIP \
       --sku Standard \
       --allocation-method static
   

   Hinweis

   Wenn Sie in Ihrem AKS-Cluster einen Lastenausgleich der SKU Basic verwenden, verwenden Sie die Option Basic für den Parameter --sku, wenn Sie eine öffentliche IP-Adresse definieren. Mit dem Lastenausgleich der SKU Basic können nur IP-Adressen der SKU Basic verwendet werden. Analog dazu können mit einem Lastenausgleich der SKU Standard nur IP-Adressen der SKU Standard verwendet werden.

3. Verwenden Sie den Befehl az role assignment create, um sicherzustellen, dass die vom AKS-Cluster verwendete Clusteridentität über delegierte Berechtigungen für die öffentliche IP-Adresse der Ressourcengruppe verfügt.

   Hinweis

   Aktualisieren Sie <ClusterName> und <ClusterResourceGroup> mit dem Namen und dem Ressourcengruppennamen Ihres AKS-Clusters.

   CLIENT_ID=$(az aks show --name <ClusterName> --resource-group <ClusterResourceGroup> --query identity.principalId -o tsv)
   RG_SCOPE=$(az group show --name myNetworkResourceGroup --query id -o tsv)
   az role assignment create \
       --assignee ${CLIENT_ID} \
       --role "Network Contributor" \
       --scope ${RG_SCOPE}
   

4. Kopieren Sie das folgende YAML-Manifest in eine neue Datei namens nginx-staticip-controller.yaml, und speichern Sie die Datei auf Ihrem lokalen Computer.

   Hinweis

   Sie können entweder service.beta.kubernetes.io/azure-pip-name für eine öffentliche IP-Adresse oder service.beta.kubernetes.io/azure-load-balancer-ipv4 für eine IPv4-Adresse und service.beta.kubernetes.io/azure-load-balancer-ipv6 für eine IPv6-Adresse verwenden, wie im YAML-Beispielcode gezeigt. Das Hinzufügen der service.beta.kubernetes.io/azure-pip-name Anmerkung gewährleistet die effizienteste LoadBalancer-Erstellung und wird dringend empfohlen, um eine potenzielle Drosselung zu vermeiden.

   apiVersion: approuting.kubernetes.azure.com/v1alpha1
   kind: NginxIngressController
   metadata:
     name: nginx-static
   spec:
     ingressClassName: nginx-static
     controllerNamePrefix: nginx-static
     loadBalancerAnnotations: 
       service.beta.kubernetes.io/azure-pip-name: "myIngressPublicIP"
       service.beta.kubernetes.io/azure-load-balancer-resource-group: "myNetworkResourceGroup"
   

5. Erstellen Sie die Ressourcen des NGINX-Eingangsdatencontrollers mithilfe des Befehls kubectl apply.

   kubectl apply -f nginx-staticip-controller.yaml
   

   In der folgenden Beispielausgabe sehen Sie die erstellten Ressourcen:

   nginxingresscontroller.approuting.kubernetes.azure.com/nginx-static created
   

Überprüfen, ob der Eingangsdatencontroller erstellt wurde

Sie können den Status der NGINX-Eingangsdatencontroller mit dem Befehl kubectl get nginxingresscontroller überprüfen.

Hinweis

Aktualisieren Sie <IngressControllerName> mit dem Namen, den Sie beim Erstellen des "NginxIngressController" verwendet haben.

kubectl get nginxingresscontroller -n <IngressControllerName>

In der folgenden Beispielausgabe sehen Sie die erstellte Ressource. Es kann einige Minuten dauern, bis der Controller verfügbar ist.

NAME           INGRESSCLASS   CONTROLLERNAMEPREFIX   AVAILABLE
nginx-public   nginx-public   nginx                  True

Sie können auch die Bedingungen anzeigen, um Probleme zu beheben:

kubectl get nginxingresscontroller -n <IngressControllerName> -o jsonpath='{range .items[*].status.conditions[*]}{.lastTransitionTime}{"\t"}{.status}{"\t"}{.type}{"\t"}{.message}{"\n"}{end}'

Die folgende Beispielausgabe zeigt die Bedingungen eines fehlerfreien Eingangscontrollers:

2023-11-29T19:59:24Z    True    IngressClassReady       Ingress Class is up-to-date
2023-11-29T19:59:50Z    True    Available               Controller Deployment has minimum availability and IngressClass is up-to-date
2023-11-29T19:59:50Z    True    ControllerAvailable     Controller Deployment is available
2023-11-29T19:59:25Z    True    Progressing             Controller Deployment has successfully progressed

Verwenden des Eingangsdatencontrollers in einem Eingang

1. Kopieren Sie das folgende YAML-Manifest in eine neue Datei namens ingress.yaml, und speichern Sie die Datei auf Ihrem lokalen Computer.

   Hinweis

   Aktualisieren Sie <Hostname> mit Ihrem DNS-Hostnamen. Der <IngressClassName> ist der, den Sie beim Erstellen des NginxIngressController definiert haben.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: aks-helloworld
     namespace: hello-web-app-routing
   spec:
     ingressClassName: <IngressClassName>
     rules:
     - host: <Hostname>
       http:
         paths:
         - backend:
             service:
               name: aks-helloworld
               port:
                 number: 80
           path: /
           pathType: Prefix
   

2. Erstellen Sie die Clusterressourcen mithilfe des Befehls kubectl apply.

   kubectl apply -f ingress.yaml -n hello-web-app-routing
   

   In der folgenden Beispielausgabe sehen Sie die erstellten Ressourcen:

   ingress.networking.k8s.io/aks-helloworld created
   

Überprüfen, ob der verwaltete Eingang erstellt wurde

Überprüfen Sie mithilfe des Befehls kubectl get ingress, ob der verwaltete Eingang erstellt wurde.

kubectl get ingress -n hello-web-app-routing

Die folgende Beispielausgabe zeigt den erstellten verwalteten Eingang. Die Eingangsklasse, der Host und die IP-Adresse können unterschiedlich sein:

NAME             CLASS                                HOSTS               ADDRESS       PORTS     AGE
aks-helloworld   webapprouting.kubernetes.azure.com   myapp.contoso.com   20.51.92.19   80, 443   4m

Bereinigen des Eingangsdatencontrollers

Sie können den NGINX-Eingangsdatencontroller mithilfe des Befehls kubectl delete nginxingresscontroller entfernen.

Hinweis

Aktualisieren Sie <IngressControllerName> mit dem Namen, den Sie beim Erstellen des NginxIngressController verwendet haben.

kubectl delete nginxingresscontroller -n <IngressControllerName>

Konfiguration pro Eingangsressource über Anmerkungen

Der NGINX-Eingangscontroller unterstützt das Hinzufügen von Anmerkungen zu bestimmten Ingressobjekten zum Anpassen ihres Verhaltens.

Sie können Anmerkungen an das Eingangsobjekt anzufügen, indem Sie die entsprechende Anmerkung im Feld metadata.annotations hinzufügen.

Hinweis

Anmerkungsschlüssel und -werte können nur Zeichenfolgen sein. Andere Typen, z. B. boolesche oder numerische Werte, müssen in Anführungszeichen eingeschlossen werden, d. h. "true", "false", "100".

Im Folgenden finden Sie einige Beispiele von Anmerkungen für allgemeine Konfigurationen. Lesen Sie die Dokumentation zu NGINX-Eingangsanmerkungen für eine vollständige Liste.

Benutzerdefinierte max. Textkörpergröße

Bei NGINX wird ein 413-Fehler an den Client zurückgegeben, wenn die Größe in einer Anforderung die maximal zulässige Größe des Clientanforderungstexts überschreitet. Verwenden Sie zum Überschreiben des Standardwerts die Anmerkung:

nginx.ingress.kubernetes.io/proxy-body-size: 4m

Hier ist ein Beispiel für die Eingangskonfiguration mit dieser Anmerkung:

Hinweis

Aktualisieren Sie <Hostname> mit Ihrem DNS-Hostnamen. Der <IngressClassName> ist der, den Sie beim Erstellen des NginxIngressController definiert haben.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 4m
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <Hostname>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

Benutzerdefiniertes Verbindungstimeout

Sie können die Zeitspanne (das Timeout) ändern, die der NGINX-Eingangsdatencontroller wartet, um eine Verbindung mit Ihrer Arbeitslast zu schließen. Alle Timeoutwerte sind einheitslos und in Sekunden angegeben. Verwenden Sie zum Überschreiben des Standardtimeouts die folgende Anmerkung, um ein gültiges 120-Sekunden-Proxy-Lesetimeout festzulegen:

nginx.ingress.kubernetes.io/proxy-read-timeout: "120"

Sehen Sie sich benutzerdefinierten Timeouts für andere Konfigurationsoptionen an.

Hier ist ein Beispiel für die Eingangskonfiguration mit dieser Anmerkung:

Hinweis

Aktualisieren Sie <Hostname> mit Ihrem DNS-Hostnamen. Der <IngressClassName> ist der, den Sie beim Erstellen des NginxIngressController definiert haben.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <Hostname>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

Back-End-Protokoll

Standardmäßig verwendet der NGINX-Eingangsdatencontroller HTTP, um die Dienste zu erreichen. Verwenden Sie die Anmerkung, um alternative Back-End-Protokolle wie HTTPS oder GRPC zu konfigurieren:

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

oder

nginx.ingress.kubernetes.io/backend-protocol: "GRPC"

Sehen Sie sich Back-End-Protokolle für andere Konfigurationsoptionen an.

Hier ist ein Beispiel für die Eingangskonfiguration mit dieser Anmerkung:

Hinweis

Aktualisieren Sie <Hostname> mit Ihrem DNS-Hostnamen. Der <IngressClassName> ist der, den Sie beim Erstellen des NginxIngressController definiert haben.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <Hostname>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

Ressourcenfreigabe zwischen verschiedenen Ursprüngen (CORS)

Verwenden Sie die Anmerkung, um die ursprungsübergreifende Ressourcenfreigabe (Cross-Origin Resource Sharing, CORS) in einer Eingangsregel zu aktivieren:

nginx.ingress.kubernetes.io/enable-cors: "true"

Sehen Sie sich Aktivieren von CORS für andere Konfigurationsoptionen an.

Hier ist ein Beispiel für die Eingangskonfiguration mit dieser Anmerkung:

Hinweis

Aktualisieren Sie <Hostname> mit Ihrem DNS-Hostnamen. Der <IngressClassName> ist der, den Sie beim Erstellen des NginxIngressController definiert haben.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/enable-cors: "true"
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <Hostname>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

SSL-Umleitung deaktivieren

Standardmäßig leitet der Controller (308) zu HTTPS um, wenn TLS für einen Eingang aktiviert ist. Um dieses Feature für bestimmte Eingangsressourcen zu deaktivieren, verwenden Sie die Anmerkung:

nginx.ingress.kubernetes.io/ssl-redirect: "false"

Sehen Sie sich serverseitige HTTPS-Erzwingung durch Umleitung für weitere Konfigurationsoptionen an.

Hier ist ein Beispiel für die Eingangskonfiguration mit dieser Anmerkung:

Hinweis

Aktualisieren Sie <Hostname> mit Ihrem DNS-Hostnamen. Der <IngressClassName> ist der, den Sie beim Erstellen des NginxIngressController definiert haben.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <Hostname>
    http:
      paths:
      - backend:
          service:
            name: aks-helloworld
            port:
              number: 80
        path: /
        pathType: Prefix

URL-Umschreibung

In einigen Szenarien unterscheidet sich die verfügbar gemachte URL im Back-End-Dienst vom angegebenen Pfad in der Eingangsregel. Ohne erneutes Schreiben einer Anforderung wird 404 zurückgegeben. Dies ist besonders hilfreich bei pfadbasiertem Routing, bei dem Sie zwei verschiedene Webanwendungen unter derselben Domäne bedienen können. Sie können den vom Dienst erwarteten Pfad mithilfe dieser Anmerkung festlegen:

nginx.ingress.kubernetes.io/rewrite-target": /$2

Hier ist ein Beispiel für die Eingangskonfiguration mit dieser Anmerkung:

Hinweis

Aktualisieren Sie <Hostname> mit Ihrem DNS-Hostnamen. Der <IngressClassName> ist der, den Sie beim Erstellen des NginxIngressController definiert haben.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aks-helloworld
  namespace: hello-web-app-routing
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: <IngressClassName>
  rules:
  - host: <Hostname>
    http:
      paths:
      - path: /app-one(/|$)(.*)
        pathType: Prefix 
        backend:
          service:
            name: app-one
            port:
              number: 80
      - path: /app-two(/|$)(.*)
        pathType: Prefix 
        backend:
          service:
            name: app-two
            port:
              number: 80

Nächste Schritte

Erfahren Sie mehr über die Überwachung der Metriken des nginx-Eingangsdatencontrollers, die im Anwendungsrouting-Add-On enthalten sind, mit Prometheus in Grafana beim Analysieren der Leistung und Nutzung Ihrer Anwendung.