Condividi tramite

Creare un controller di ingresso non gestito

  • Articolo

Un controller di ingresso è un componente software che fornisce proxy inverso, routing del traffico configurabile e terminazione TLS per i servizi Kubernetes. Le risorse di ingresso Kubernetes vengono usate per configurare le regole di ingresso e le route per i singoli servizi Kubernetes. Quando si usano un controller di ingresso e regole di ingresso, è possibile usare un unico indirizzo IP per instradare il traffico a più servizi in un cluster Kubernetes.

Questo articolo illustra come distribuire il controller di ingresso NGINX in un cluster del servizio Azure Kubernetes. Due applicazioni vengono eseguite nel cluster servizio Azure Kubernetes, ognuna delle quali è accessibile tramite un singolo indirizzo IP.

Importante

È consigliabile usare il componente aggiuntivo Instradamento dell’applicazione per l'ingresso nel servizio Azure Kubernetes. Per ulteriori informazioni, consultare Ingresso nginx gestito con componente aggiuntivo di routing dell’applicazione.

Nota

Esistono due controller di ingresso open source per Kubernetes basati su Nginx: uno gestito dalla community di Kubernetes (kubernetes/ingress-nginx) e uno gestito da NGINX, Inc. (nginxinc/kubernetes-ingress). Questo articolo usa il controller di ingresso della community Kubernetes.

Operazioni preliminari

  • Questo articolo usa Helm 3 per installare il controller di ingresso NGINX in una versione supportata di Kubernetes. Accertarsi di usare la versione più recente di Helm e di avere accesso al repository Helm in ingresso-nginx. I passaggi descritti in questo articolo potrebbero non essere compatibili con le versioni precedenti del grafico Helm, del controller in ingresso NGINX o di Kubernetes.
  • Questo articolo presuppone che sia presente un cluster già esistente del servizio Azure Kubernetes con un Registro Azure Container integrato (ACR). Per ulteriori informazioni sulla creazione di un cluster del servizio Azure Kubernetes con un Registro Azure Container integrato, consultare Eseguire l'autenticazione con Registro Azure Container dal servizio Azure Kubernetes.
  • L'endpoint di integrità dell’API di Kubernetes healthz è stato deprecato in Kubernetes v1.16. È possibile sostituirlo con gli endpoint livez e readyz. Consultare endpoint di integrità dell'API di Kubernetes per determinare quale endpoint usare per lo scenario.
  • Se si usa l'interfaccia della riga di comando di Azure, questo articolo richiede l'esecuzione dell'interfaccia della riga di comando di Azure versione 2.0.64 o successive. Eseguire az --version per trovare la versione. Se è necessario installare o aggiornare, vedere [Installare l'interfaccia della riga di comando di Azure][azure-cli-install].
  • In questo articolo si presuppone che sia in esecuzione Azure PowerShell versione 5.9.0 o una versione successiva se si usa Azure PowerShell. Eseguire Get-InstalledModule -Name Az per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare Azure PowerShell.

Configurazione di base

Per creare un controller di ingresso NGINX base senza personalizzare le impostazioni predefinite, usare Helm. La seguente configurazione usa le impostazioni predefinite per praticità. È possibile aggiungere parametri per personalizzare la distribuzione, ad esempio --set controller.replicaCount=3.

Nota

Se si desidera abilitare la conservazione protocollo IP di origine client per le richieste ai contenitori nel cluster, aggiungere --set controller.service.externalTrafficPolicy=Local al comando di installazione di Helm. Il protocollo IP di origine client viene archiviato nell'intestazione della richiesta in X-Forwarded-For. Quando si usa un controller in ingresso con conservazione protocollo IP di origine client abilitata, il pass-through TLS non funzionerà.

NAMESPACE=ingress-basic

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --create-namespace \
  --namespace $NAMESPACE \
  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
  --set controller.service.externalTrafficPolicy=Local

Nota

