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 cloud pubblico

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

Il diagramma seguente mostra come un controller Ingress dirige il traffico di rete da Internet a 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 della rotta all'hostname del bilanciatore di carico VPC assegnato ai servizi per il controller di ingresso. Nei cluster VPC, gli indirizzi IP esterni dei servizi del controller di Ingress sono fluttuanti e vengono mantenuti dietro un hostname assegnato al VPC.

3. Il bilanciatore di carico VPC risolve l'hostname VPC con un indirizzo IP esterno disponibile di un servizio di controller di Ingress segnalato come sano. Il bilanciatore di carico VPC controlla continuamente gli indirizzi IP esterni dei servizi che espongono il controller di ingresso in ogni zona del cluster.

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

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

6. Quando l'applicazione restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo worker in cui è presente il controller di Ingress che ha inoltrato la richiesta del client. Il controller di ingresso invia quindi il pacchetto di risposta al client attraverso 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 con il solo endpoint del servizio cloud privato, per impostazione predefinita viene creato un controller di ingresso privato. Il controller Ingress assegna percorsi accessibili privatamente per le applicazioni e ascolta l'interfaccia di rete privata dell'host. Solo i client connessi alla tua rete VPC privata possono accedere alle applicazioni esposte da un instradamento privato.

Il diagramma seguente mostra come un controller Ingress dirige il traffico di rete dalle reti private a 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 della rotta all'hostname del bilanciatore di carico VPC assegnato ai servizi per il controller di ingresso. Nei cluster VPC, gli indirizzi IP dei servizi del controller di Ingress sono fluttuanti e vengono mantenuti dietro un hostname assegnato al 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 VPC privato risolve l'hostname VPC con un indirizzo IP privato disponibile di un servizio di controller Ingress segnalato come sano. Il bilanciatore di carico VPC controlla continuamente gli indirizzi IP dei servizi che espongono il controller di ingresso in ogni zona del cluster.

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

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

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

Impostazione di rotte pubbliche in cluster classici o in cluster VPC con un endpoint di servizio cloud pubblico

Se il cluster viene creato su un'infrastruttura classica o se il cluster viene creato su un'infrastruttura VPC e si è abilitato l'endpoint del servizio cloud pubblico durante la creazione del cluster, il cluster viene creato con un controller Ingress pubblico per impostazione predefinita. È possibile utilizzare questo controllore Ingress per creare rotte pubbliche per la propria applicazione.

1. Crea un servizio ClusterIP Kubernetes per la distribuzione della tua applicazione. Il servizio fornisce un indirizzo IP interno per l'applicazione 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. Ottenere l'indirizzo IP pubblico del servizio pubblico del controllore di ingresso in ciascuna zona nella colonna EXTERNAL-IP. Si noti che il servizio di controller Ingress nella prima zona in cui sono presenti nodi lavoratori si chiama sempre router-default, mentre i servizi di controller Ingress nelle zone aggiunte successivamente al cluster hanno nomi come 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. Mappare il dominio personalizzato all'indirizzo IP pubblico del controller di Ingress, aggiungendo l'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 un hostname di rotta 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:

     oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
     

     Devi gestire le connessioni HTTP/2? Dopo aver creato la rotta, eseguire oc edit route <app_service_name> e modificare il valore targetPort della rotta in https. È possibile testare il percorso eseguendo curl -I --http2 https://<route> --insecure.
   • Bordo: se si utilizza un dominio personalizzato, includere le opzioni --hostname, --cert, --key e, facoltativamente, l'opzione --ca-cert. Per ulteriori informazioni sui requisiti del certificato TLS, consultare la documentazione del percorso edge Red Hat OpenShift.

     oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • Crittografare 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 del certificato TLS, consultare la documentazione sulla crittografia ripetuta del percorso Red Hat OpenShift.

     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, puoi utilizzare le annotazioni route - specific HAProxy.

Impostazione di rotte pubbliche in cluster VPC con un endpoint di servizio solo per il 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 con un router privato per impostazione predefinita. Per esporre pubblicamente le vostre applicazioni, dovete prima creare una risorsa pubblica IngressController e configurarla con un sottodominio. L'operatore Ingress crea e configura automaticamente un nuovo controllore Ingress pubblico basato su IngressController, che si può usare per creare rotte pubbliche per le proprie applicazioni.

