Share via


Geavanceerde NGINX-ingangscontroller- en toegangsbeheerobjectconfiguraties met de invoegtoepassing voor toepassingsroutering

De invoegtoepassing voor toepassingsroutering ondersteunt twee manieren om toegangsbeheerobjecten en inkomende objecten te configureren:

Vereisten

Een AKS-cluster met de invoegtoepassing voor toepassingsroutering.

Verbinding maken met uw AKS-cluster

Als u vanaf uw lokale computer verbinding wilt maken met het Kubernetes-cluster, gebruikt kubectlu de Kubernetes-opdrachtregelclient. U kunt deze lokaal installeren met behulp van de opdracht az aks install-cli . Als u Azure Cloud Shell gebruikt, is kubectl al geïnstalleerd.

Configureer kubectl om verbinding te maken met uw Kubernetes-cluster met behulp van de az aks get-credentials opdracht.

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

Configuratie van de NGINX-ingangscontroller

De invoegtoepassing voor toepassingsroutering maakt gebruik van een aangepaste Kubernetes-resourcedefinitie (CRD) die wordt aangeroepen NginxIngressController om NGINX-ingangscontrollers te configureren. U kunt meer ingangscontrollers maken of bestaande configuratie wijzigen.

Hier volgt een verwijzing naar eigenschappen die u kunt instellen om een NginxIngressController.

Eigenschappen Beschrijving
ingressClassName De naam van de IngressClass naam die wordt gebruikt voor de NGINX-ingangscontroller. De standaardwaarde is de naam van de NginxIngressController indien niet opgegeven.
controllerNamePrefix Een naam die wordt gebruikt voor het voorvoegsel van de beheerde NGINX-controllerbronnen voor inkomend verkeer. Standaard ingesteld op nginx.
loadBalancerAnnotations Een set aantekeningen om het gedrag van de service van de NGINX-ingangscontroller te beheren door load balancer-aantekeningen in te stellen
Schalen Configuratieopties voor de schaal van de NGINX-ingangscontroller.
scaling.minReplicas De ondergrens voor het aantal ingangscontrollerreplica's. De standaardwaarde is 2 pods.
scaling.maxReplicas De bovengrens voor het aantal ingangscontrollerreplica's. De standaardwaarde is 100 pods.
scaling.threshold Definieert hoe snel de NGINX Controller-pods voor inkomend verkeer moeten worden geschaald op basis van de workload. Rapid betekent dat de ingangscontroller snel en agressief wordt geschaald voor het verwerken van plotselinge en significante verkeerspieken. Steady prioriteit geeft aan kosteneffectiviteit, waarbij minder replica's meer werk verwerken. Balanced is een goede mix tussen de twee die geschikt zijn voor de meeste gebruiksvoorbeelden. Als dit veld niet is opgegeven, wordt dit veld standaard ingesteld op Balanced.
defaultBackendService De Kubernetes-service die de NGINX-ingangscontroller standaard moet instellen voor het verwerken van alle URL-paden en als host fungeert voor de controller Inkomend-NGINX(d.w.v. alle aanvragen die niet zijn toegewezen met inkomend verkeer). De controller stuurt verkeer door naar de eerste poort van de service. Als dit niet is opgegeven, wordt de standaardback-end gebruikt die is ingebouwd.
defaultBackendService.namespace Naamruimte van de service.
defaultBackendService.name Naam van de service.
defaultSSLCertificate Het geheim waarnaar wordt verwezen door deze eigenschap bevat het standaardcertificaat dat moet worden gebruikt bij het openen van de standaardback-endservice. Als deze eigenschap niet is opgegeven, gebruikt NGINX een zelfondertekend certificaat. Als de tls: sectie niet is ingesteld voor inkomend verkeer, geeft NGINX het standaardcertificaat op, maar wordt HTTPS-omleiding niet afgedwongen.
defaultSSLCertificate.forceSSLRedirect Hiermee dwingt u een omleiding af voor Ingresses die geen sectie opgeven tls: .
defaultSSLCertificate.keyVaultURI De Azure Key Vault-URI waar het standaard-SSL-certificaat kan worden gevonden. De invoegtoepassing moet worden geconfigureerd voor het gebruik van de sleutelkluis.
defaultSSLCertificate.secret Hiermee configureert u de naam en naamruimte waar het standaard-SSL-geheim zich in het cluster bevindt.
defaultSSLCertificate.secret.name Naam van het geheim.
defaultSSLCertificate.secret.namespace Naamruimte van het geheim.