In questa esercitazione, service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path è impostato su /healthz. Ciò significa che se il codice di risposta delle richieste a /healthz non è 200, l'intero controller di ingresso sarà inattivo. È possibile modificare il valore ad altri URI nel proprio scenario. Non è possibile eliminare questa parte o annullare l'impostazione del valore, o il controller di ingresso sarà comunque inattivo. Il pacchetto ingress-nginx usato in questa esercitazione, fornito da Kubernetes official, restituirà sempre il codice di risposta 200 se /healthz è richiesto, poiché è progettato come back-end predefinito perché gli utenti abbiano un avvio rapido, a meno che non sia sovrascritto dalle regole di ingresso.

Configurazione personalizzata

In alternativa alla configurazione di base presentata nella sezione precedente, il seguente set di passaggi mostrerà come distribuire un controller di ingresso personalizzato. È possibile usare un indirizzo IP statico interno o un indirizzo IP pubblico dinamico.

Importare le immagini usate dal grafico Helm nel Registro Azure Container

Per controllare le versioni delle immagini, è necessario importarle nel proprio Registro Azure Container. Il grafico Helm del controller in ingresso NGINX si basa su tre immagini del contenitore. Usare az acr import per importare le immagini nel Registro Azure Container.

REGISTRY_NAME=<REGISTRY_NAME>
SOURCE_REGISTRY=registry.k8s.io
CONTROLLER_IMAGE=ingress-nginx/controller
CONTROLLER_TAG=v1.8.1
PATCH_IMAGE=ingress-nginx/kube-webhook-certgen
PATCH_TAG=v20230407
DEFAULTBACKEND_IMAGE=defaultbackend-amd64
DEFAULTBACKEND_TAG=1.5

az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$CONTROLLER_IMAGE:$CONTROLLER_TAG --image $CONTROLLER_IMAGE:$CONTROLLER_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$PATCH_IMAGE:$PATCH_TAG --image $PATCH_IMAGE:$PATCH_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG --image $DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG

Nota

Oltre a importare immagini dei contenitori nel Registro Azure Container, è anche possibile importare grafici Helm. Per ulteriori informazioni, consultare Eseguire il push e il pull dei grafici Helm nel Registro Azure Container.

Creare un controller di ingresso

Per creare il controller di ingresso, usare Helm per installare ingress-nginx. Il controller di ingresso deve essere pianificato in un nodo Linux. I nodi di Windows Server non devono eseguire il controller di ingresso. Un selettore di nodo viene specificato con il parametro --set nodeSelector per indicare all'utilità di pianificazione Kubernetes di eseguire il controller di ingresso NGINX in un nodo basato su Linux.

Per una maggiore ridondanza, vengono distribuite due repliche dei controller di ingresso NGINX con il parametro --set controller.replicaCount. Per sfruttare appieno le repliche del controller di ingresso in esecuzione, assicurarsi che nel cluster servizio Azure Kubernetes siano presenti più nodi.

Il seguente esempio crea uno spazio dei nomi del servizio Kubernetes per le risorse in ingresso denominate in ingresso-di base e funziona all'interno di tale spazio dei nomi. Specificare uno spazio dei nomi per il proprio ambiente in base alle esigenze. Se il cluster del servizio Azure Kubernetes non è abilitato per il controllo degli accessi in base al ruolo, aggiungere --set rbac.create=false ai comandi Helm.

Nota

Se si desidera abilitare la conservazione protocollo IP di origine client per le richieste ai contenitori nel cluster, aggiungere --set controller.service.externalTrafficPolicy=Local al comando di installazione di Helm. Il protocollo IP di origine client viene archiviato nell'intestazione della richiesta in X-Forwarded-For. Quando si usa un controller in ingresso con conservazione protocollo IP di origine client abilitata, il pass-through TLS non funzionerà.

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>

# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version 4.7.1 \
    --namespace ingress-basic \
    --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_LOGIN_SERVER \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
    --set controller.service.externalTrafficPolicy=Local \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest=""

Creare un controller di ingresso usando un indirizzo IP interno

Per impostazione predefinita, il controller di ingresso NGINX viene creato con un'assegnazione di indirizzo IP pubblico e dinamico. Un requisito di configurazione comune consiste nell'usare una rete privata interna e un indirizzo IP. Questo approccio consente di limitare l'accesso ai servizi ai soli utenti interni, escludendo qualsiasi accesso esterno.