Si noti che, anche se nei passaggi successivi si crea una risorsa IngressController, IngressController deve solo creare e configurare il controller di Ingress necessario. Dopo che il controllore Ingress è stato creato, puoi utilizzare direttamente il controllore Ingress per creare le rotte.

1. Preparare il dominio che si desidera utilizzare per il controller di 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, copiare il sottodominio che ha il valore più alto 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 ha il valore 000<n> più alto di 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 copiato, modificare il valore 000<n> nel sottodominio in 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. Creare la risorsa IngressController nello spazio dei nomi openshift-ingress-operator del cluster. Quando si crea IngressController,, un controllore Ingress pubblico viene creato automaticamente e distribuito nello spazio dei nomi 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. Registrare il nome host del servizio VPC con il dominio 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 con il servizio 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
      

   2. Aggiungi i selettori ai controller Ingress in cui vuoi utilizzare la frammentazione.

      oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
      

   3. 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.

      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.

7. Crea un servizio ClusterIP Kubernetes per la distribuzione della tua applicazione. Il servizio fornisce un indirizzo IP interno per l'applicazione 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 della rotta viene generato nel formato <app_service_name>-<app_project>.<router-subdomain>.

   • Semplice:

     oc expose service <app_service_name> [--hostname <subdomain>]
     

   • Passthrough:

     oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
     

     Devi gestire le connessioni HTTP/2? Dopo aver creato la rotta, eseguire oc edit route <app_service_name> e modificare il valore targetPort della rotta in https. È possibile testare il percorso eseguendo curl -I --http2 https://<route> --insecure.
   • Bordo: se si utilizza un dominio personalizzato, includere le opzioni --hostname, --cert, --key e, facoltativamente, l'opzione --ca-cert. Per ulteriori informazioni sui requisiti del certificato TLS, consultare la documentazione del percorso edge Red Hat OpenShift.

     oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • Crittografare 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 del certificato TLS, consultare la documentazione sulla crittografia ripetuta del percorso Red Hat OpenShift.

     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, puoi utilizzare le annotazioni route - specific HAProxy.

11. Per creare percorsi per più applicazioni utilizzando lo stesso sottodominio, è possibile ripetere i passaggi da 7 a 10 in modo che il percorso sia generato dallo stesso controller pubblico di Ingress. Se si desidera creare percorsi per più applicazioni utilizzando un sottodominio diverso, ripetere tutti i passaggi di questa sezione per creare un nuovo controller Ingress pubblico con un dominio diverso.

Impostazione di rotte private in cluster classici o in cluster VPC con un endpoint di servizio cloud pubblico

Se il cluster viene creato su un'infrastruttura classica o se il cluster viene creato su un'infrastruttura VPC e si è abilitato l'endpoint del servizio cloud pubblico durante la creazione del cluster, per impostazione predefinita il cluster viene creato solo con un controller di ingresso pubblico. Per esporre privatamente le applicazioni, occorre prima creare una risorsa privata IngressController e configurare il controllore con un sottodominio. L'operatore Ingress crea e configura automaticamente un nuovo controller Ingress privato, che può essere utilizzato per creare percorsi privati per le applicazioni.

Si noti che anche se si crea una risorsa IngressController nei passaggi successivi, la risorsa IngressController è necessaria solo per creare e configurare il controller di Ingress necessario. Dopo che il controller Ingress è stato creato, utilizzi il router direttamente per creare gli instradamenti.

