Geavanceerde NGINX-ingangscontroller- en toegangsbeheerobjectconfiguraties met de invoegtoepassing voor toepassingsroutering
De invoegtoepassing voor toepassingsroutering ondersteunt twee manieren om toegangsbeheerobjecten en inkomende objecten te configureren:
- Configuratie van de NGINX-ingangscontroller , zoals het maken van meerdere controllers, het configureren van privé-load balancers en het instellen van statische IP-adressen.
- Configuratieresource per inkomend verkeer via aantekeningen.
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 kubectl
u 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-preview
Kubernetes 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 standaardNginxIngressController
aangepaste resource handmatig verwijderen.Internal
: De standaard Nginx-ingangscontroller wordt gemaakt met een interne load balancer. Eventuele wijzigingen in aantekeningen in deNginxIngressController
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 deNginxIngressController
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 standaardNginxIngressController
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:
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
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:
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"
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:
Maak een Azure-resourcegroep met behulp van de
az group create
opdracht.az group create --name myNetworkResourceGroup --location eastus
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.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}
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 voorservice.beta.kubernetes.io/azure-load-balancer-ipv4
een IPv4-adres enservice.beta.kubernetes.io/azure-load-balancer-ipv6
voor een IPv6-adres, zoals wordt weergegeven in het voorbeeld van YAML. Het toevoegen van deservice.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"
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
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 deNginxIngressController
.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
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 GRPC
wilt 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.
Azure Kubernetes Service