Pubblicazione di app con percorsi in Red Hat OpenShift 4

Flusso del traffico in un cluster classico a zona singola

Il seguente diagramma mostra in che modo un router indirizza il traffico di rete da internet a un'applicazione in un cluster classico a zona singola.

1. Una richiesta alla tua applicazione utilizza il nome host dell'instradamento che hai configurato per la tua applicazione.

2. Un servizio DNS risolve il dominio secondario nell'indirizzo IP pubblico portatile del servizio router.

3. Il router riceve la richiesta e la inoltra all'indirizzo IP privato del pod dell'applicazione sulla rete privata. L'indirizzo IP di origine del pacchetto di richieste viene modificato nell'indirizzo IP pubblico del nodo di lavoro su cui viene eseguito il pod router. Se nel cluster vengono distribuite più istanze dell'applicazione, il router invia le richieste tra i pod dell'applicazione.

4. Quando l'applicazione restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo di lavoro in cui è presente il router che ha inoltrato la richiesta client. Il router invia quindi il pacchetto di risposta tramite il servizio del programma di bilanciamento del carico al client.

Flusso del traffico in un cluster classico multizona

Il seguente diagramma mostra in che modo un router indirizza il traffico di rete da internet a un'applicazione in un cluster classico multizona.

1. Una richiesta alla tua applicazione utilizza il nome host dell'instradamento che hai configurato per la tua applicazione.

2. Un servizio DNS risolve il dominio secondario di instradamento nell'indirizzo IP pubblico portatile di un servizio router che è stato segnalato come integro da MZLB (multizone load balancer). MZLB controlla continuamente gli indirizzi IP pubblici portatili dei servizi che espongono il router in ciascuna zona del tuo cluster. Le richieste vengono gestite dai servizi router in varie zone in un ciclo round-robin.

3. In base all'indirizzo IP risolto del servizio router, il router riceve la richiesta.

4. Il router inoltra la richiesta all'indirizzo IP privato del pod dell'applicazione sulla rete privata. L'indirizzo IP di origine del pacchetto di richieste viene modificato nell'indirizzo IP pubblico del nodo di lavoro su cui viene eseguito il pod router. Ogni router invia le richieste alle istanze dell'applicazione nella propria zona e alle istanze dell'applicazione in altre zone. Inoltre, se più istanze dell'applicazione vengono distribuite in una zona, il router alterna le richieste tra i pod dell'applicazione.

5. Quando l'applicazione restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo di lavoro in cui è presente il router che ha inoltrato la richiesta client. Il router invia quindi il pacchetto di risposta tramite il servizio del programma di bilanciamento del carico al client.

Flusso di traffico in un cluster VPC multizona con un endpoint di servizio nel cloud pubblico

Quando si crea un cluster VPC multizona con l'endpoint del servizio cloud pubblico abilitato, viene creato per impostazione predefinita un controller Ingress pubblico. Il controller Ingress assegna percorsi accessibili pubblicamente alle tue app e ascolta le richieste rivolte alle tue app sull'interfaccia di rete pubblica dell'host.

Il diagramma seguente illustra come un controller Ingress indirizzi il traffico di rete proveniente da Internet verso un'applicazione in un cluster VPC multizona.

1. Una richiesta alla tua applicazione utilizza il nome host dell'instradamento che hai configurato per la tua applicazione.

2. Un servizio DNS risolve il sottodominio "route" nell'hostname del bilanciatore di carico VPC assegnato ai servizi per il controller Ingress. Nei cluster VPC, gli indirizzi IP esterni dei servizi del controller Ingress sono fluttuanti e vengono gestiti tramite un nome host assegnato dal VPC.

3. Il bilanciatore di carico VPC risolve il nome host VPC in un indirizzo IP esterno disponibile di un servizio di controller Ingress che è stato segnalato come funzionante. Il bilanciatore di carico VPC verifica costantemente gli indirizzi IP esterni dei servizi che espongono il controller Ingress in ciascuna zona del cluster.

