Share via


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:

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:

  1. 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
    
  2. 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:

  1. 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"
    
  2. 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:

  1. Creare un gruppo di risorse di Azure usando il comando az group create.

    az group create --name myNetworkResourceGroup --location eastus
    
  2. 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.

  3. 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}
    
  4. 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 per service.beta.kubernetes.io/azure-load-balancer-ipv4 un indirizzo IPv4 e service.beta.kubernetes.io/azure-load-balancer-ipv6 per un indirizzo IPv6, come illustrato nell'esempio YAML. L'aggiunta dell'annotazione service.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"
    
  5. 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

  1. 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 di 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. 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.