Algemene configuraties

De standaardconfiguratie van de NGINX-ingangscontroller beheren (preview)

Notitie

Het beheren van de NGINX-controllerconfiguratie voor inkomend verkeer bij het inschakelen van de invoegtoepassing is beschikbaar in API 2024-06-02-previewKubernetes versie 1.30 of hoger en de versie van de Azure CLI-extensie 7.0.0b5 aks-preview of hoger. Zie Controleren op beschikbare AKS-clusterupgrades om de versie van uw AKS-cluster te controleren.

Wanneer u de invoegtoepassing voor toepassingsroutering inschakelt met NGINX, wordt er een ingangscontroller gemaakt die is aangeroepen default in de app-routing-namespace geconfigureerde met een openbare Azure Load Balancer. Deze ingangscontroller maakt gebruik van de naam van de klasse Inkomend verkeer van webapprouting.kubernetes.azure.com.

U kunt ook bepalen of de standaardinstelling een openbaar of intern IP-adres krijgt, of of deze helemaal wordt gemaakt bij het inschakelen van de invoegtoepassing.

Hier volgen de mogelijke configuratieopties:

  • None: De standaard Nginx-ingangscontroller wordt niet gemaakt en wordt niet verwijderd als deze al bestaat. Gebruikers moeten desgewenst de standaard NginxIngressController aangepaste resource handmatig verwijderen.
  • Internal: De standaard Nginx-ingangscontroller wordt gemaakt met een interne load balancer. Eventuele wijzigingen in aantekeningen in de NginxIngressController aangepaste resource om deze extern te maken, worden overschreven.
  • External: De standaard Nginx-ingangscontroller die is gemaakt met een externe load balancer. Eventuele wijzigingen in aantekeningen in de NginxIngressController aangepaste resource om deze intern te maken, worden overschreven.
  • AnnotationControlled (standaard): De standaard Nginx-ingangscontroller wordt gemaakt met een externe load balancer. Gebruikers kunnen de standaard NginxIngressController aangepaste resource bewerken om aantekeningen van load balancers te configureren.

De standaardconfiguratie van de ingangscontroller beheren bij het maken van het cluster

Als u toepassingsroutering op een nieuw cluster wilt inschakelen, gebruikt u de az aks create opdracht, waarbij u de --enable-app-routing en de --app-routing-default-nginx-controller vlaggen opgeeft. U moet de <DefaultIngressControllerType> configuratieopties instellen die eerder zijn beschreven.

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

De standaardconfiguratie voor inkomend verkeer op een bestaand cluster bijwerken

Als u de standaardconfiguratie van de ingangscontroller voor toepassingsroutering op een bestaand cluster wilt bijwerken, gebruikt u de az aks approuting update opdracht en geeft u de --nginx vlag op. U moet de <DefaultIngressControllerType> configuratieopties instellen die eerder zijn beschreven.

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

Een andere openbare NGINX-ingangscontroller maken

Een andere NGINX-ingangscontroller maken met een openbare Azure Load Balancer:

  1. Kopieer het volgende YAML-manifest naar een nieuw bestand met de naam nginx-public-controller.yaml en sla het bestand op uw lokale computer op.

    apiVersion: approuting.kubernetes.azure.com/v1alpha1
    kind: NginxIngressController
    metadata:
      name: nginx-public
    spec:
      ingressClassName: nginx-public
      controllerNamePrefix: nginx-public
    
  2. Maak de NGINX-controllerbronnen voor inkomend verkeer met behulp van de kubectl apply opdracht.

    kubectl apply -f nginx-public-controller.yaml
    

    In de volgende voorbeelduitvoer ziet u de gemaakte resource:

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

Een interne NGINX-ingangscontroller maken met een privé-IP-adres

Een NGINX-ingangscontroller maken met een interne Azure Load Balancer met een privé-IP-adres:

  1. Kopieer het volgende YAML-manifest naar een nieuw bestand met de naam nginx-internal-controller.yaml en sla het bestand op uw lokale computer op.

    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. Maak de NGINX-controllerbronnen voor inkomend verkeer met behulp van de kubectl apply opdracht.

    kubectl apply -f nginx-internal-controller.yaml
    

    In de volgende voorbeelduitvoer ziet u de gemaakte resource:

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

Een NGINX-ingangscontroller maken met een statisch IP-adres

