NCP creerà un bilanciamento del carico di livello 7 per gli ingressi con specifica TLS e un bilanciamento del carico di livello 7 per gli ingressi senza specifica TLS. È inoltre possibile creare CRD (CustomResourceDefinitions) per gestire la scalabilità in ingresso.

Si tenga presente quanto segue:
  • Tutti gli ingressi riceveranno un singolo indirizzo IP.
  • Alla risorsa in ingresso viene allocato un indirizzo IP dal pool di IP esterno specificato dall'opzione external_ip_pools nella sezione [nsx_v3] ncp.ini. Il bilanciamento del carico è esposto su questo indirizzo IP e sulle porte HTTP e HTTPS (80 e 443).
  • Alla risorsa in ingresso viene allocato un indirizzo IP dal pool di IP esterno specificato dall'opzione external_ip_pools_lb nella sezione [nsx_v3] ncp.ini. Se l'opzione external_ip_pools_lb non esiste, viene utilizzato il pool specificato da external_ip_pools. Il bilanciamento del carico è esposto su questo indirizzo IP e sulle porte HTTP e HTTPS (80 e 443).
  • È possibile passare a un pool di IP diverso modificando la configurazione e riavviando NCP.
  • È possibile specificare un certificato predefinito per TLS. Vedere di seguito per le informazioni sulla generazione di un certificato e sul montaggio di un certificato nel pod NCP.
  • Gli ingressi senza specifica TLS saranno ospitati nel server virtuale HTTP (porta 80).
  • Gli ingressi con specifica TLS saranno ospitati nel server virtuale HTTPS (porta 443). Il bilanciamento del carico fungerà da server SSL e terminerà la connessione SSL client.
  • È supportata la modifica dell'ingresso aggiungendo o rimuovendo la sezione TLS. Quando la chiave tls viene rimossa dalla specifica in ingresso, le regole di uscita vengono trasferite dal server virtuale HTTPS (porta 443) al server virtuale HTTP (porta 80). Allo stesso modo, quando la chiave tls viene aggiunta alla specifica in ingresso, le regole di uscita vengono trasferite dal server virtuale HTTP (porta 80) al server virtuale HTTPS (porta 443).
  • Se sono presenti regole duplicate nelle definizioni di ingresso per un singolo cluster, viene applicata solo la prima regola. Gli altri punti di uscita con regole duplicate saranno annotati con errore. Ad esempio, se si creano due ingressi con lo stesso host e path e un ingresso è TLS mentre l'altro è non TLS e kubernetes.io/ingress.allow-http è false, le due regole verranno create in server virtuali diversi e non saranno in conflitto tra loro. Tuttavia, se kubernetes.io/ingress.allow-http è true, l'ingresso applicato in un secondo momento verrà annotato con un errore. Per ulteriori informazioni, vedere la sezione "Errori" in basso.
  • Per ogni cluster è supportato solo un singolo ingresso con un back-end predefinito. Il traffico che non corrisponde ad alcuna regola di ingresso verrà inoltrato al back-end predefinito.
  • Se sono presenti più ingressi con un back-end predefinito, verrà configurato solo il primo di essi. Gli altri verranno annotati con un errore. Per ulteriori informazioni, vedere la sezione "Errori" in basso.
  • Le regole vengono applicate nel seguente ordine:
    1. Regole sia con host sia con path specificate.
      1. Regole con l'Exact pathType.
      2. Regole con l'Prefix pathType.
      3. Regole con l'Regex pathType.
    2. Regole con host o path specificate.
      1. Regole con l'Exact pathType.
      2. Regole con l'Prefix pathType.
      3. Regole con l'Regex pathType.

    Nota: se più percorsi corrispondono a una richiesta, la precedenza verrà assegnata al percorso corrispondente più lungo.

    Info pathType
    • A partire da Kubernetes 1.19 pathType è obbligatorio.
    • Se è impostato use-regex, sarà effettivo solo se pathType è ImplementationSpecific.
    • Se use-regex non è impostato, ImplementationSpecific viene trattato allo stesso modo di Exact. pathType ha la precedenza sulle altre annotazioni NCP.
    • Possono coesistere due percorsi corrispondenti con pathTypediverse.
    • Per il tipo di Prefix , /foo corrisponderà a /foo/, /foo/bar ma non /foo o /foobar. Per associare /foo, aggiungere il percorso del Exact /foo alla regola d'ingresso.
  • Caratteri jolly nel nome host
    Quando si specifica il nome host, è possibile specificare il nome esatto, ad esempio abc.example.com, o utilizzare un carattere jolly, come ad esempio *.example.com. Si noti che il carattere jolly corrisponde a una o più etichette DNS. La seguente tabella mostra i risultati della corrispondenza se si specifica *.example.com.
    Intestazione host Risultato della corrispondenza
    abc.example.com Associa
    abc.def.example.com Associa
    example.com Nessuna corrispondenza
  • (Quest'opzione è applicabile se si utilizza la modalità Criterio). Se viene creato un ingresso TLS con un back-end predefinito, è consigliabile configurare tale back-end predefinito per rispondere alle richieste HTTP e HTTPS perché:
    • Il bilanciamento del carico terminerà TLS e invierà richieste HTTP al server back-end predefinito se è presente un ingresso TLS (nel cluster per il caso d'uso Kubernetes/TKGI o nello stesso spazio dei nomi per il caso d'uso di Project Pacific) con l'host che corrisponde a quello nella richiesta.
    • Il bilanciamento del carico ricodificherà TLS e invierà la richiesta HTTPS al server back-end se è presente un ingresso TLS (nel cluster per il caso d'uso Kubernetes/TKGI o nello stesso spazio dei nomi per il caso d'uso di Project Pacific) con l'host che corrisponde a quello nella richiesta.
  • La risorsa IngressClass è supportata.
  • L'attributo pathType è supportato.
  • L'autenticazione client JWT (JSON Web Token) è supportata. Questa funzionalità richiede NSX 3.0.0 o versione successiva.
A partire da Kubernetes 1.18, l'annotazione kubernetes.io/ingress.class è obsoleta e sostituita dalla risorsa IngressClass. Per specificare NSX come controller in ingresso nella risorsa IngressClass, impostare il parametro del controller su k8s.io/nsx. Ad esempio: 
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nsx-lb
  annotations:
    ingressclass.kubernetes.io/is-default-class: true
spec:
  controller: k8s.io/nsx
Per specificare un controllo in ingresso di terze parti, impostare il parametro del controller su k8s.io/<controller name>. Ad esempio: 
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx-lb
  annotations:
    ingressclass.kubernetes.io/is-default-class: false
spec:
  controller: k8s.io/ingress-nginx

Per impostare IngressClass come valore predefinito per il cluster, impostare il ingressclass.kubernetes.io/is-default-class annotazione su true. Vedere l'esempio in alto.

Non è necessario usare sia l'annotazione kubernetes.io/ingress.class sia la risorsa IngressClass.

Se si configura manualmente un oggetto Endpoints , assicurarsi di impostare il parametro targetRef. Il valore deve essere l'UID del pod back-end. Ad esempio: 
apiVersion: networking.k8s.io/v1
kind: Endpoints
metadata:
  name: tea-svc
subsets:
  - addresses:
    - ip: 172.26.0.2
      targetRef:
        uid: 4378e0ae-5837-49c6-a0b2-178dced8eb1e
...

Annotazioni funzionalità

Nella seguente tabella sono elencate le annotazioni supportate da NCP:
Annotazione Descrizione Valori supportati Valore predefinito
kubernetes.io/ingress.allow-http Abilita le richieste HTTP oltre a HTTPS true, false true
ncp/use-regex Abilita la corrispondenza del modello di percorso true, false false
ingress.kubernetes.io/rewrite-target Riscrive il percorso della richiesta in arrivo
  • Percorso che inizia con '/'
  • Percorso con un segnaposto numerato per un gruppo acquisito in un'espressione regolare, ad esempio /$1
 Nessun valore predefinito
ncp/http-redirect Reindirizza le richieste HTTP su HTTPS true, false false
kubernetes.io/ingress.class Indica quale controllo di uscita è responsabile per quest'ingresso nsx, nginx, etc. nsx
nsx/bilanciamento del carico Posiziona un ingresso in un bilanciamento del carico dedicato Nome di un bilanciamento del carico CRD Nessun valore predefinito
ncp/allowed-source-range Limita l'accesso in ingresso in base all'IP di origine della richiesta Elenco di CIDR separato da virgole, indirizzi IP o intervalli di IP. Nessun valore predefinito
ncp/ssl-mode Seleziona la modalità SSL per tutte le regole in un in ingresso offload, riesecuzione della crittografia, passthrough offload
ncp/jwt-alg Determina l'algoritmo da utilizzare per convalidare la firma JWT. Abilita l'autenticazione client JWT se impostata con ncp/jwt-secret. HS256, RS256 Nessun valore predefinito
ncp/jwt-secret Specifica il nome del segreto Kubernetes che contiene il segreto JWT o la chiave pubblica usata per la convalida della firma. Abilita l'autenticazione client JWT se impostata con ncp/jwt-alg. Nome di un segreto Kubernetes Nessun valore predefinito
ncp/jwt-token Posizione aggiuntiva per la ricerca di JWT nella richiesta HTTP. _arg_<param_name>, _cookie_<cookie_name> Nessun valore predefinito
ncp/jwt-realm Specifica l'intestazione dell'Area di autenticazione restituita con 401 quando l'autenticazione non riesce. Stringa che indica l'area di autenticazione Nome host della regola d'ingresso
ncp/jwt-preserve Opzione per mantenere JWT e passare al back-end dopo l'autenticazione riuscita. true, false true
ncp/connection_multiplexing_enabled Abilita TCP Multiplexing. true, false false
ncp/connection_multiplexing_number Se TCP Multiplexing è abilitato, specifica il numero di connessioni TCP inattive disponibili. 0 - 2147483647 6
Dettagli sulle annotazioni:
  • Corrispondenza percorso Regex (espressione regolare)
    • È possibile abilitare o disabilitare la corrispondenza delle espressioni regolari del parametro path d'ingresso (ma non di host) utilizzando ncp/use-regexdi annotazione. Se impostato su false, verrà eseguita una corrispondenza esatta del percorso facendo corrispondere equals. Se impostato su true, la corrispondenza delle espressioni regolari verrà eseguita aggiungendo l'inizio del carattere stringa (^) e la fine del carattere stringa ($) al percorso, in modo che l'intero URI della richiesta corrisponda al modello. Quando si utilizza l'operatore del OR (|), specificare sempre l'ambito con parentesi in modo che ^ e $ vengano applicati a tutti gli operandi. Ad esempio, path: /(tea|coffee|milk). Un esempio di specifica in ingresso:
      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    kubernetes.io/ingress.class: "nsx"
    #/tea/cup will be served by tea-svc:80
    ncp/use-regex: "True"
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      # for this tea and coffee NCP will configure regex rule
      - path: /tea/(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee/(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80
      # for juice and alcohol NCP will configure Exact and Prefix rules
      - path: /juice
        pathType: Exact
        backend:
          service:
            name: juice-svc
            port:
              number: 80
      - path: /alcohol
        pathType: Prefix
        backend:
          service:
            name: bar
              number: 80
    • Aggiornamento dei regressi prima dell'aggiornamento di NCP
      Quest'operazione è obbligatoria solo se sono presenti ingressi che richiedono la corrispondenza di tutti i percorsi secondari utilizzando i caratteri '.' e '*'.
      1. Aggiornare gli ingressi in modo da includere l'annotazione ncp/use-regex: true.
      2. Per la corrispondenza di tutti i percorsi secondari, se sono presenti percorsi come /coffee/* o /*, sostituirli con /coffee/.* e /.*.

        /coffee/.* corrisponderà a /coffee/, /coffee/a, /coffee/b, /coffee/a/be così via. /.* corrisponderà a /coffee, /tea, /coffee/ae così via. Se si omette il percorso, verrà prodotto lo stesso comportamento di path: /.*.

  • Nell'esempio seguente dell'annotazione ingress.kubernetes.io/rewrite-target, i percorsi /tè e /caffè verranno riscritti per / prima di inviare l'URL al servizio back-end. 
    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80
    Se path viene specificato utilizzando un'espressione regolare, i gruppi acquisiti vengono salvati in segnaposto numerati nel formato $1, $2 e così via. Questi segnaposto possono essere utilizzati come parametri nell'annotazione ingress.kubernetes.io/rewrite-target. I gruppi di acquisizione e i segnaposto denominati non sono supportati. Ad esempio, 
    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    kubernetes.io/ingress.class: "nsx"
    ncp/use-regex: "true"
    #/tea/cup will be rewritten to /cup before sending request to endpoint
    ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea/(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee/(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80
  • Informazioni sull'annotazione kubernetes.io/ingress.allow-http:
    • Se l'annotazione è impostata su false, verranno create regole per il server virtuale HTTPS.
    • Se l'annotazione è impostata su true o mancante, verranno create regole per i server virtuali HTTP e HTTPS. Le regole HTTPS verranno create solo se la sezione TLS è presente nella specifica in ingresso.
  • Informazioni sull'annotazione ncp/http-redirect:
    • Se l'annotazione è impostata su false, il traffico HTTP in entrata (porta 80) verso il server virtuale HTTP non verrà reindirizzato al server virtuale HTTPS.
    • Se l'annotazione è impostata su true, il traffico HTTP in entrata (porta 80) verso il server virtuale HTTP verrà reindirizzato al server virtuale HTTPS (porta 443).

    Questa annotazione è valida solo se la sezione TLS è presente. Quest'annotazione ha la precedenza su kubernetes.io/ingress.allow-http. Se impostata su true, indirizza il traffico HTTP corrispondente su HTTPS, indipendentemente da come è impostata la kubernetes.io/ingress.allow-http.

  • Informazioni sull'annotazione kubernetes.io/ingress.class:
    • Se il valore è nsx, quest'ingresso verrà gestito da NCP. Se viene specificato un altro valore, il numero d'ingresso verrà ignorato da NCP. Per ulteriori informazioni vedere Controller di ingresso di terze parti.
  • Per ulteriori informazioni sulle annotazioni nsx/loadbalancer, vedere CRD LoadBalancer per la gestione della scalabilità in ingresso.
  • Informazioni sull'annotazione ncp/allowed-source-range:
    • Supportato solo in modalità Policy.
    • Quando è impostata, una richiesta in entrata verrà accettata solo se il relativo IP di origine è incluso in quest'annotazione. In caso contrario, il traffico verrà interrotto.
    • È possibile specificare una combinazione di CIDR, indirizzi IP e intervalli di IP. Ad esempio, 1.1.1.1/24, 2.2.2.2, 3.3.3.3-4.4.4.4.
    • Esempio YAML:
      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    kubernetes.io/ingress.class: "nsx"
    #Source IP addresses allowed to access ingress URL
    ncp/allowed-source-range: "192.168.128.0/17, 192.168.64.0-192.168.64.255, 192.168.16.32"
spec:
  tls:
  - hosts:
    - cafe.example.com
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80
  • Informazioni sull'annotazione ncp/ssl-mode:
    • Supportato solo in modalità Policy.
    • Quest'annotazione si applica a tutte le regole in un ingresso e il bilanciamento del carico funzionerà nella modalità SSL selezionata per queste regole.

      Se ncp/ssl-mode è impostato su reencrypt o su passthrough, kubernetes.io/ingress.allow-http deve essere impostato su False. Quest'opzione non può essere impostata su passthrough se ingress.kubernetes.io/rewrite-target ncp/use-regex o ncp/allowed-source-range l'annotazione è impostata.

      Se ncp/ssl-mode è impostato su passthrough, l'attributo path nella specifica rules non è supportato.

  • Informazioni sull'autenticazione client JWT:
    • Per abilitare l'autenticazione del client JWT per tutte le regole in un in ingresso, è necessario impostare un valore valido sia ncp/jwt-alg sia ncp/jwt-secret. Quando quest'opzione è abilitata, il traffico HTTP in entrata verrà passato solo al back-end se corrisponde a un token Web JSON valido. In caso contrario, il traffico verrà rifiutato con lo stato 401.
    • Questa funzionalità non è compatibile con le seguenti annotazioni:
      • kubernetes.io/ingress.allow-http: true
      • ncp/http-redirect: true
      • ncp/ssl-mode: passthrough
    • ncp/jwt-alg:
      • Algoritmi simmetrici supportati: HS256
      • Algoritmi asimmetrici supportati: RS256
    • ncp/jwt-secret:
      • È necessario configurare una chiave simmetrica o un certificato pubblico in un segreto Kubernetes con il nome specificato in quest'annotazione nello stesso spazio dei nomi dell'ingresso.
      • Per gli algoritmi simmetrici, il segreto deve essere archiviato nel campo jwt.key.
      • Per gli algoritmi asimmetrici, il certificato pubblico deve essere archiviato nel campo tls.crt.
      • L'autenticazione del client JWT verrà disabilitata se il segreto simmetrico o il certificato pubblico non vengono archiviati nelle posizioni menzionate sopra o se i dati archiviati nel segreto non sono validi.
    • ncp/jwt-token:
      • È possibile configurare un solo elemento in quest'annotazione.
      • _arg_<param_name>: Per JWT passato come parametro URI. Specificare il nome del parametro che contiene JWT.
      • _cookie_<cookie_name>: Per JWT passato come cookie. Specificare il nome del cookie che contiene JWT.
  • Informazioni sulle annotazioni ncp/connection_multiplxing_enabled e ncp/connection_multiplxing_number:
    • TCP Multiplexing non può coesistere con HTTP NTLM. In NSX, se un pool di bilanciamento del carico con TCP Multiplexing abilitato è associato a un server di livello 7 abilitato per NTLM, la configurazione NTLM avrà la precedenza su TCP Multiplexing.
    • Esempio YAML:
      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    ncp/connection_multiplexing_enabled: "true"
    ncp/connection_multiplexing_number: 100
spec:
  tls:
  - hosts:
    - cafe.example.com
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Errori

Nella risorsa in ingresso vengono annotati gli errori. La chiave di errore è ncp/error.loadbalancer e la chiave di avviso è ncp/warning.loadbalancer. Il possibile errore e avviso sono:
  • ncp/error.loadbalancer: DEFAULT_BACKEND_IN_USE

    Quest'errore indica che esiste già un ingresso con un back-end predefinito. L'ingresso sarà inattivo. Quest'errore si verificherà se (1) quest'ingresso è per HTTP e esiste un altro ingresso per HTTP con un back-end predefinito; (2) Quest'ingresso è per HTTPS e un altro ingresso per HTTPS con un back-end predefinito esiste già; o (3) quest'ingresso è per HTTP e HTTPS e un altro ingresso per HTTP e HTTPS con un back-end predefinito. Per correggere l'errore, eliminare e ricreare l'ingresso con una specifica corretta.

  • ncp/warning.loadbalancer: SECRET_NOT_FOUND

    Quest'errore indica che il segreto specificato nella specifica in uscita non esiste o se ncp/jwt-alg e ncp/jwt-secret sono annotati ma il segreto non può essere trovato nello stesso spazio dei nomi dell'ingresso. Il punto di uscita sarà parzialmente attivo. Per correggere l'errore, creare il segreto mancante. Da notare che una volta visualizzato un avviso nell'annotazione, l'avviso non sarà cancellato durante il ciclo di vita della risorsa in ingresso.

  • ncp/warning.loadbalancer: INVALID_INGRESS
    Quest'errore indica che una delle seguenti condizioni è vera. L'ingresso sarà inattivo. Per correggere l'errore, eliminare e ricreare l'ingresso con una specifica corretta.
    • Una regola d' ingresso è in conflitto con un'altra regola di uscita nello stesso cluster Kubernetes. I conflitti vengono determinati solo per gli ingressi con la stessa strategia di corrispondenza, ossia lo stesso valore di annotazione ncp/use-regex.
    • L'annotazione kubernetes.io/ingress.allow-http è impostata su false e non è presente una sezione TLS in ingresso.
    • L'annotazione ncp/http-redirect è impostata su true e non è presente una sezione TLS in ingresso.
    • Una regola di ingresso non dispone del host e path specificato. Tale regola di ingresso ha le stesse funzionalità del back-end predefinito in ingresso. Utilizzare invece il back-end predefinito in ingresso.
    • Ingresso include annotazioni JWL che non possono essere elaborate correttamente. Ad esempio:
      • Manca ncp/jwt-alg o ncp/jwt-secret.
      • ncp/jwt-alg è configurato con un algoritmo non supportato.
      • ncp/jwt-alg e ncp/jwt-secret sono configurati con altre annotazioni di abilitazione HTTP o con passthrough SSL.