4. In base all'indirizzo IP identificato, il bilanciatore di carico VPC invia la richiesta a un servizio di controller Ingress.

5. Il controller Ingress inoltra la richiesta all'indirizzo IP privato del pod dell'app tramite la rete privata. L'indirizzo IP di origine del pacchetto di richiesta viene modificato in modo da corrispondere all'indirizzo IP del nodo worker su cui è in esecuzione il pod del controller Ingress. Ogni controller di Ingress invia richieste alle istanze dell'app presenti nella propria zona e a quelle presenti in altre zone. Inoltre, se in una zona sono distribuite più istanze dell'app, il controller Ingress alterna le richieste tra i pod dell'app.

6. Quando l'app restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo worker su cui si trova il controller Ingress che ha inoltrato la richiesta del client. Il controller Ingress invia quindi il pacchetto di risposta al client tramite il bilanciatore di carico VPC.

Flusso di traffico in un cluster VPC multizona con un solo endpoint di servizio cloud privato

Quando si crea un cluster VPC multizona utilizzando esclusivamente l'endpoint del servizio cloud privato, viene creato per impostazione predefinita un controller Ingress privato. Il controller Ingress assegna percorsi accessibili in modo privato alle tue app e rimane in ascolto sull'interfaccia di rete dell'host privato. Solo i client connessi alla tua rete VPC privata possono accedere alle applicazioni esposte da un instradamento privato.

Il diagramma seguente illustra come un controller Ingress indirizzi il traffico di rete proveniente da reti private verso un'applicazione in un cluster VPC multizona.

1. Un client connesso alla tua rete VPC privata invia una richiesta alla tua applicazione utilizzando l'instradamento privato dell'applicazione. Ad esempio, potresti utilizzare la VPN Virtual Private Cloud, IBM Cloud Transit Gateway o IBM Cloud Direct Link per consentire le richieste da una rete in loco, da un altro VPC o dall'infrastruttura classica IBM Cloud alle applicazioni che vengono eseguite nel tuo cluster.

2. Un servizio DNS risolve il sottodominio "route" nell'hostname del bilanciatore di carico VPC assegnato ai servizi per il controller Ingress. Nei cluster VPC, gli indirizzi IP dei servizi del controller Ingress sono fluttuanti e vengono gestiti tramite un nome host assegnato dal VPC. Tieni presente che sebbene il record DNS per il dominio secondario di instradamento sia registrato nel sistema DNS pubblico, i server di risoluzione DNS sono raggiungibili dal VPC.

3. Il bilanciatore di carico privato della VPC risolve il nome host della VPC in un indirizzo IP privato disponibile di un servizio di controller Ingress che è stato segnalato come funzionante. Il bilanciatore di carico VPC verifica costantemente gli indirizzi IP dei servizi che espongono il controller Ingress in ciascuna zona del cluster.

4. In base all'indirizzo IP identificato, il bilanciatore di carico VPC invia la richiesta a un servizio di controller Ingress.

5. Il controller Ingress inoltra la richiesta all'indirizzo IP privato del pod dell'app tramite la rete privata. L'indirizzo IP di origine del pacchetto di richiesta viene modificato in modo da corrispondere all'indirizzo IP del nodo worker su cui è in esecuzione il pod del controller Ingress. Ogni controller di Ingress invia richieste alle istanze dell'app presenti nella propria zona e a quelle presenti in altre zone. Inoltre, se in una zona sono distribuite più istanze dell'app, il controller Ingress alterna le richieste tra i pod dell'app.

6. Quando l'app restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo worker su cui si trova il controller Ingress che ha inoltrato la richiesta del client. Il controller Ingress invia quindi il pacchetto di risposta al client passando attraverso il bilanciatore di carico VPC e attraverso la VPN " IBM Cloud VPC ", Transit Gateway o Direct Link.