Usare i parametri --set controller.service.loadBalancerIP e --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true per assegnare un indirizzo IP interno al controller di ingresso. Fornire il proprio indirizzo IP interno per l'uso con il controller di ingresso. Assicurarsi che questo indirizzo IP non sia già in uso all'interno della rete virtuale. Inoltre, se si usano una rete virtuale e una subnet esistenti, per gestirle è necessario configurare il cluster del servizio Azure Kubernetes con le autorizzazioni corrette. Per ulteriori informazioni, consultare Usare il networking kubenet con gli intervalli di indirizzi IP nel servizio Azure Kubernetes (AKS) o Configurare Azure Container Networking Interface nel servizio Azure Kubernetes (AKS).

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>

# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version 4.7.1 \
    --namespace ingress-basic \
    --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_LOGIN_SERVER \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.loadBalancerIP=10.224.0.42 \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest=""

Controllare il servizio di bilanciamento del carico

Controllare il servizio di bilanciamento del carico usando kubectl get services.

kubectl get services --namespace ingress-basic -o wide -w ingress-nginx-controller

Quando viene creato il servizio di bilanciamento del carico Kubernetes per il controller di ingresso NGINX, viene assegnato un indirizzo IP in EXTERNAL-IP, come illustrato nell'output del seguente esempio:

NAME                       TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE   SELECTOR
ingress-nginx-controller   LoadBalancer   10.0.65.205   EXTERNAL-IP     80:30957/TCP,443:32414/TCP   1m   app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx

Se durante questa fase si passa all'indirizzo IP esterno, comparirà una pagina 404. Ciò è dovuto al fatto che è comunque necessario configurare la connessione all'indirizzo IP esterno (operazione eseguita nelle sezioni successive).

Eseguire applicazioni demo

Per visualizzare il controller in ingresso in azione, eseguire due applicazioni demo nel cluster del servizio Azure Kubernetes. In questo esempio, kubectl apply viene usato per distribuire due istanze di una semplice applicazione Hello world.

  1. Creare un file aks-helloworld-one.yaml e copiarlo nel seguente YAML esempio:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld-one  
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld-one
  template:
    metadata:
      labels:
        app: aks-helloworld-one
    spec:
      containers:
      - name: aks-helloworld-one
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "Welcome to Azure Kubernetes Service (AKS)"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld-one  
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: aks-helloworld-one

  2. Creare un file aks-helloworld-two.yaml e copiarlo nel seguente YAML esempio:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld-two  
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld-two
  template:
    metadata:
      labels:
        app: aks-helloworld-two
    spec:
      containers:
      - name: aks-helloworld-two
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "AKS Ingress Demo"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld-two  
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: aks-helloworld-two

  3. Eseguire le due applicazioni demo usando kubectl apply:

    kubectl apply -f aks-helloworld-one.yaml --namespace ingress-basic
kubectl apply -f aks-helloworld-two.yaml --namespace ingress-basic

Creare una route in ingresso

Entrambe le applicazioni sono in esecuzione nel cluster Kubernetes. Per instradare il traffico a ogni applicazione, creare una risorsa ingresso Kubernetes. La risorsa di ingresso configura le regole che instradano il traffico a una delle due applicazioni.

