Configurazioni avanzate di ingresso e ingresso NGINX con il componente aggiuntivo routing dell'applicazione
Il componente aggiuntivo di routing dell'applicazione supporta due modi per configurare i controller di ingresso e gli oggetti in ingresso:
- Configurazione del controller di ingresso NGINX, ad esempio la creazione di più controller, la configurazione di servizi di bilanciamento del carico privato e l'impostazione di indirizzi IP statici.
- Configurazione per risorsa di ingresso tramite annotazioni.
Prerequisiti
Un cluster del servizio Azure Kubernetes con il componente aggiuntivo di routing dell'applicazione.
Connettersi al cluster del servizio Azure Kubernetes
Per connettersi al cluster Kubernetes dal computer locale si usa kubectl
, il client da riga di comando di Kubernetes. È possibile installarlo in locale usando il comando az aks install-cli. Se si usa Azure Cloud Shell, kubectl
è già installato.
Per configurare kubectl per connettersi al cluster Kubernetes, usare il comando az aks get-credentials
.
az aks get-credentials -resource-group <ResourceGroupName> --name <ClusterName>
Configurazione del controller di ingresso NGINX
Il componente aggiuntivo di routing dell'applicazione usa una definizione di risorsa personalizzata (CRD) kubernetes chiamata NginxIngressController
per configurare i controller di ingresso NGINX. È possibile creare più controller di ingresso o modificare la configurazione esistente.
NginxIngressController
CRD ha un loadBalancerAnnotations
campo per controllare il comportamento del servizio del controller di ingresso NGINX impostando le annotazioni del servizio di bilanciamento del carico.
Controller di ingresso NGINX predefinito
Quando si abilita il componente aggiuntivo di routing dell'applicazione con NGINX, viene creato un controller di ingresso denominato default
in configurato con un servizio di bilanciamento del app-routing-namespace
carico di Azure pubblico. Tale controller di ingresso usa un nome di classe in ingresso di webapprouting.kubernetes.azure.com
.
Creare un altro controller di ingresso NGINX pubblico
Per creare un altro controller di ingresso NGINX con un'istanza pubblica di Azure Load Balancer:
Copiare il manifesto YAML seguente in un nuovo file denominato nginx-public-controller.yaml e salvare il file nel computer locale.
apiVersion: approuting.kubernetes.azure.com/v1alpha1 kind: NginxIngressController metadata: name: nginx-public spec: ingressClassName: nginx-public controllerNamePrefix: nginx-public
Creare le risorse del controller di ingresso NGINX usando il
kubectl apply
comando .kubectl apply -f nginx-public-controller.yaml
L'output di esempio seguente mostra la risorsa creata:
nginxingresscontroller.approuting.kubernetes.azure.com/nginx-public created
Creare un controller di ingresso NGINX interno con un indirizzo IP privato
Per creare un controller di ingresso NGINX con un servizio di bilanciamento del carico interno di Azure con un indirizzo IP privato:
Copiare il manifesto YAML seguente in un nuovo file denominato nginx-internal-controller.yaml e salvare il file nel computer locale.
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"
Creare le risorse del controller di ingresso NGINX usando il
kubectl apply
comando .kubectl apply -f nginx-internal-controller.yaml
L'output di esempio seguente mostra la risorsa creata:
nginxingresscontroller.approuting.kubernetes.azure.com/nginx-internal created
Creare un controller di ingresso NGINX con un indirizzo IP statico
Per creare un controller di ingresso NGINX con un indirizzo IP statico in Azure Load Balancer:
Creare un gruppo di risorse di Azure usando il comando
az group create
.az group create --name myNetworkResourceGroup --location eastus
Creare un indirizzo IP pubblico statico usando il
az network public ip create
comando .az network public-ip create \ --resource-group myNetworkResourceGroup \ --name myIngressPublicIP \ --sku Standard \ --allocation-method static
Nota
Se si usa un servizio di bilanciamento del carico dello SKU Basic nel cluster del servizio Azure Kubernetes, usare Basic per il parametro
--sku
quando si definisce un indirizzo IP pubblico. Solo gli indirizzi IP SKU Basic funzionano con il servizio di bilanciamento del carico dello SKU Basic e solo gli indirizzi IP SKU Standard funzionano con servizi di bilanciamento del carico dello SKU Standard.Verificare che l'identità del cluster usata dal cluster del servizio Azure Kubernetes disponga delle autorizzazioni delegate per il gruppo di risorse dell'indirizzo IP pubblico usando il comando [
az role assignment create
][az-role-assignment-create].Nota
Aggiornare
<ClusterName>
e<ClusterResourceGroup>
con il nome e il nome del gruppo di risorse del cluster del servizio Azure Kubernetes.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}
Copiare il manifesto YAML seguente in un nuovo file denominato nginx-staticip-controller.yaml e salvare il file nel computer locale.
Nota
È possibile usare
service.beta.kubernetes.io/azure-pip-name
per il nome IP pubblico oppure perservice.beta.kubernetes.io/azure-load-balancer-ipv4
un indirizzo IPv4 eservice.beta.kubernetes.io/azure-load-balancer-ipv6
per un indirizzo IPv6, come illustrato nell'esempio YAML. L'aggiunta dell'annotazioneservice.beta.kubernetes.io/azure-pip-name
garantisce la creazione di LoadBalancer più efficiente ed è consigliabile evitare potenziali limitazioni.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"
Creare le risorse del controller di ingresso NGINX usando il
kubectl apply
comando .kubectl apply -f nginx-staticip-controller.yaml
L'output di esempio seguente mostra la risorsa creata:
nginxingresscontroller.approuting.kubernetes.azure.com/nginx-static created
Verificare che il controller di ingresso sia stato creato
È possibile verificare lo stato del controller di ingresso NGINX usando il kubectl get nginxingresscontroller
comando .
Nota
Aggiornare <IngressControllerName>
con il nome usato durante la creazione di 'NginxIngressController'.
kubectl get nginxingresscontroller -n <IngressControllerName>
L'output di esempio seguente mostra la risorsa creata. La disponibilità del controller potrebbe richiedere alcuni minuti:
NAME INGRESSCLASS CONTROLLERNAMEPREFIX AVAILABLE
nginx-public nginx-public nginx True
È anche possibile visualizzare le condizioni per risolvere eventuali problemi:
kubectl get nginxingresscontroller -n <IngressControllerName> -o jsonpath='{range .items[*].status.conditions[*]}{.lastTransitionTime}{"\t"}{.status}{"\t"}{.type}{"\t"}{.message}{"\n"}{end}'
L'output di esempio seguente mostra le condizioni di un controller di ingresso integro:
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
Usare il controller di ingresso in un ingresso
Copiare il manifesto YAML seguente in un nuovo file denominato ingress.yaml e salvare il file nel computer locale.
Nota
Eseguire l'aggiornamento
<Hostname>
con il nome host DNS.<IngressClassName>
è quello definito durante la creazione diNginxIngressController
.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
Creare le risorse del cluster usando il comando
kubectl apply
.kubectl apply -f ingress.yaml -n hello-web-app-routing
L'output di esempio seguente mostra la risorsa creata:
ingress.networking.k8s.io/aks-helloworld created
Verificare che l'Ingress gestito sia stato creato
È possibile verificare che l'ingresso gestito sia stato creato usando il comando kubectl get ingress
.
kubectl get ingress -n hello-web-app-routing
L'output di esempio seguente mostra l'ingresso gestito creato. La classe in ingresso, l'host e l'indirizzo IP possono essere diversi:
NAME CLASS HOSTS ADDRESS PORTS AGE
aks-helloworld webapprouting.kubernetes.azure.com myapp.contoso.com 20.51.92.19 80, 443 4m
Pulizia dei controller di ingresso
È possibile rimuovere il controller di ingresso NGINX usando il kubectl delete nginxingresscontroller
comando .
Nota
Aggiornare <IngressControllerName>
con il nome usato durante la creazione di NginxIngressController
.
kubectl delete nginxingresscontroller -n <IngressControllerName>
Configurazione per risorsa di ingresso tramite annotazioni
Il controller di ingresso NGINX supporta l'aggiunta di annotazioni a oggetti in ingresso specifici per personalizzare il comportamento.
È possibile annotare l'oggetto in ingresso aggiungendo la rispettiva annotazione nel metadata.annotations
campo .
Nota
Le chiavi e i valori di annotazione possono essere solo stringhe. Altri tipi, ad esempio valori booleani o numerici, devono essere racchiusi tra virgolette, ad esempio "true"
, "false"
, "100"
.
Ecco alcuni esempi di annotazioni per le configurazioni comuni. Per un elenco completo, vedere la documentazione relativa alle annotazioni in ingresso NGINX.
Dimensioni massime personalizzate del corpo
Per NGINX, viene restituito un errore 413 al client quando le dimensioni di una richiesta superano le dimensioni massime consentite del corpo della richiesta client. Per eseguire l'override del valore predefinito, usare l'annotazione:
nginx.ingress.kubernetes.io/proxy-body-size: 4m
Di seguito è riportato un esempio di configurazione di ingresso con questa annotazione:
Nota
Eseguire l'aggiornamento <Hostname>
con il nome host DNS.
<IngressClassName>
è quello definito durante la creazione di 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
Timeout connessione personalizzata
È possibile modificare il timeout che il controller di ingresso NGINX attende di chiudere una connessione con il carico di lavoro. Tutti i valori di timeout sono unitless e in secondi. Per eseguire l'override del timeout predefinito, usare l'annotazione seguente per impostare un timeout di lettura proxy di 120 secondi valido:
nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
Esaminare i timeout personalizzati per altre opzioni di configurazione.
Di seguito è riportato un esempio di configurazione di ingresso con questa annotazione:
Nota
Eseguire l'aggiornamento <Hostname>
con il nome host DNS.
<IngressClassName>
è quello definito durante la creazione di 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
Protocollo back-end
Per impostazione predefinita, il controller di ingresso NGINX usa HTTP
per raggiungere i servizi. Per configurare protocolli back-end alternativi, HTTPS
ad esempio o GRPC
, usare l'annotazione :
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
or
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
Esaminare i protocolli back-end per altre opzioni di configurazione.
Di seguito è riportato un esempio di configurazione di ingresso con questa annotazione:
Nota
Eseguire l'aggiornamento <Hostname>
con il nome host DNS.
<IngressClassName>
è quello definito durante la creazione di 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)
Per abilitare la condivisione di risorse tra le origini (CORS) in una regola di ingresso, usare l'annotazione :
nginx.ingress.kubernetes.io/enable-cors: "true"
Vedere abilitare CORS per altre opzioni di configurazione.
Di seguito è riportato un esempio di configurazione di ingresso con questa annotazione:
Nota
Eseguire l'aggiornamento <Hostname>
con il nome host DNS.
<IngressClassName>
è quello definito durante la creazione di 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
Disabilitare il reindirizzamento SSL
Per impostazione predefinita, il controller reindirizza (308) a HTTPS se TLS è abilitato per un ingresso. Per disabilitare questa funzionalità per risorse di ingresso specifiche, usare l'annotazione :
nginx.ingress.kubernetes.io/ssl-redirect: "false"
Esaminare l'imposizione HTTPS sul lato server tramite reindirizzamento per altre opzioni di configurazione.
Di seguito è riportato un esempio di configurazione di ingresso con questa annotazione:
Nota
Eseguire l'aggiornamento <Hostname>
con il nome host DNS.
<IngressClassName>
è quello definito durante la creazione di 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
Riscrittura dell'URL
In alcuni scenari, l'URL esposto nel servizio back-end è diverso dal percorso specificato nella regola di ingresso. Senza una richiesta di riscrittura restituisce 404. Ciò è particolarmente utile con il routing basato sul percorso in cui è possibile gestire due applicazioni Web diverse nello stesso dominio. È possibile impostare il percorso previsto dal servizio usando l'annotazione :
nginx.ingress.kubernetes.io/rewrite-target": /$2
Di seguito è riportato un esempio di configurazione di ingresso con questa annotazione:
Nota
Eseguire l'aggiornamento <Hostname>
con il nome host DNS.
<IngressClassName>
è quello definito durante la creazione di 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
Passaggi successivi
Informazioni sul monitoraggio delle metriche del controller in ingresso-nginx incluse nel componente aggiuntivo di routing dell'applicazione con con Prometheus in Grafana come parte dell'analisi delle prestazioni e dell'utilizzo dell'applicazione.