Configurazione di percorsi pubblici nei cluster classici o nei cluster VPC con un endpoint di servizio cloud pubblico

Se il cluster è stato creato su un'infrastruttura classica, oppure se è stato creato su un'infrastruttura VPC e durante la creazione del cluster è stato abilitato l'endpoint del servizio cloud pubblico, il cluster viene creato per impostazione predefinita con un controller Ingress pubblico. Puoi utilizzare questo controller Ingress per creare percorsi pubblici per la tua app.

1. Crea un servizio ClusterIP Kubernetes per la distribuzione della tua applicazione. Il servizio assegna all'app un indirizzo IP interno a cui il controller Ingress può inviare il traffico.

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. Scegli un dominio per la tua applicazione. Nota che gli URL di instradamento devono avere una lunghezza massima di 130 caratteri IBM: se non hai bisogno di utilizzare un dominio personalizzato, viene generato un nome host di instradamento nel formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Dominio personalizzato: per specificare un dominio personalizzato, collabora con il tuo provider DNS o IBM Cloud® Internet Services.

   1. Recupera l'indirizzo IP pubblico del servizio del controller Ingress pubblico in ciascuna zona nella colonna EXTERNAL-IP. Si noti che il servizio controller Ingress nella prima zona in cui sono presenti i nodi worker è sempre denominato router-default, mentre i servizi controller Ingress nelle zone aggiunte successivamente al cluster hanno nomi del tipo router-dal12.

       oc get svc -n openshift-ingress
       ```
   1. Crea un dominio personalizzato con il tuo provider DNS.
           Se vuoi utilizzare lo stesso dominio secondario per più servizi nel tuo cluster, puoi registrare un dominio secondario jolly, come ad esempio `*.example.com`.
   {: tip}
   
   1. Associa il tuo dominio personalizzato all'indirizzo IP pubblico del controller Ingress aggiungendo tale indirizzo IP come record A.
   
   

3. Configura un instradamento basato sul tipo di terminazione TLS richiesto dalla tua applicazione. Se non hai un dominio personalizzato, non includere l'opzione --hostname. Viene generato automaticamente un nome host di route nel formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Se hai registrato un dominio secondario jolly, specifica un dominio secondario univoco in ogni instradamento che crei. Ad esempio, potresti specificare --hostname svc1.example.com in questo instradamento e --hostname svc2.example.com in un altro instradamento.

   • Semplice:

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * Passthrough:
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
       ```
       Devi gestire le connessioni HTTP/2? Dopo aver creato la route, esegui il comando ` `oc edit route <app_service_name>` ` e modifica il valore ` `targetPort` ` della route in ` `https``. È possibile testare il percorso eseguendo il comando `curl -I --http2 https://<route> --insecure`.
   * Suggerimento: se utilizzi un dominio personalizzato, includi le opzioni `--hostname`, `--cert` e `--key` e, facoltativamente, l'opzione `--ca-cert`. Per ulteriori informazioni sui requisiti relativi al certificato " TLS ", consultare la [documentazione relativa alla rotta edge " Red Hat OpenShift "](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Crittografia nuovamente: se si utilizza un dominio personalizzato, includere le opzioni `--hostname`, `--cert` e `--key` e, facoltativamente, l'opzione `--ca-cert`. Per ulteriori informazioni sui requisiti relativi al certificato " TLS ", consultare la [documentazione relativa alla procedura di ricrittografia " Red Hat OpenShift "](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

4. Verifica che l'instradamento per il tuo servizio dell'applicazione sia stato creato.

   oc get routes
   

5. Opzionale: Personalizzare le regole di routing predefinite con configurazioni opzionali. Ad esempio, è possibile utilizzare annotazioni HAProxy specifiche per la rotta.

Configurazione di percorsi pubblici nei cluster VPC utilizzando esclusivamente un endpoint di servizio cloud privato

Se il cluster è stato creato su un'infrastruttura VPC e durante la creazione del cluster è stato abilitato solo l'endpoint del servizio cloud privato, per impostazione predefinita il cluster verrà creato con un solo router privato. Per rendere pubbliche le tue app, devi prima creare una risorsa pubblica IngressController e configurarla con un sottodominio. L'operatore Ingress crea e configura automaticamente un nuovo controller Ingress pubblico basato sul IngressController, che è possibile utilizzare per creare percorsi pubblici per le proprie app.

Si noti che, sebbene nei passaggi seguenti si crei una risorsa IngressController, l' IngressController è necessario solo per creare e configurare il controller Ingress richiesto. Dopo che il controllore Ingress è stato creato, puoi utilizzare direttamente il controllore Ingress per creare le rotte.

1. Prepara il dominio che desideri utilizzare per il tuo controller Ingress.

   • Dominio personalizzato: per registrare un dominio personalizzato, collabora con il tuo provider DNS (Domain Name Service) o il DNS IBM Cloud. Se vuoi utilizzare lo stesso dominio secondario per più servizi nel tuo cluster, puoi registrare un dominio secondario jolly, come ad esempio *.example.com. Se si utilizza un dominio personalizzato, è necessario specificare anche il certificato di dominio nella propria specifica IngressController. Per ulteriori informazioni, vedi Impostazione di un certificato predefinito personalizzato
   • Dominio fornito da IBM:
     1. Elenca i domini secondari esistenti nel tuo cluster. Nella colonna " Sottodominio " dell'output, copia il sottodominio che presenta il valore più alto di " 000<n> ".

        ibmcloud oc nlb-dns ls --cluster CLUSTER_NAME_OR_ID
        

        In questo esempio di output, il sottodominio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud presenta il valore di 000<n> più elevato, pari a 0002.

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        

     2. Nel sottodominio che hai copiato, modifica il valore 000<n> sostituendolo con 000<n+1>. Ad esempio, il sottodominio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud viene modificato in mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. Registrerai questo dominio secondario nei passi successivi.

2. Crea un file YAML che configura un controller Ingress pubblico con il dominio dal passo 1.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: public
     namespace: openshift-ingress-operator
   spec:
     # defaultCertificate: If you are using a custom domain, specify the domain certificate
       # name: custom-certs-default
     replicas: 2
     domain: <domain>
     endpointPublishingStrategy:
       loadBalancer:
         scope: External
       type: LoadBalancerService
   

3. Crea la risorsa IngressController nello spazio dei nomi openshift-ingress-operator del tuo cluster. Quando si crea l' IngressController,, viene automaticamente creato e distribuito un controller Ingress pubblico nel namespace openshift-ingress in base alle impostazioni di IngressController. Inoltre, viene creato un servizio controller Ingress per esporre il controllore Ingress.

   oc create -f public.yaml -n openshift-ingress-operator
   

4. Ottieni il nome host VPC nel campo EXTERNAL IP del servizio router-public. Nei cluster VPC, gli indirizzi IP esterni dei tuoi servizi router sono mobili e vengono invece mantenuti dietro un nome host assegnato dal VPC.

   oc get svc router-public -n openshift-ingress
   

   Output di esempio

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
   router-public                LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
   

5. Registra il nome host VPC del servizio con il dominio che hai scelto al punto 1. Questo passo garantisce che gli indirizzi IP dei servizi del tuo controller Ingress, che sono conservati dietro il nome host VPC, siano registrati con il dominio che hai scelto per il controller Ingress.

   • Dominio personalizzato: collabora con il tuo provider DNS per aggiungere il nome host VPC del servizio come CNAME che viene associato al tuo dominio personalizzato.
   • Dominio fornito da IBM: crea una voce DNS per il nome host VPC del servizio. Quando si esegue il comando seguente, il sottodominio specificato al punto 2 viene generato automaticamente e registrato nel servizio del controller Ingress.

       ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
       ```
   

6. Facoltativo: se vuoi utilizzare la frammentazione del controller Ingress in modo che specifici instradamenti siano gestiti da un controller Ingress specifico, ad esempio gli instradamenti privati sono ammessi solo a un router privato, puoi utilizzare le etichette di instradamento o le etichette dello spazio dei nomi per specificare il metodo di frammentazione. Per aggiungere il selettore durante il tempo di creazione, includilo nello yaml ingresscontroller in spec. Ad esempio, per consentire a un controller Ingress di gestire solo ingress / instradamenti con etichetta type=sharded, puoi aggiungere un routeSelector. Per ulteriori informazioni, vedi frammentazione del controller Ingress.

     routeSelector:
       matchLabels:
         type: sharded
   

   1. Per aggiungere i selettori a un controller Ingress esistente, ottieni un elenco di controller Ingress.

       oc get ingresscontroller -n openshift-ingress-operator
       ```
   1. Aggiungi i selettori ai controller Ingress in cui vuoi utilizzare la frammentazione.
   
   ```sh {: pre}
       oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
       ```
   
   1. Si noti che non vengono aggiunti selettori al IngressController, quindi tutte le rotte sono ancora ammesse al controllore Ingress predefinito del cluster. È possibile utilizzare l'instradamento pertinente o un selettore di etichetta dello spazio dei nomi per modificare questo comportamento. Ad esempio, per regolare il router predefinito per ignorare ingress / routes con etichetta `type=sharded`, esegui il seguente comando patch.
   ```sh {: pre}
       oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
       ```
       Diverse rotte e ingressi sul cluster dipendono dal controller di ingresso pubblico predefinito. Assicurarsi che le modifiche siano corrette prima di modificare il controllore Ingress predefinito. Per ulteriori informazioni, vedi [frammentazione del controller Ingress](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/networking_overview/index#nw-ingress-sharding_configuring-ingress){: external}.
       {: note}
   
   
   

7. Crea un servizio ClusterIP Kubernetes per la distribuzione della tua applicazione. Il servizio assegna all'app un indirizzo IP interno a cui il controller Ingress può inviare il traffico.

   oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
   

8. Configura un instradamento basato sul tipo di terminazione TLS richiesto dalla tua applicazione. Se non si include l'opzione --hostname, il nome host del percorso viene generato automaticamente nel formato <app_service_name>-<app_project>.<router-subdomain>.

   • Semplice:

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * Passthrough:
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
       ```
       Devi gestire le connessioni HTTP/2? Dopo aver creato la route, esegui il comando ` `oc edit route <app_service_name>` ` e modifica il valore ` `targetPort` ` della route in ` `https``. È possibile testare il percorso eseguendo il comando `curl -I --http2 https://<route> --insecure`.
   * Suggerimento: se utilizzi un dominio personalizzato, includi le opzioni `--hostname`, `--cert` e `--key` e, facoltativamente, l'opzione `--ca-cert`. Per ulteriori informazioni sui requisiti relativi al certificato " TLS ", consultare la [documentazione relativa alla rotta edge " Red Hat OpenShift "](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Crittografia nuovamente: se si utilizza un dominio personalizzato, includere le opzioni `--hostname`, `--cert` e `--key` e, facoltativamente, l'opzione `--ca-cert`. Per ulteriori informazioni sui requisiti relativi al certificato " TLS ", consultare la [documentazione relativa alla procedura di ricrittografia " Red Hat OpenShift "](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

9. Verifica che l'instradamento per la tua applicazione sia stato creato.

   oc get routes
   

10. Facoltativo: personalizza le regole di instradamento del controller Ingress pubblico con configurazioni facoltative. Ad esempio, è possibile utilizzare annotazioni HAProxy specifiche per la rotta.

11. Per creare percorsi per altre app utilizzando lo stesso sottodominio, è possibile ripetere i passaggi da 7 a 10 in modo che il percorso venga generato dallo stesso controller Ingress pubblico. Se desideri creare percorsi per altre app utilizzando un sottodominio diverso, ripeti tutti i passaggi descritti in questa sezione per creare un nuovo controller Ingress pubblico con un dominio diverso.

Configurazione di percorsi privati nei cluster classici o nei cluster VPC con un endpoint di servizio cloud pubblico

Se il cluster è stato creato su un'infrastruttura classica, oppure se è stato creato su un'infrastruttura VPC e durante la creazione del cluster è stato abilitato l'endpoint del servizio cloud pubblico, per impostazione predefinita il cluster viene creato con un solo controller Ingress pubblico. Per rendere accessibili le tue app in modalità privata, devi prima creare una risorsa " IngressController " privata e configurare il controller con un sottodominio. L'operatore Ingress crea e configura automaticamente un nuovo controller Ingress privato, che puoi utilizzare per creare percorsi privati per le tue app.

Si noti che, sebbene nei passaggi seguenti si crei una risorsa IngressController, la risorsa IngressController è necessaria solo per creare e configurare il controller Ingress richiesto. Dopo che il controller Ingress è stato creato, utilizzi il router direttamente per creare gli instradamenti.

1. Prepara il dominio che desideri utilizzare per il tuo controller Ingress.

   • Dominio personalizzato, cluster classici o VPC: per registrare un dominio personalizzato, collabora con il tuo provider DNS (Domain Name Service) o il DNS IBM Cloud. Se vuoi utilizzare lo stesso dominio secondario per più servizi nel tuo cluster, puoi registrare un dominio secondario jolly, come ad esempio *.example.com.
   • Dominio fornito da IBM, solo cluster VPC:
     1. Elenca i domini secondari esistenti nel tuo cluster. Nella colonna " Sottodominio " dell'output, copia il sottodominio che presenta il valore più alto di " 000<n> ".

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        In questo esempio di output, il sottodominio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud presenta il valore di 000<n> più elevato, pari a 0002.

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        

     2. Nel sottodominio che hai copiato, modifica il valore 000<n> sostituendolo con 000<n+1>. Ad esempio, il sottodominio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud viene modificato in mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. Registrerai questo dominio secondario nei passi successivi.

2. Crea un file di configurazione che configura un controller Ingress privato con il dominio dal passo 1.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: private
     namespace: openshift-ingress-operator
   spec:
     replicas: 2
     domain: <domain>
     endpointPublishingStrategy:
       loadBalancer:
         scope: Internal
       type: LoadBalancerService
   

3. Crea la risorsa IngressController nello spazio dei nomi openshift-ingress-operator del tuo cluster. Quando si crea la risorsa IngressController, viene automaticamente creato e distribuito un controller Ingress privato nello spazio dei nomi openshift-ingress, in base alle impostazioni specificate in IngressController. Inoltre, viene creato un servizio di controller Ingress per rendere accessibile il controller Ingress tramite un indirizzo IP (cluster classici) o un nome host VPC (cluster VPC).

   oc create -f private.yaml -n openshift-ingress-operator
   

4. Ottieni l'indirizzo IP o il nome host VPC nel campo EXTERNAL IP del servizio router-private.

   oc get svc router-private -n openshift-ingress
   

   Output di esempio per i cluster classici:

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
   router-private               LoadBalancer   172.21.57.132    10.XX.XX.XX    80/TCP,443/TCP,1940/TCP      3m
   

   Output di esempio per i cluster VPC:

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
   router-private               LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
   

5. Registra l'indirizzo IP esterno o il nome host VPC del servizio con il dominio che hai scelto nel passo 1.

   • Dominio personalizzato, cluster classici o VPC: rivolgiti al tuo provider DNS per aggiungere l'indirizzo IP esterno del servizio come record A (cluster classici) oppure il nome host VPC come record CNAME (cluster VPC) che rimandi al tuo dominio personalizzato.
   • IBM- Solo per i cluster VPC con dominio fornito: creare una voce DNS per il nome host VPC del servizio. Quando si esegue il comando seguente, il sottodominio specificato al punto 2 viene generato automaticamente e registrato nel servizio del controller Ingress.

       ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
       ```
   

6. Facoltativo: se vuoi utilizzare la frammentazione del controller Ingress in modo che specifici instradamenti siano gestiti da un controller Ingress specifico, ad esempio gli instradamenti privati sono ammessi solo a un router privato, puoi utilizzare le etichette di instradamento o le etichette dello spazio dei nomi per specificare il metodo di frammentazione. Per aggiungere il selettore durante il tempo di creazione, includilo nello yaml ingresscontroller in spec. Ad esempio, per consentire a un controller Ingress di gestire solo ingress / instradamenti con etichetta type=sharded, puoi aggiungere un routeSelector. Per ulteriori informazioni, vedi frammentazione del controller Ingress.

     routeSelector:
       matchLabels:
         type: sharded
   

   1. Per aggiungere i selettori a un controller Ingress esistente, ottieni un elenco di controller Ingress.

       oc get ingresscontroller -n openshift-ingress-operator
       ```
   1. Aggiungi i selettori ai controller Ingress in cui vuoi utilizzare la frammentazione.
   
   ```sh {: pre}
       oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
       ```
   
   1. Si noti che non vengono aggiunti selettori al IngressController, quindi tutte le rotte sono ancora ammesse al controllore Ingress predefinito del cluster. È possibile utilizzare l'instradamento pertinente o un selettore di etichetta dello spazio dei nomi per modificare questo comportamento. Ad esempio, per regolare il router predefinito per ignorare ingress / routes con etichetta `type=sharded`, esegui il seguente comando patch.
   ```sh {: pre}
       oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
       ```
   

7. Crea un servizio ClusterIP Kubernetes per la distribuzione della tua applicazione. Il servizio assegna all'app un indirizzo IP interno a cui il controller Ingress può inviare il traffico.

   oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
   

8. Configura un instradamento basato sul tipo di terminazione TLS richiesto dalla tua applicazione. Specificare il nome host impostato nel passo 5.

   • Semplice:

       oc expose service <app_service_name> --hostname <subdomain>
       ```
   * Passthrough:
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> --hostname <subdomain>
       ```
       Devi gestire le connessioni HTTP/2? Dopo aver creato la route, esegui il comando ` `oc edit route <app_service_name>` ` e modifica il valore ` `targetPort` ` della route in ` `https``. È possibile testare il percorso eseguendo il comando `curl -I --http2 https://<route> --insecure`.
   * Suggerimento: se utilizzi un dominio personalizzato, includi le opzioni `--cert` e `--key` e, facoltativamente, l'opzione `--ca-cert`. Per ulteriori informazioni sui requisiti relativi al certificato " TLS ", consultare la [documentazione relativa alla rotta edge " Red Hat OpenShift "](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route edge --service <app_service_name> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Ricrittografa: se utilizzi un dominio personalizzato, includi le opzioni `--cert` e `--key` e, facoltativamente, l'opzione `--ca-cert`. Per ulteriori informazioni sui requisiti relativi al certificato " TLS ", consultare la [documentazione relativa alla procedura di ricrittografia " Red Hat OpenShift "](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

9. Verifica che l'instradamento per la tua applicazione sia stato creato.

   oc get routes
   

10. Facoltativo: personalizza le regole di instradamento del controller Ingress privato con configurazioni facoltative. Ad esempio, è possibile utilizzare annotazioni HAProxy specifiche per la rotta.

11. Per creare percorsi per altre app utilizzando lo stesso sottodominio, è possibile ripetere i passaggi da 7 a 10 in modo che il percorso venga generato dallo stesso controller Ingress privato. Se desideri creare percorsi per altre app utilizzando un sottodominio diverso, ripeti tutti i passaggi descritti in questa sezione per creare un nuovo controller Ingress privato.

Configurazione di percorsi privati nei cluster VPC utilizzando esclusivamente un endpoint di servizio cloud privato

Se il cluster è stato creato su un'infrastruttura VPC e durante la creazione del cluster è stato abilitato solo l'endpoint del servizio cloud privato, il cluster viene creato per impostazione predefinita con un controller Ingress privato. Puoi utilizzare questo controller Ingress per creare percorsi privati per la tua app.

1. Crea un servizio ClusterIP Kubernetes per la distribuzione della tua applicazione. Il servizio assegna all'app un indirizzo IP interno a cui il controller Ingress può inviare il traffico.

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. Scegli un dominio per la tua applicazione.

   • IBM- Dominio fornito: se non hai bisogno di un dominio personalizzato, ti verrà generato automaticamente un sottodominio di Route nel formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.
   • Dominio personalizzato: per specificare un dominio personalizzato, collabora con il tuo provider DNS o IBM Cloud® Internet Services.

     1. Recupera l'indirizzo IP esterno del servizio del controller Ingress privato in ciascuna zona nella colonna EXTERNAL-IP. Si noti che il servizio controller Ingress nella prima zona in cui sono presenti i nodi worker è sempre denominato router-default, mentre i servizi controller Ingress nelle zone aggiunte successivamente al cluster hanno nomi del tipo router-dal12.

        oc get svc -n openshift-ingress
        

     2. Crea un dominio personalizzato con il tuo provider DNS. Se vuoi utilizzare lo stesso dominio secondario per più servizi nel tuo cluster, puoi registrare un dominio secondario jolly, come ad esempio *.example.com.

     3. Associa il tuo dominio personalizzato all'indirizzo IP privato dei servizi del controller Ingress aggiungendo gli indirizzi IP come record A.

3. Configura un percorso in base al tipo di terminazione TLS richiesta dalla tua app. Se non hai un dominio personalizzato, non includere l'opzione --hostname. Viene generato automaticamente un sottodominio di percorso nel formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Se hai registrato un dominio secondario jolly, specifica un dominio secondario univoco in ogni instradamento che crei. Ad esempio, potresti specificare --hostname svc1.example.com in questo instradamento e --hostname svc2.example.com in un altro instradamento.

   • Semplice:

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * Passthrough:
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
       ```
       Devi gestire le connessioni HTTP/2? Dopo aver creato la route, esegui il comando ` `oc edit route <app_service_name>` ` e modifica il valore ` `targetPort` ` della route in ` `https``. È possibile testare il percorso eseguendo il comando `curl -I --http2 https://<route> --insecure`.
   
   * Suggerimento: se utilizzi un dominio personalizzato, includi le opzioni `--hostname`, `--cert` e `--key` e, facoltativamente, l'opzione `--ca-cert`. Per ulteriori informazioni sui requisiti relativi al certificato " TLS ", consultare la [documentazione relativa alla rotta edge " Red Hat OpenShift "](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Crittografia nuovamente: se si utilizza un dominio personalizzato, includere le opzioni `--hostname`, `--cert` e `--key` e, facoltativamente, l'opzione `--ca-cert`. Per ulteriori informazioni sui requisiti relativi al certificato " TLS ", consultare la [documentazione relativa alla procedura di ricrittografia " Red Hat OpenShift "](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

4. Verifica che l'instradamento per il tuo servizio dell'applicazione sia stato creato.

   oc get routes
   

5. Opzionale: Personalizzare le regole di routing predefinite con configurazioni opzionali. Ad esempio, è possibile utilizzare annotazioni HAProxy specifiche per la rotta.