1. Preparare il dominio che si desidera utilizzare per il controller di 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, copiare il sottodominio che ha il valore più alto 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 ha il valore 000<n> più alto di 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 copiato, modificare il valore 000<n> nel sottodominio in 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. Creare la risorsa IngressController nello spazio dei nomi openshift-ingress-operator del cluster. Quando si crea la risorsa IngressController, viene automaticamente creato un controllore Ingress privato e distribuito nello spazio dei nomi openshift-ingress, in base alle impostazioni di IngressController. Inoltre, viene creato un servizio di controller Ingress per esporre il controller Ingress con un indirizzo IP (cluster classici) o un hostname 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 classico o VPC: Collaborate con il vostro provider DNS per aggiungere l'indirizzo IP esterno del servizio come record A (cluster classici) o l'hostname VPC come CNAME (cluster VPC) che corrisponde al vostro dominio personalizzato.
   • IBM-dominio fornito, solo cluster VPC: Creare una voce DNS per il nome host del servizio VPC. Quando si esegue il comando seguente, il sottodominio specificato al punto 2 viene generato automaticamente e registrato con il servizio 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
      

   2. Aggiungi i selettori ai controller Ingress in cui vuoi utilizzare la frammentazione.

      oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
      

   3. 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.

      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 fornisce un indirizzo IP interno per l'applicazione 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:

     oc create route passthrough --service <app_service_name> --hostname <subdomain>
     

     Devi gestire le connessioni HTTP/2? Dopo aver creato la rotta, eseguire oc edit route <app_service_name> e modificare il valore targetPort della rotta in https. È possibile testare il percorso eseguendo curl -I --http2 https://<route> --insecure.
   • Bordo: se si utilizza un dominio personalizzato, includere le opzioni --cert e --key e, facoltativamente, l'opzione --ca-cert. Per ulteriori informazioni sui requisiti del certificato TLS, consultare la documentazione del percorso edge Red Hat OpenShift.

     oc create route edge --service <app_service_name> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • Crittografare nuovamente: Se si utilizza un dominio personalizzato, includere le opzioni --cert e --key e, facoltativamente, l'opzione --ca-cert. Per ulteriori informazioni sui requisiti del certificato TLS, consultare la documentazione sulla crittografia ripetuta del percorso Red Hat OpenShift.

     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, puoi utilizzare le annotazioni route - specific HAProxy.

11. Per creare percorsi per più applicazioni utilizzando lo stesso sottodominio, è possibile ripetere i passaggi da 7 a 10 in modo che il percorso sia generato dallo stesso controller Ingress privato. Se si desidera creare percorsi per più app utilizzando un sottodominio diverso, ripetere tutti i passaggi di questa sezione per creare un nuovo controller Ingress privato.

Impostazione di rotte private in cluster VPC con un solo endpoint di servizio cloud privato

Se il cluster è stato creato su un'infrastruttura VPC e si è abilitato l'unico endpoint del servizio cloud privato durante la creazione del cluster, il cluster viene creato con un controller Ingress privato per impostazione predefinita. È possibile utilizzare questo controller Ingress per creare percorsi privati per la propria applicazione.

1. Crea un servizio ClusterIP Kubernetes per la distribuzione della tua applicazione. Il servizio fornisce un indirizzo IP interno per l'applicazione 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 avete bisogno di un dominio personalizzato, viene generato un sottodominio di percorso 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. Ottenere l'indirizzo IP esterno per il servizio di controller di ingresso privato in ciascuna zona nella colonna EXTERNAL-IP. Si noti che il servizio di controller Ingress nella prima zona in cui sono presenti nodi lavoratori si chiama sempre router-default, mentre i servizi di controller Ingress nelle zone aggiunte successivamente al cluster hanno nomi come 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. Mappare il dominio personalizzato all'indirizzo IP privato dei servizi del controller di Ingress aggiungendo gli indirizzi IP come record A.

3. Impostare un percorso in base al tipo di terminazione TLS richiesta dall'applicazione. Se non hai un dominio personalizzato, non includere l'opzione --hostname. Viene generato 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:

     oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
     

     Devi gestire le connessioni HTTP/2? Dopo aver creato la rotta, eseguire oc edit route <app_service_name> e modificare il valore targetPort della rotta in https. È possibile testare il percorso eseguendo curl -I --http2 https://<route> --insecure.

   • Bordo: se si utilizza un dominio personalizzato, includere le opzioni --hostname, --cert, --key e, facoltativamente, l'opzione --ca-cert. Per ulteriori informazioni sui requisiti del certificato TLS, consultare la documentazione del percorso edge Red Hat OpenShift.

     oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
     

   • Crittografare 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 del certificato TLS, consultare la documentazione sulla crittografia ripetuta del percorso Red Hat OpenShift.

     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, puoi utilizzare le annotazioni route - specific HAProxy.