Een NGINX-ingangscontroller maken met een statisch IP-adres op de Azure Load Balancer:

  1. Maak een Azure-resourcegroep met behulp van de az group create opdracht.

    az group create --name myNetworkResourceGroup --location eastus
    
  2. Maak een statisch openbaar IP-adres met behulp van de az network public ip create opdracht.

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

    Notitie

    Als u een Basic SKU-load balancer in uw AKS-cluster gebruikt, gebruikt u Basic voor de parameter bij het --sku definiëren van een openbaar IP-adres. Alleen Basic SKU-IP's werken met de Load Balancer basic SKU en alleen Standard SKU-IP's werken met Standard SKU-load balancers.

  3. Zorg ervoor dat de clusteridentiteit die door het AKS-cluster wordt gebruikt, gedelegeerde machtigingen heeft voor de resourcegroep van het openbare IP-adres met behulp van de az role assignment create opdracht.

    Notitie

    Werk <ClusterName> de <ClusterResourceGroup> naam en resourcegroepnaam van uw AKS-cluster bij.

    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. Kopieer het volgende YAML-manifest naar een nieuw bestand met de naam nginx-staticip-controller.yaml en sla het bestand op uw lokale computer op.

    Notitie

    U kunt deze gebruiken service.beta.kubernetes.io/azure-pip-name voor een openbare IP-naam of voor service.beta.kubernetes.io/azure-load-balancer-ipv4 een IPv4-adres en service.beta.kubernetes.io/azure-load-balancer-ipv6 voor een IPv6-adres, zoals wordt weergegeven in het voorbeeld van YAML. Het toevoegen van de service.beta.kubernetes.io/azure-pip-name aantekening zorgt ervoor dat de meest efficiënte LoadBalancer wordt gemaakt en wordt ten zeerste aanbevolen om mogelijke beperking te voorkomen.

    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. Maak de NGINX-controllerbronnen voor inkomend verkeer met behulp van de kubectl apply opdracht.

    kubectl apply -f nginx-staticip-controller.yaml
    

    In de volgende voorbeelduitvoer ziet u de gemaakte resource:

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

Controleren of de ingangscontroller is gemaakt

U kunt de status van de NGINX-ingangscontroller controleren met behulp van de kubectl get nginxingresscontroller opdracht.

Notitie

Werk <IngressControllerName> bij met de naam die u hebt gebruikt bij het maken van de 'NginxIngressController'.

kubectl get nginxingresscontroller -n <IngressControllerName>

In de volgende voorbeelduitvoer ziet u de gemaakte resource. Het kan enkele minuten duren voordat de controller beschikbaar is:

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

U kunt ook de voorwaarden bekijken om eventuele problemen op te lossen:

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

In de volgende voorbeelduitvoer ziet u de voorwaarden van een controller voor inkomend verkeer in orde:

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

De ingangscontroller gebruiken in een inkomend verkeer

  1. Kopieer het volgende YAML-manifest naar een nieuw bestand met de naam ingress.yaml en sla het bestand op uw lokale computer op.

    Notitie

    Werk <Hostname> bij met uw DNS-hostnaam. Het <IngressClassName> is degene die u hebt gedefinieerd bij het maken van de NginxIngressController.

    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. Maak de clusterbronnen met behulp van de kubectl apply opdracht.

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

    In de volgende voorbeelduitvoer ziet u de gemaakte resource:

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

Controleren of het beheerde inkomend verkeer is gemaakt

U kunt controleren of het beheerde inkomend verkeer is gemaakt met behulp van de kubectl get ingress opdracht.

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

In de volgende voorbeelduitvoer ziet u het gemaakte beheerde inkomend verkeer. De ingangsklasse, host en IP-adres kunnen afwijken:

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

Toegangsbeheerobjectcontrollers opschonen

U kunt de NGINX-ingangscontroller verwijderen met behulp van de kubectl delete nginxingresscontroller opdracht.

Notitie

Werk <IngressControllerName> bij met de naam die u hebt gebruikt bij het maken van de NginxIngressController.

kubectl delete nginxingresscontroller -n <IngressControllerName>

Resource per inkomend verkeer configureren via aantekeningen

De NGINX-ingangscontroller biedt ondersteuning voor het toevoegen van aantekeningen aan specifieke objecten voor inkomend verkeer om hun gedrag aan te passen.

U kunt aantekeningen toevoegen aan het inkomende object door de respectieve aantekening toe te voegen in het metadata.annotations veld.

Notitie

