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:

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 -g <ResourceGroupName> -n <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.

NginxIngressController CRD verfügt über ein loadBalancerAnnotations-Feld, um das Verhalten des NGINX-Eingangsdatencontrollerdiensts zu steuern, indem Lastenausgleichsanmerkungen festgelegt werden.

Der standardmäßige NGINX-Eingangsdatencontroller

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.

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][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.