Nel seguente esempio, il traffico verso EXTERNAL_IP/hello-world-one viene instradato al servizio denominato aks-helloworld-one. Il traffico verso EXTERNAL_IP/hello-world-two viene instradato al servizio aks-helloworld-two. Il traffico verso EXTERNAL_IP/statico viene instradato al servizio denominato aks-helloworld-one per asset statici.

  1. Creare un file denominato hello-world-ingress.yaml e copiarlo nell'esempio YAML seguente:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /hello-world-one(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port:
              number: 80
      - path: /hello-world-two(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-two
            port:
              number: 80
      - path: /(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port:
              number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress-static
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/rewrite-target: /static/$2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /static(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld-one
            port: 
              number: 80

  2. Creare la risorsa di ingresso con il comando kubectl apply.

    kubectl apply -f hello-world-ingress.yaml --namespace ingress-basic

Testare il controller di ingresso

Per testare le route per il controller di ingresso, passare alle due applicazioni. Aprire un Web browser all'indirizzo IP del controller di ingresso NGINX, come EXTERNAL_IP. La prima applicazione demo viene visualizzata nel Web browser, come illustrato nel seguente esempio:

Screenshot che mostra la prima app in esecuzione dietro il controller di ingresso.

A questo punto, aggiungere il percorso /hello-world-two all'indirizzo IP, ad esempio EXTERNAL_IP/hello-world-two. Viene visualizzata la seconda applicazione demo con il titolo personalizzato:

Screenshot che mostra la seconda app in esecuzione dietro il controller di ingresso.

Testare un indirizzo IP interno

  1. Creare un pod test e collegarvi una sessione terminal.

    kubectl run -it --rm aks-ingress-test --image=mcr.microsoft.com/dotnet/runtime-deps:6.0 --namespace ingress-basic

  2. Installare curl nel pod usando apt-get.

    apt-get update && apt-get install -y curl

  3. Accedere all'indirizzo del controller in ingresso Kubernetes usando curl, ad esempio http://10.224.0.42. Fornire l’indirizzo IP interno specificato durante la distribuzione del controller in ingresso.

    curl -L http://10.224.0.42

    Non è stato fornito alcun percorso aggiuntivo insieme all'indirizzo, pertanto, il controller di ingresso viene instradato per impostazione predefinita verso la route /. Viene restituita la prima applicazione demo, come illustrato nell'output di esempio condensato seguente:

    <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link rel="stylesheet" type="text/css" href="/static/default.css">
    <title>Welcome to Azure Kubernetes Service (AKS)</title>
[...]

  4. Aggiungere il percorso /hello-world-two all'indirizzo, ad esempio http://10.224.0.42/hello-world-two.

    curl -L -k http://10.224.0.42/hello-world-two

    Viene restituita la seconda applicazione demo con titolo personalizzato, come illustrato nell'output di esempio condensato seguente:

    <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link rel="stylesheet" type="text/css" href="/static/default.css">
    <title>AKS Ingress Demo</title>
[...]

Pulire le risorse

Questo articolo ha usato Helm per installare i componenti di ingresso e le app di esempio. Quando si distribuisce un grafico Helm, vengono create numerose risorse Kubernetes. Queste risorse includono pod, distribuzioni e servizi. Per pulire queste risorse, è possibile eliminare l'intero spazio dei nomi esempio o eliminare risorse individualmente.

Eliminare lo spazio dei nomi esempio e tutte le risorse

Per eliminare l'intero spazio dei nomi esempio, usare il comando kubectl delete e specificare il nome dello spazio dei nomi. Tutte le risorse nello spazio dei nomi vengono eliminate.

kubectl delete namespace ingress-basic

Eliminare le risorse singolarmente

In alternativa, un approccio più granulare consiste nell'eliminare le singole risorse create.

  1. Elencare le versioni di Helm con il comando helm list.

    helm list --namespace ingress-basic

    Cercare grafici denominati ingress-nginx e aks-helloworld, come illustrato nell'output del seguente esempio:

    NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
ingress-nginx           ingress-basic   1               2020-01-06 19:55:46.358275 -0600 CST    deployed        nginx-ingress-1.27.1    0.26.1

  2. Disinstallare le versioni con il comando helm uninstall.

    helm uninstall ingress-nginx --namespace ingress-basic

  3. Successivamente, rimuovere le due applicazioni esempio.

    kubectl delete -f aks-helloworld-one.yaml --namespace ingress-basic
kubectl delete -f aks-helloworld-two.yaml --namespace ingress-basic

  4. Rimuovere la route in ingresso che ha indirizzato il traffico verso le app esempio.

    kubectl delete -f hello-world-ingress.yaml

  5. Eliminare lo spazio dei nomi usando il comando kubectl delete e specificare il nome dello spazio dei nomi.

    kubectl delete namespace ingress-basic

Passaggi successivi

Per configurare TLS con i componenti di ingresso esistenti, consultare Usare TLS con un controller in ingresso.

Per configurare il cluster del servizio Azure Kubernetes per l'uso del routing delle applicazioni HTTP, consultare Abilitare il componente aggiuntivo di routing delle applicazioni HTTP.

In questo articolo sono stati inclusi alcuni componenti esterni ad servizio Azure Kubernetes. Per altre informazioni su questi componenti, vedere le pagine di progetto seguenti:

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.