Aantekeningssleutels en -waarden kunnen alleen tekenreeksen zijn. Andere typen, zoals Booleaanse waarden of numerieke waarden, moeten worden geciteerd, bijvoorbeeld "true", "false". "100"

Hier volgen enkele voorbeelden van aantekeningen voor algemene configuraties. Raadpleeg de documentatie voor aantekeningen voor inkomend verkeer van NGINX voor een volledige lijst.

Aangepaste maximale grootte van hoofdtekst

Voor NGINX wordt een 413-fout geretourneerd naar de client wanneer de grootte in een aanvraag groter is dan de maximaal toegestane grootte van de hoofdtekst van de clientaanvraag. Als u de standaardwaarde wilt overschrijven, gebruikt u de aantekening:

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

Hier volgt een voorbeeld van een configuratie voor inkomend verkeer met behulp van deze aantekening:

Notitie

Werk <Hostname> bij met uw DNS-hostnaam. Het <IngressClassName> is degene die u hebt gedefinieerd bij het maken van de NginxIngressController.

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

Aangepaste verbindingstime-out

U kunt de time-out wijzigen waarop de NGINX-ingangscontroller wacht om een verbinding met uw workload te sluiten. Alle time-outwaarden zijn eenheidsloos en in seconden. Als u de standaardtime-out wilt overschrijven, gebruikt u de volgende aantekening om een geldige time-out voor lezen van de proxy van 120 seconden in te stellen:

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

Bekijk aangepaste time-outs voor andere configuratieopties.

Hier volgt een voorbeeld van een configuratie voor inkomend verkeer met behulp van deze aantekening:

Notitie

Werk <Hostname> bij met uw DNS-hostnaam. Het <IngressClassName> is degene die u hebt gedefinieerd bij het maken van de NginxIngressController.

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

Protocol van back-end

Standaard gebruikt HTTP de NGINX-ingangscontroller om de services te bereiken. Als u alternatieve back-endprotocollen zoals HTTPS of GRPCwilt configureren, gebruikt u de aantekening:

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

or

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

Bekijk back-endprotocollen voor andere configuratieopties.

Hier volgt een voorbeeld van een configuratie voor inkomend verkeer met behulp van deze aantekening:

Notitie

Werk <Hostname> bij met uw DNS-hostnaam. Het <IngressClassName> is degene die u hebt gedefinieerd bij het maken van de NginxIngressController.

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

Cross-Origin Resource Sharing (CORS)

Als u CROSS-Origin Resource Sharing (CORS) wilt inschakelen in een regel voor inkomend verkeer, gebruikt u de aantekening:

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

Controleer cors inschakelen voor andere configuratieopties.

Hier volgt een voorbeeld van een configuratie voor inkomend verkeer met behulp van deze aantekening:

Notitie

Werk <Hostname> bij met uw DNS-hostnaam. Het <IngressClassName> is degene die u hebt gedefinieerd bij het maken van de NginxIngressController.

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

Standaard wordt de controller omgeleid (308) naar HTTPS als TLS is ingeschakeld voor een inkomend verkeer. Als u deze functie wilt uitschakelen voor specifieke toegangsbeheerobjectbronnen, gebruikt u de aantekening:

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

Controleer https-afdwinging aan de serverzijde via omleiding voor andere configuratieopties.

Hier volgt een voorbeeld van een configuratie voor inkomend verkeer met behulp van deze aantekening:

Notitie

Werk <Hostname> bij met uw DNS-hostnaam. Het <IngressClassName> is degene die u hebt gedefinieerd bij het maken van de NginxIngressController.

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 herschrijven

In sommige scenario's verschilt de weergegeven URL in de back-endservice van het opgegeven pad in de regel Inkomend verkeer. Zonder herschrijven retourneert een aanvraag 404. Deze configuratie is handig met padgebaseerde routering , waar u twee verschillende webtoepassingen onder hetzelfde domein kunt leveren. U kunt het pad instellen dat door de service wordt verwacht met behulp van de aantekening:

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

Hier volgt een voorbeeld van een configuratie voor inkomend verkeer met behulp van deze aantekening:

Notitie

Werk <Hostname> bij met uw DNS-hostnaam. Het <IngressClassName> is degene die u hebt gedefinieerd bij het maken van de NginxIngressController.

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

Volgende stappen

Meer informatie over het bewaken van de metrische gegevens voor inkomend-nginx-controller die deel uitmaken van de invoegtoepassing voor toepassingsroutering met Prometheus in Grafana als onderdeel van het analyseren van de prestaties en het gebruik van uw toepassing.