Network Load Balancer for VPC

Nei cluster VPC, configurare un layer-4 Network Load Balancer for VPC (VPC NLB) in ciascuna zona del cluster, affinché funga da punto di ingresso esterno per le richieste in entrata destinate a un'applicazione.

Gli NLB VPC forniscono diversi vantaggi, come fornire una maggiore velocità di trasmissione e prestazioni migliori utilizzando il DSR (direct server return). Con il DSR, il nodo di lavoro può inviare pacchetti di risposta dell'applicazione direttamente all'indirizzo IP del client e ignorare l'NLB VPC, diminuendo la quantità di traffico che l'NLB VPC deve gestire. Inoltre, l'NLB VPC supporta la conservazione dell'indirizzo IP di origine su tutte le richieste client per impostazione predefinita.

• I nomi NLB VPC standard hanno un formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Per visualizzare l'ID del cluster, esegui il comando ibmcloud oc cluster get --cluster <cluster_name>``. Per visualizzare l'UID del servizio LoadBalancer Kubernetes, esegui oc get svc myloadbalancer -o yaml e cerca il campo metadata.uid nell'output. Nel nome VPC NLB, i trattini (-) vengono rimossi dall'UID del servizio Kubernetes LoadBalancer.

• I nomi NLB VPC permanenti hanno un formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Per visualizzare l'ID del cluster, esegui il comando ibmcloud oc cluster get --cluster <cluster_name>``. Per visualizzare l'UID del servizio LoadBalancer Kubernetes, esegui oc get svc myloadbalancer -o yaml e cerca il campo metadata.uid nell'output. Nel nome VPC NLB, i trattini (-) vengono rimossi dall'UID del servizio Kubernetes LoadBalancer.

• Quando crei un servizio Kubernetes LoadBalancer per un'applicazione nel tuo cluster e includi l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb", viene creato un NLB VPC nel tuo VPC all'esterno del tuo cluster. Il VPC NLB instrada le richieste destinate alla tua app attraverso le porte private NodePorts che vengono aperte automaticamente sui tuoi nodi di lavoro.

• Se crei un servizio pubblico Kubernetes LoadBalancer, puoi accedere alla tua applicazione da Internet tramite l'indirizzo IP pubblico esterno assegnato dall'NLB VPC al servizio Kubernetes LoadBalancer. Anche se i nodi di lavoro sono collegati solo a una sottorete VPC privata, il VPC NLB è in grado di ricevere e instradare le richieste pubbliche verso il servizio che espone l'applicazione. Si noti che non è necessario alcun gateway pubblico sulla sottorete VPC per consentire le richieste pubbliche al VPC NLB. Tuttavia, se la tua applicazione deve accedere a un URL pubblico, devi collegare i gateway pubblici alle sottoreti VPC a cui sono connessi i tuoi nodi di lavoro.

• Se crei un servizio ** Kubernetes **privatoLoadBalancer, la tua applicazione è accessibile solo ai sistemi che sono connessi alle tue sottoreti private all'interno della stessa regione e dello stesso VPC. Se sei connesso alla tua rete VPC privata, puoi accedere alla tua applicazione tramite l'indirizzo IP privato esterno assegnato dall'NLB VPC al servizio LoadBalancer Kubernetes.

Il diagramma seguente illustra come un utente accede a un’app da Internet tramite il VPC NLB.

1. Una richiesta alla tua app utilizza l'indirizzo IP esterno assegnato al servizio Kubernetes LoadBalancer dal VPC NLB.
2. La richiesta viene inoltrata automaticamente dal VPC NLB a una delle porte del nodo sul nodo di lavoro e, successivamente, all'indirizzo IP privato del pod dell'applicazione.
3. Se le istanze dell'applicazione vengono distribuite su più nodi di lavoro all'interno del cluster, il VPC NLB instrada le richieste tra i pod dell'applicazione presenti sui vari nodi di lavoro in tutte le zone del cluster.

Application Load Balancer for VPC

Configurare un bilanciamento del carico a livello di applicazione ( layer-7, VPC ALB) multizona Application Load Balancer for VPC (VPC ALB) che funga da punto di ingresso esterno per le richieste in entrata destinate a un’applicazione nel proprio cluster.

Non confondere l’ Application Load Balancer for VPC con i bilanciatori di carico delle applicazioni Ingress Red Hat OpenShift on IBM Cloud. I bilanciatori di carico delle applicazioni per VPC (VPC ALB) vengono eseguiti all’esterno del cluster, all’interno della VPC, e sono configurati dai servizi Kubernetes LoadBalancer creati dall’utente. I programmi di bilanciamento del carico delle applicazioni Ingress(ALB) sono controller Ingress che vengono eseguiti sui nodi di lavoro nel cluster.

• I nomi ALB VPC hanno un formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Per visualizzare l'ID del cluster, esegui il comando ibmcloud oc cluster get --cluster <cluster_name>``. Per visualizzare l'UID del servizio LoadBalancer Kubernetes, esegui oc get svc myloadbalancer -o yaml e cerca il campo metadata.uid nell'output. Nel nome dell'ALB VPC vengono rimossi i trattini (-) dall'UID del servizio Kubernetes LoadBalancer.

• Per impostazione predefinita, quando si crea un servizio Kubernetes LoadBalancer per un’app nel proprio cluster, viene creato un Application Load Balancer for VPC nella propria VPC al di fuori del cluster. L'ALB VPC instrada le richieste verso la tua app attraverso le porte private NodePorts, che vengono aperte automaticamente sui tuoi nodi di lavoro.

• Se si crea un servizio pubblico Kubernetes LoadBalancer, è possibile accedere all'app da Internet tramite il nome host assegnato dall'ALB VPC al servizio Kubernetes LoadBalancer nel formato 1234abcd-<region>.lb.appdomain.cloud. Anche se i tuoi nodi di lavoro sono collegati solo a una sottorete VPC privata, l'ALB VPC può ricevere e instradare le richieste pubbliche verso il servizio che espone la tua app. Si noti che non è necessario alcun gateway pubblico sulla sottorete VPC per consentire le richieste pubbliche al proprio ALB VPC. Tuttavia, se la tua applicazione deve accedere a un URL pubblico, devi collegare i gateway pubblici alle sottoreti VPC a cui sono connessi i tuoi nodi di lavoro.

• Se crei un servizio ** Kubernetes **privatoLoadBalancer, la tua applicazione è accessibile solo ai sistemi che sono connessi alle tue sottoreti private all'interno della stessa regione e dello stesso VPC. Se sei connesso alla tua rete VPC privata, puoi accedere alla tua app tramite il nome host assegnato dall’ALB della VPC al servizio Kubernetes LoadBalancer nel formato 1234abcd-<region>.lb.appdomain.cloud.

Il diagramma seguente illustra come un utente accede a un'app da Internet tramite l'ALB della VPC.

1. Una richiesta alla tua app utilizza il nome host assegnato al servizio Kubernetes LoadBalancer dal VPC ALB, ad esempio 1234abcd-<region>.lb.appdomain.cloud.
2. La richiesta viene inoltrata automaticamente dall'ALB VPC a una delle porte del nodo sul nodo di lavoro e, successivamente, all'indirizzo IP privato del pod dell'applicazione.
3. Se le istanze dell'applicazione vengono distribuite a più nodi di lavoro nel cluster, il programma di bilanciamento del carico instrada le richieste tra i pod dell'applicazione su vari nodi di lavoro. Inoltre, se si dispone di un cluster multizona, l'ALB VPC instrada le richieste ai nodi di lavoro in tutte le sottoreti e le zone del cluster.

Configurazione di un NLB utilizzando un intervallo di porta

Gli intervalli di porta possono essere utilizzati negli NLB pubblici quando è necessario ospitare un servizio da un singolo nome host che ha più applicazioni di backend, ciascuna in ascolto su un numero di porta separato. Per utilizzare gli intervalli di porte nel cluster Kubernetes, è necessario eseguire alcune configurazioni manuali. Per prima cosa, l'opzione ibm-load-balancer-cloud-provider-vpc-port-range deve essere impostata. Può includere uno o più intervalli, ognuno delimitato da una virgola. Il valore spec.ports.port deve essere impostato anche sul valore minimo nell'intervallo di porta.

Nel seguente esempio, viene utilizzato un intervallo di porte di 30000-30010.

I servizi Nodeport devono essere creati manualmente per ogni distribuzione in cui il servizio NLB inoltra la richiesta. Il numero di porta di ciascuno di questi servizi Nodeport deve essere compreso nell'intervallo di porte configurato nel servizio NLB.

Nel seguente diagramma di esempio, un servizio Nodeport con porta 30000 viene creato per la distribuzione 1 mentre un servizio Nodeport con porta 30001 viene creato per la distribuzione 2.

L'utente effettua una richiesta alla porta 30001 dell'NLB contenente l'intervallo di porta. Questa richiesta è indirizzata al servizio NLB VPC che indirizza la richiesta al servizio Nodeport nel cluster che è anche in ascolto sulla porta 30001, che in questo caso è per la distribuzione 2. Il servizio Nodeport indirizza quindi la richiesta alla porta di destinazione dei pod selezionati di Deployment 2.

Crea un NLB che utilizza un intervallo di porta utilizzando il seguente esempio. Il selettore e i pod di backend devono essere associati al servizio del programma di bilanciamento del carico dell'intervallo di porte in modo che i controlli di integrità restituiscano l'esito positivo e i dati vengano consegnati alle porte nell'intervallo di porta. Per utilizzare l'intervallo di porte, devi creare ulteriori servizi NodePort che hanno valori di porta nell'intervallo definito dal servizio del programma di bilanciamento del carico.

1. Salvare la seguente configurazione LoadBalancer di esempio come un file denominato loadbalancer.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-port-range: 30000-30010
     name: nlb-port-range
   spec:
     externalTrafficPolicy: Cluster
     ports:
     - port: 30000 # Must match min from the port range
       protocol: TCP
       nodePort: 30011 # Can be port in range or not
       targetPort: 8080
     selector:
       app: echo-server  # Must be valid for health checks to work
     type: LoadBalancer
   

2. Crea il servizio.

   oc apply -f loadbalancer.yaml
   

3. Crea un servizio NodePort con valori di porta che si trovano nell'intervallo di porta specificato nel LoadBalancer che hai creato in precedenza.

   apiVersion: v1
   kind: Service
   metadata:
     name: echo-server-node-port
   spec:
     ports:
     - port: 80
       protocol: TCP # The protocol of the port range
       nodePort: 30003 # Node port in the port range
       targetPort: 8080
     selector:
       app: echo-server
     type: NodePort
   

4. Crea il servizio " NodePort ".

   oc apply -f nodeport.yaml
   

5. Per accedere a una porta compresa nell'intervallo fornito da NLB.

   curl https://<public ip assigned to NLB>:30003
   

   • 30003 = È una porta nodo nell'intervallo che risponde alla richiesta
   • Le altre porte nell'intervallo non rispondono a meno che non vengano creati ulteriori servizi porta del nodo.

Configurazione di un NLB VPC privato

Rendi la tua app accessibile al traffico di rete privato configurando un servizio Kubernetes LoadBalancer in ciascuna zona del tuo cluster. Quando si crea il servizio Kubernetes LoadBalancer, viene automaticamente creata una VPC NLB ( Network Load Balancer for VPC ) privata all'interno della propria VPC, al di fuori del cluster, che instrada le richieste verso l'applicazione.

Prima di iniziare

• Assicurati di disporre del Writer o del Manager IBM Cloud ruolo di accesso del servizio IAM per lo spazio dei nomi in cui distribuisci il servizio Kubernetes LoadBalancer per l'NLB VPC.
• Connettiti alla tua rete privata VPC, ad esempio tramite una connessione VPN VPC.
• Accedi al tuo cluster Red Hat OpenShift.
• Per visualizzare gli NLB VPC, installa il plug-in infrastructure-service. Il prefisso per l'esecuzione dei comandi è ibmcloud is.

  ibmcloud plugin install infrastructure-service
  

Per consentire alla tua app di ricevere richieste di rete privata,

1. Crea una sottorete VPC dedicata al tuo NLB VPC. Questa sottorete deve esistere nello stesso VPC e nella stessa ubicazione del tuo cluster, ma non può essere collegata al tuo cluster o a qualsiasi nodo di lavoro.

   1. Dalla dashboard delle sottoreti VPC, fare clic su " Nuova sottorete ".
   2. Immetti un nome per la tua sottorete.
   3. Selezionare l'ubicazione in cui si trova il cluster e la zona in cui si desidera creare l'NLB VPC.
   4. Seleziona il nome del VPC in cui si trova il tuo cluster.
   5. Specifica il numero di indirizzi IP da creare. Poiché questa sottorete è dedicata all'NLB VPC, potresti scegliere una dimensione più piccola, come ad esempio 16. Non è possibile modificare in un secondo momento il numero di indirizzi IP di una sottorete VPC. Se si immette un intervallo di indirizzi IP specifico, evitare di utilizzare i seguenti intervalli riservati: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 e 172.20.0.0/16.
   6. Fai clic su Create subnet. Una volta eseguito il provisioning della sottorete, prendi nota del suo ID.

2. Se il client che deve connettersi alla tua applicazione tramite l'NLB VPC esiste al di fuori del VPC e della zona in cui hai creato la sottorete VPC dedicata, devi creare una tabella di instradamento ingresso personalizzata. Gli NLB VPC privati potrebbero aggiungere regole alla tabella di instradamento personalizzata per garantire la disponibilità del servizio per alcune condizioni di malfunzionamento. Per ulteriori informazioni, vedi la tabella nelle limitazioni note e Informazioni sulle tabelle di instradamento e sugli instradamenti.

   1. Dal dashboard delle tabelle di instradamento VPC, fai clic su Crea.
   2. Immettere un nome per la tabella di instradamento.
   3. Seleziona l'ubicazione e la zona in cui hai creato la sottorete dedicata.
   4. Seleziona il nome del VPC in cui esiste la tua sottorete.
   5. Per il Tipo di traffico, seleziona Ingress.
   6. A seconda di dove il client accede alla tua applicazione, scegli un' Origine del traffico. Per ulteriori informazioni sulla configurazione delle connessioni alla tua rete privata VPC, vedi la documentazione per scegliere la VPN IBM Cloud VPC, Transit Gatewayo Direct Link per la connettività VPC.
      • Rete in loco: Direct link
      • Un'altra infrastruttura VPC o classica: Transit gateway
      • Un'altra zona all'interno dello stesso VPC: zona VPC

3. Distribuisci la tua applicazione al cluster. Assicurati di aggiungere un'etichetta nella sezione dei metadati del tuo file di configurazione della distribuzione. Questa etichetta personalizzata identifica tutti i pod su cui viene eseguita la tua applicazione per includerli nel bilanciamento del carico.

4. Crea un file YAML di configurazione per il tuo servizio Kubernetes LoadBalancer. Considerare la denominazione del servizio nel formato <app_name>-vpc-nlb-<VPC_zone>.

   apiVersion: v1
   kind: Service
   metadata:
     name: <app_name>-vpc-nlb-<VPC_zone>
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp: "<tcp_port"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
     type: LoadBalancer
     selector:
       <selector_key>: <selector_value>
     ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"

   Facoltativo. Includi un nome univoco per rendere persistente il tuo programma di bilanciamento del carico VPC. I programmi di bilanciamento del carico VPC persistenti non vengono eliminati quando viene eliminato il cluster a cui appartengono. Per ulteriori informazioni, vedi Programmi di bilanciamento del carico VPC persistenti.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"

   Obbligatorio: l'annotazione per creare un NLB VPC.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"

   Obbligatorio: annotazione per specificare un servizio che accetta richieste private.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

   Obbligatorio: l'annotazione per specificare la sottorete dedicata in cui viene distribuito l'NLB VPC. Il valore può essere specificato come ID sottorete VPC, nome sottorete VPC o CIDR sottorete VPC. È necessario specificare una sola sottorete. La sottorete deve esistere nello stesso VPC del tuo cluster e in una zona in cui il tuo cluster ha nodi di lavoro, ma nessun nodo di lavoro può essere collegato a questa sottorete. I nodi di lavoro che esistono nella stessa zona di questa sottorete sono configurati per ricevere il traffico dall'NLB VPC. Per visualizzare le sottoreti in tutti i gruppi di risorse, esegui ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone>.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

   Facoltativo: annotazione per specificare un selettore di etichetta del nodo di lavoro. All'interno della stessa zona della sottorete dedicata per l'NLB VPC, puoi configurare specifici nodi di lavoro per ricevere il traffico selezionando una delle chiavi del selettore di etichetta supportate. Si noti che è possibile includere solo un selettore di etichetta nell'annotazione e che il selettore deve essere specificato nel formato "key=value". Se questa annotazione non è specificata, tutti i nodi di lavoro nella stessa zona della sottorete VPC che hai specificato nell'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets sono configurati per ricevere il traffico dall'NLB VPC. Se specificato, tutte le etichette dedicated: edge sui nodi di lavoro vengono ignorate.

   Le seguenti chiavi sono consentite. - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp

   Facoltativo: specificare una porta del nodo TCP da utilizzare per i controlli di integrità dell' TCP in un bilanciatore di carico UDP. Obbligatorio per i bilanciatori di carico UDP in cui l'opzione " externalTrafficPolicy " è impostata su " Cluster". Per ulteriori considerazioni prima di impostare un valore di porta, consultare la sezione “Configurazione dei controlli di integrità di TCP per i bilanciatori di carico UDP ”.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

   Facoltativo: questa annotazione imposta il protocollo di controllo dell'integrità nella risorsa del programma di bilanciamento del carico VPC associata al servizio del programma di bilanciamento del carico Kubernetes. Normalmente, il protocollo di controllo dell'integrità del LB VPC è determinato dal valore dell'impostazione externalTrafficPolicy nella specifica del servizio del programma di bilanciamento del carico Kubernetes. Questa annotazione sovrascrive tale logica. Questa annotazione non modifica il funzionamento di Kubernetes, e in particolare di kube - proxy, in relazione alle diverse impostazioni di externalTrafficPolicy.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

   Facoltativo. La porta dell' TCP e utilizzata per i controlli di integrità. Questa annotazione si applica solo se è specificato anche ibm-load-balancer-cloud-provider-vpc-health-check-protocol.

   • Se la porta TCP specificata non rientra nell'intervallo di porte dei nodi Kubernetes (30.000-32.767), è necessario modificare il gruppo di sicurezza VPC applicato ai nodi di lavoro del cluster per consentire il traffico in entrata su tale porta.
   • Se questa annotazione viene applicata a un servizio di bilanciamento del carico di tipo " Kubernetes " associato a un VPC ALB, è necessario modificare le regole in uscita del gruppo di sicurezza assegnato al VPC ALB per consentire il traffico in uscita verso la porta TCP specificata.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

   Facoltativo. Il percorso "Health check URL " per i controlli di integrità HTTP e HTTPS. Questa annotazione si applica solo se ibm-load-balancer-cloud-provider-vpc-health-check-protocol è impostato su http o https.

   • Il percorso URL deve avere il formato di una destinazione di richiesta in forma di origine.
   • Se questa annotazione non è specificata e l'annotazione ibm-load-balancer-cloud-provider-vpc-health-check-protocol è impostata su http o https, viene applicato il valore predefinito /.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

   Facoltativo. Il numero di secondi di attesa tra i tentativi di controllo di integrità. Per impostazione predefinita, questo valore è impostato su 5 e ha un minimo di 2 e un massimo di 60. Questo valore deve essere maggiore del valore ibm-load-balancer-cloud-provider-vpc-health-check-timeout, che per impostazione predefinita è impostato su 2.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

   Facoltativo. Il numero di secondi di attesa per una risposta a un controllo di integrità. Per impostazione predefinita, questo valore è impostato su 2 e ha un minimo di 1 e un massimo di 59. Questo valore deve essere inferiore a ibm-load-balancer-cloud-provider-vpc-health-check-delay, che per impostazione predefinita è impostato su 5.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

   Il numero massimo di tentativi di controllo di integrità per il programma di bilanciamento del carico VPC. Per impostazione predefinita, questo valore è impostato su 2 e ha un minimo di 1 e un massimo di 10.

   selector

   La chiave dell'etichetta (<selector_key>) e il valore (<selector_value>) che hai utilizzato nella sezione " spec.template.metadata.labels " del file YAML di distribuzione della tua app. Questa etichetta personalizzata identifica tutti i pod su cui viene eseguita la tua applicazione per includerli nel bilanciamento del carico.

   port

   La porta su cui è in ascolto il servizio.

   targetPort

   Facoltativo: la porta verso cui il servizio indirizza il traffico. L'applicazione in esecuzione nel pod deve essere in ascolto del traffico in entrata proveniente dall' TCP su questa porta di destinazione. La porta di destinazione è spesso definita staticamente nell'immagine in esecuzione nel pod dell'applicazione. La porta di destinazione configurata nel pod è diversa dalla porta del nodo per il servizio e potrebbe anche essere diversa dalla porta esterna configurata sull'LB VPC.

   externalTrafficPolicy

   Obbligatorio. Specificare Local O Cluster.

   Impostato Local per preservare l'indirizzo IP di origine delle richieste dei client alle tue app. Questa impostazione impedisce l'inoltro del traffico in entrata a un altro nodo. Questa opzione configura anche i controlli di integrità di HTTP.

   Se Cluster è impostato, DSR viene implementato solo dal nodo di lavoro a cui l'NLB VPC inoltra inizialmente la richiesta in entrata. Dopo l'arrivo della richiesta in entrata, la richiesta viene inoltrata a un nodo di lavoro contenente il pod dell'applicazione, che potrebbe trovarsi in una zona diversa. La risposta dal pod dell'applicazione viene inviata al nodo di lavoro originale e tale nodo di lavoro utilizza DSR per inviare la risposta direttamente al client, ignorando l'NLB VPC. Questa opzione configura anche i controlli di integrità di TCP. Per i bilanciatori di carico di tipo “ UDP ”, è necessario il file “ service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp ” se si sceglie l’opzione “ Cluster ”. Per ulteriori informazioni, consultare la sezione " Configurazione dei controlli di integrità di TCP per i bilanciatori di carico UDP ".

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

   Facoltativo. Il numero di nodi worker per zona a cui il bilanciatore di carico esegue il percorso. Il valore predefinito è 8. Per un cluster con nodi worker in tre zone, il risultato è che il bilanciatore di carico esegue il routing su 24 nodi worker totali. Il numero totale di nodi worker in tutte le zone verso cui il bilanciatore di carico esegue il percorso non può superare i 50. Se il cluster ha meno di 50 nodi worker in tutte le zone, specificare 0 per instradare a tutti i nodi worker in una zona.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

   Facoltativo. Un gruppo di sicurezza gestito dal cliente da aggiungere al bilanciatore di carico VPC. Se non si desidera utilizzare il gruppo di sicurezza IBM gestito, specificare un gruppo di sicurezza di cui si è proprietari e che si gestisce. Questa opzione rimuove il gruppo di sicurezza gestito da IBM e lo sostituisce con il gruppo di sicurezza specificato. La rimozione dell'annotazione da un bilanciatore di carico esistente sostituisce il gruppo di sicurezza aggiunto con il gruppo di sicurezza gestito da IBM. È possibile aggiungere o rimuovere questa annotazione in qualsiasi momento. L'utente è responsabile della gestione del proprio gruppo di sicurezza e del suo aggiornamento.

5. Crea il servizio LoadBalancer Kubernetes nel tuo cluster.

   oc apply -f <filename>.yaml -n <namespace>
   

6. Verifica che il servizio LoadBalancer Kubernetes sia stato creato correttamente nel tuo cluster. Quando il servizio viene creato, il campo Ingresso LoadBalancer viene popolato con un indirizzo IP esterno assegnato dall'NLB VPC.

La configurazione del VPC NLB nella tua VPC richiede alcuni minuti. L'indirizzo IP esterno del servizio Kubernetes LoadBalancer potrebbe essere pending fino al completamento della configurazione del VPC NLB.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
Esempio di output della CLI per un servizio privato `LoadBalancer`:
```sh {: screen}
NAME:                     myvpcnlb
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     10.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
Warning  SyncLoadBalancerFailed           13m (x5 over 15m)    service-controller  Error syncing load balancer: failed to ensure load balancer: kube-bqcssbbd0bsui62odcdg-2d93b07decf641d2ad3f9c2985122ec1 for service default/myvpcnlb is busy: offline/create_pending
Normal   EnsuringLoadBalancer             9m27s (x7 over 15m)  service-controller  Ensuring load balancer
Normal   EnsuredLoadBalancer              9m20s                service-controller  Ensured load balancer
Normal   CloudVPCLoadBalancerNormalEvent  8m17s                ibm-cloud-provider  Event on cloud load balancer myvpcnlb for service default/myvpcnlb with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

7. Verifica che il VPC NLB sia stato creato correttamente nella tua VPC. Nell'output, verificare che il VPC NLB presenti uno stato operativo “ online ” e uno stato di provisioning “ active ”.

   ibmcloud is load-balancers
   

   Nel seguente esempio di output della CLI, viene creato il VPC NLB denominato " kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e " per il servizio " Kubernetes " LoadBalancer:

   ID                                     Name                                                         Created          Host Name                                  Is Public   Listeners                               Operating Status   Pools                                   Private IPs              Provision Status   Public IPs                    Subnets                                Resource Group
   06496f64-a689-4693-ba23-320959b7b677   kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e   8 minutes ago    1234abcd-us-south.lb.appdomain.cloud       no         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.XXX.XXX.XXX           active             -               c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

8. Dalla tua connessione alla rete privata VPC, accedi all'indirizzo IP del servizio Kubernetes LoadBalancer che hai trovato nel passo 6 e alla tua porta dell'applicazione nel formato <external_IP>:<app_port>.

9. Facoltativo: ripeti questi passi per distribuire un NLB VPC privato in ogni zona in cui vuoi esporre la tua applicazione. Quindi, puoi registrare gli indirizzi IP esterni dell'NLB VPC in ogni zona con un dominio secondario DNS.

Registrazione di un record DNS e di un certificato TLS

Gli NLB VPC forniscono indirizzi IP esterni statici tramite i quali puoi accedervi. Per registrare un certificato SSL per il dominio della tua app e supportare HTTPS, puoi creare un sottodominio fornito da IBM oppure utilizzare un dominio personalizzato di tua scelta.

Ad esempio, supponete di avere un cluster multizona ed esegui le repliche della tua applicazione sui nodi di lavoro in ciascuna zona del cluster. crea un NLB VPC per zona per esporre le repliche dell'applicazione. Quindi, puoi registrare gli indirizzi IP esterni forniti da ogni NLB VPC con una voce DNS.

Dopo aver creato un sottodominio DNS per gli NLB VPC, non è possibile utilizzare i comandi nlb-dns health-monitor per creare un controllo di integrità personalizzato. Viene invece utilizzato il controllo di integrità VPC predefinito. Per ulteriori informazioni, consulta la documentazione VPC.

• Crea un NLB VPC per zona per la tua applicazione. Assicurati di definire una porta HTTPS nel servizio Kubernetes LoadBalancer che configura il VPC NLB.
• Per utilizzare il certificato SSL per accedere alla tua applicazione tramite HTTPS, è necessario che la tua applicazione sia in grado di terminare le connessioni TLS.

Per registrare gli indirizzi IP NLB VPC con un dominio secondario DNS,

1. Richiama l'indirizzo IP esterno del tuo programma di bilanciamento del carico.

   oc get svc -o wide
   

   Output di esempio

   NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)            AGE      SELECTOR
   ...
   myapp-vpc-nlb-jp-tok-3    LoadBalancer   172.21.xxx.xxx   169.xx.xxx.xx     8080:30532/TCP     1d       run=webserver
   

2. Crea un dominio secondario DNS personalizzato o fornito da IBMper l'indirizzo IP.

   • Dominio personalizzato:

     1. Registra un dominio personalizzato lavorando con il tuo provider DNS (Domain Name Service) o il DNS IBM Cloud.
     2. Definisci un alias per il tuo dominio personalizzato specificando gli indirizzi IP del programma di bilanciamento del carico come record A.

   • IBM-sottodominio fornito: utilizzare i comandi nlb-dns per generare un sottodominio con un certificato SSL per gli indirizzi IP. IBM Cloud si occupa di generare e gestire per conto dell'utente il certificato wildcard SSL per il sottodominio.

     1. Crea un dominio secondario DNS e un certificato SSL.

        ibmcloud oc nlb-dns create vpc-gen2 --type public --cluster <cluster_name_or_id> --ip <vpc_nlb1_ip> --ip <vpc_nlb2_ip> --ip <vpc_nlb3_ip>
        

     2. Verifica che il dominio secondario sia stato creato. Per ulteriori informazioni, vedi Descrizione del formato del dominio secondario.

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

        Output di esempio

        Subdomain                                                                               IP(s)                                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     169.46.xx.x,169.48.xxx.xx,169.48.xxx.xx      None             created                   <certificate>
        

3. Apri un browser e digita l'indirizzo URL per accedere alla tua app tramite il sottodominio.

Per utilizzare il certificato SSL per accedere alla tua applicazione tramite HTTPS, assicurati di aver definito una porta HTTPS nel tuo servizio LoadBalancer Kubernetes. È possibile verificare che le richieste vengano correttamente instradate attraverso la porta HTTPS eseguendo il comando curl -v --insecure https://<domain>. Un errore di connessione indica che sul servizio non è aperta alcuna porta HTTPS. Inoltre, assicurati che la tua applicazione possa terminare le connessioni TLS. È possibile verificare che l'applicazione si chiuda correttamente TLS eseguendo curl -v https://<domain>. Un errore di certificato indica che la tua applicazione non sta terminando correttamente le connessioni TLS.

Configurazione di un ALB VPC pubblico o privato

Prima di iniziare

• Assicurati di disporre del Writer o del Manager IBM Cloud ruolo di accesso del servizio IAM per lo spazio dei nomi in cui distribuisci il servizio Kubernetes LoadBalancer per l'NLB VPC.
• Accedi al tuo cluster Red Hat OpenShift.
• Per visualizzare gli ALB VPC, installa il plug-in infrastructure-service. Il prefisso per l'esecuzione dei comandi è ibmcloud is.

  ibmcloud plugin install infrastructure-service
  

Per consentire alla tua app di ricevere richieste pubbliche o private,

1. Distribuisci la tua applicazione al cluster. Assicurati di aggiungere un'etichetta nella sezione dei metadati del tuo file di configurazione della distribuzione. Questa etichetta personalizzata identifica tutti i pod su cui viene eseguita la tua applicazione per includerli nel bilanciamento del carico.

2. Crea un file YAML di configurazione per il tuo servizio LoadBalancer Kubernetes e denominalo myloadbalancer.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     name: myloadbalancer
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "<public_or_private>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
    type: LoadBalancer
    selector:
       <selector_key>: <selector_value>
    ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"

   Facoltativo. Includi un nome univoco per rendere persistente il tuo programma di bilanciamento del carico VPC. I programmi di bilanciamento del carico VPC persistenti non vengono eliminati quando viene eliminato il cluster a cui appartengono. Per ulteriori informazioni, vedi Programmi di bilanciamento del carico VPC persistenti.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"

   Facoltativo: abilitare il protocollo PROXY. Il programma di bilanciamento del carico trasmette le informazioni di connessione del client, incluso l'indirizzo IP del client, l'indirizzo IP del server proxy e entrambi i numeri di porta, nelle intestazioni della richiesta alla tua applicazione di back - end. Tieni presente che la tua app di backend deve essere configurata per accettare il protocollo PROXY. Ad esempio, è possibile configurare un'applicazione NGINX in modo che accetti il protocollo PROXY seguendo questi passaggi.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type

   Annotazione per specificare un servizio che accetta le richieste pubbliche o private. Se non si include questa annotazione, viene creato un file pubblico LoadBalancer.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

   Annotazione per specificare un selettore di etichetta del nodo di lavoro. Per identificare i nodi di lavoro che ricevono traffico, puoi selezionare una delle chiavi del selettore di etichetta supportate. Si noti che è possibile includere solo un selettore di etichetta nell'annotazione e che il selettore deve essere specificato nel formato "key=value". Se questa annotazione non viene specificata, tutti i nodi di lavoro nel tuo cluster sono configurati per ricevere il traffico dall'ALB VPC. Se specificata, questa annotazione ha la precedenza sull'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-zone e qualsiasi etichetta dedicated: edge sui nodi di lavoro viene ignorata.

   Sono consentite le seguenti chiavi: - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

   Annotazione per specificare una o più sottoreti in cui il servizio ALB VPC distribuisce. Se specificata, questa annotazione ha la precedenza sull'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-zone. Nota che puoi specificare una sottorete diversa nello stesso VPC rispetto alle sottoreti a cui è collegato il cluster. In questo caso, sebbene l'ALB VPC sia distribuito a una sottorete differente nello stesso VPC, l'ALB VPC può ancora instradare il traffico ai tuoi nodi di lavoro sulle sottoreti del cluster. Per visualizzare le sottoreti in tutti i gruppi di risorse, esegui ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone>.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-zone

   Annotazione per specificare una zona VPC a cui è collegato il tuo cluster. Quando si specifica una zona in questa annotazione, si verificano due processi.

   1. L'ALB VPC viene distribuito nella stessa sottorete di quella zona a cui sono collegati i nodi di lavoro.
   2. Solo i nodi di lavoro del cluster presenti in questa zona sono configurati per ricevere il traffico proveniente dall'ALB della VPC.

   Per visualizzare le zone, esegui il comando ibmcloud oc zone ls --provider vpc-gen2``.

   Per posizionare il programma di bilanciamento del carico in una zona specifica, devi specificare questa annotazione quando crei il programma di bilanciamento del carico. Se successivamente modifichi questa annotazione in una zona diversa, il programma di bilanciamento del carico stesso non viene spostato nella nuova zona. Tuttavia, il programma di bilanciamento del carico viene riconfigurato per inviare traffico solo ai nodi di lavoro nella nuova zona.

   Se l'etichetta dedicated: edge è impostata sui nodi di lavoro e specifichi questa annotazione, solo i nodi edge nella zona specificata sono configurati per ricevere il traffico. I nodi periferici presenti in altre zone e i nodi non periferici presenti nella zona specificata non ricevono traffico dal bilanciatore di carico.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

   Facoltativo: questa annotazione imposta il protocollo di controllo dell'integrità nella risorsa del programma di bilanciamento del carico VPC associata al servizio del programma di bilanciamento del carico Kubernetes. Normalmente, il protocollo di controllo dell'integrità del LB VPC è determinato dal valore dell'impostazione externalTrafficPolicy nella specifica del servizio del programma di bilanciamento del carico Kubernetes. Questa annotazione sovrascrive tale logica. Questa annotazione non modifica il funzionamento di Kubernetes, e in particolare di kube - proxy, in relazione alle diverse impostazioni di externalTrafficPolicy.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

   Facoltativo. La porta dell' TCP e utilizzata per i controlli di integrità. Questa annotazione si applica solo se è specificato anche ibm-load-balancer-cloud-provider-vpc-health-check-protocol.

   • Se la porta TCP specificata non rientra nell'intervallo di porte dei nodi Kubernetes (30.000-32.767), è necessario modificare il gruppo di sicurezza VPC applicato ai nodi di lavoro del cluster per consentire il traffico in entrata su tale porta.
   • Se questa annotazione viene applicata a un servizio di bilanciamento del carico di tipo " Kubernetes " associato a un VPC ALB, è necessario modificare le regole in uscita del gruppo di sicurezza assegnato al VPC ALB per consentire il traffico in uscita verso la porta TCP specificata.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

   Facoltativo. Il percorso "Health check URL " per i controlli di integrità HTTP e HTTPS. Questa annotazione si applica solo se ibm-load-balancer-cloud-provider-vpc-health-check-protocol è impostato su http o https.

   • Il percorso URL deve avere il formato di una destinazione di richiesta in forma di origine.
   • Se questa annotazione non è specificata e l'annotazione ibm-load-balancer-cloud-provider-vpc-health-check-protocol è impostata su http o https, viene applicato il valore predefinito /.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

   Facoltativo. Il numero di secondi di attesa tra i tentativi di controllo di integrità. Per impostazione predefinita, questo valore è impostato su 5 e ha un minimo di 2 e un massimo di 60. Questo valore deve essere maggiore del valore ibm-load-balancer-cloud-provider-vpc-health-check-timeout, che per impostazione predefinita è impostato su 2.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

   Facoltativo. Il numero di secondi di attesa per una risposta a un controllo di integrità. Per impostazione predefinita, questo valore è impostato su 2 e ha un minimo di 1 e un massimo di 59. Questo valore deve essere inferiore a ibm-load-balancer-cloud-provider-vpc-health-check-delay, che per impostazione predefinita è impostato su 5.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

   Il numero massimo di tentativi di controllo di integrità per il programma di bilanciamento del carico VPC. Per impostazione predefinita, questo valore è impostato su 2 e ha un minimo di 1 e un massimo di 10.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout

   Facoltativo. Il timeout di connessione inattiva del listener in secondi. Il timeout di inattività predefinito dipende dalle impostazioni dell'account. Generalmente, questo valore è 50. Tuttavia, alcuni account consentiti hanno impostazioni di timeout più grandi. Se non imposti l'annotazione, i tuoi programmi di bilanciamento del carico utilizzano l'impostazione di timeout nel tuo account. È possibile specificare esplicitamente il timeout impostando questa annotazione. Il minimo è 50. Il valore massimo è 7200.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

   Facoltativo. Può essere applicato solo per ALB VPC privati nella versione4.15 o più tardi. L' instance e DNS da associare a questo bilanciatore di carico. Per ulteriori informazioni, vedere Registrazione di un record DNS privato.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

   Facoltativo. Può essere applicato solo per ALB VPC privati nella versione4.15 o più tardi. L' zone e DNS da associare a questo bilanciatore di carico. Per ulteriori informazioni, vedere Registrazione di un record DNS privato.

   selector

   La chiave dell'etichetta (<selector_key>) e il valore (<selector_value>) che hai utilizzato nella sezione " spec.template.metadata.labels " del file YAML di distribuzione della tua app. Questa etichetta personalizzata identifica tutti i pod su cui viene eseguita la tua applicazione per includerli nel bilanciamento del carico.

   port

   La porta su cui è in ascolto il servizio.

   targetPort

   Facoltativo: la porta verso cui il servizio indirizza il traffico. L'applicazione in esecuzione nel pod deve essere in ascolto del traffico in entrata proveniente dall' TCP su questa porta di destinazione. La porta di destinazione è spesso definita staticamente nell'immagine in esecuzione nel pod dell'applicazione. La porta di destinazione configurata nel pod è diversa dalla porta del nodo per il servizio e potrebbe anche essere diversa dalla porta esterna configurata sull'LB VPC.

   externalTrafficPolicy

   Obbligatorio. Specificare Local o Cluster.

   Impostare su Local per conservare l'indirizzo IP di origine delle richieste dei client alle applicazioni. Questa impostazione impedisce l'inoltro del traffico in entrata a un altro nodo. Questa opzione configura anche i controlli di integrità di HTTP. Per i bilanciatori di carico " UDP ", è necessario il file " service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp " se si sceglie l'opzione " Cluster ". Per ulteriori informazioni, consultare la sezione " Configurazione dei controlli di integrità di TCP per i bilanciatori di carico UDP ".

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

   Facoltativo. Il numero di nodi worker per zona a cui il bilanciatore di carico esegue il percorso. Il valore predefinito è 8. Per un cluster con nodi worker in tre zone, il risultato è che il bilanciatore di carico esegue il routing su 24 nodi worker totali. Il numero totale di nodi worker in tutte le zone verso cui il bilanciatore di carico esegue il percorso non può superare i 50. Se il cluster ha meno di 50 nodi worker in tutte le zone, specificare 0 per instradare a tutti i nodi worker in una zona.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

   Facoltativo. Un gruppo di sicurezza gestito dal cliente da aggiungere al bilanciatore di carico VPC. Se non si desidera utilizzare il gruppo di sicurezza IBM gestito, specificare un gruppo di sicurezza di cui si è proprietari e che si gestisce. Questa opzione rimuove il gruppo di sicurezza gestito da IBM e lo sostituisce con il gruppo di sicurezza specificato. La rimozione dell'annotazione da un bilanciatore di carico esistente sostituisce il gruppo di sicurezza aggiunto con il gruppo di sicurezza gestito da IBM. È possibile aggiungere o rimuovere questa annotazione in qualsiasi momento. L'utente è responsabile della gestione del proprio gruppo di sicurezza e del suo aggiornamento.

3. Crea il servizio LoadBalancer Kubernetes nel tuo cluster.

   oc apply -f myloadbalancer.yaml -n <namespace>
   

4. Verifica che il servizio LoadBalancer Kubernetes sia stato creato correttamente nel tuo cluster. Al momento della creazione del servizio, il campo " LoadBalancer " di Ingress viene compilato con un nome host assegnato dall'ALB della VPC.

L'ALB VPC richiede alcuni minuti per essere configurato nella tua VPC. Non è possibile accedere all'app utilizzando il nome host del servizio Kubernetes LoadBalancer finché l'ALB VPC non sarà stato completamente configurato.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
Output della CLI di esempio per un servizio `LoadBalancer` pubblico:
```sh {: screen}
NAME:                     myvpcalb
Namespace:                default
Labels:                   <none>
Annotations:              
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.XX.XX
LoadBalancer Ingress:     1234abcd-us-south.lb.appdomain.cloud
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  30610/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     31438
Events:
    Type    Reason                           Age   From                Message
----    ------                           ----  ----                -------
Normal  EnsuringLoadBalancer             16m   service-controller  Ensuring load balancer
Normal  EnsuredLoadBalancer              15m   service-controller  Ensured load balancer
Normal  CloudVPCLoadBalancerNormalEvent  13m   ibm-cloud-provider  Event on cloud load balancer myvpcalb for service default/myvpcalb with UID 08cbacf0-2c93-4186-84b6-c4ab88a2faf9: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

5. Verifica che l'ALB della VPC sia stato creato correttamente nella tua VPC. Nell'output, verificare che l'ALB VPC presenti uno stato operativo “ online ” e uno stato di provisioning “ active ”.

   Non rinominare gli ALB VPC creati automaticamente per i servizi di LoadBalancer. Se si rinomina un VPC ALB, Red Hat OpenShift on IBM Cloud crea automaticamente un altro VPC ALB per il servizio LoadBalancer.

   ibmcloud is load-balancers
   

   Nell'esempio seguente di output della CLI, viene creato l'ALB VPC denominato " kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306 " per il servizio " Kubernetes " LoadBalancer:

   ID                                          Name                                                         Family        Subnets               Is public   Provision status   Operating status   Resource group
   r006-d044af9b-92bf-4047-8f77-a7b86efcb923   kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306   Application   mysubnet-us-south-3   true        active             online             default
   

6. Se hai creato un servizio pubblico LoadBalancer, esegui il comando curl specificando il nome host del servizio Kubernetes LoadBalancer assegnato dall'ALB VPC individuato al punto 4. Esempio:

   curl 06496f64-us-south.lb.appdomain.cloud:8080
   

   Output di esempio

   Hello world from hello-world-deployment-5fd7787c79-sl9hn! Your app is up and running in a cluster!
   

   Se hai creato un servizio LoadBalancer privato, devi essere connesso alla tua rete VPC privata per eseguire curl per il nome host.

Non eliminare le sottoreti che hai collegato al tuo cluster durante la sua creazione o quando aggiungi nodi di lavoro in una zona. Se elimini una sottorete VPC utilizzata dal tuo cluster, qualsiasi programma di bilanciamento del carico che utilizza gli indirizzi IP dalla sottorete potrebbe presentare dei problemi e potresti non essere in grado di creare nuovi programmi di bilanciamento del carico.

Gli ALB e gli NLB VPC che non sono associati a cluster di Kubernetes o OpenShift possono essere aggiornati direttamente utilizzando i comandi "ibmcloud is" o la sezione " Infrastruttura VPC " nella console. Ad esempio, modificare la porta di un listener di front - end o il valore di timeout del controllo di integrità. Tuttavia, per i bilanciatori di carico VPC associati a cluster di Kubernetes o OpenShift, eventuali aggiornamenti devono essere effettuati tramite annotazioni nella configurazione di Ingress. Il provider " IBM Cloud " esegue periodicamente la risincronizzazione con tutti gli ALB e gli NLB associati alla VPC, per garantire che il bilanciatore di carico in esecuzione sia conforme alla configurazione prevista da Ingress. Quindi, se effettui delle modifiche a tale programma di bilanciamento del carico direttamente tramite VPC invece di utilizzare le annotazioni Ingress, tali modifiche verranno ripristinate.

Registrazione di un record DNS e di un certificato TLS

L'ALB ( Application Load Balancer for VPC ) di VPC fornisce un nome host predefinito per l' HTTP, nel formato 1234abcd-<region>.lb.appdomain.cloud, tramite il quale è possibile accedere all'applicazione. Tuttavia, se desideri un certificato TLS per il dominio della tua app a supporto di HTTPS, puoi creare un sottodominio fornito da IBM oppure utilizzare un dominio personalizzato sia per gli ALB VPC pubblici che per quelli privati.

Dopo aver creato un sottodominio DNS per un nome host VPC ALB, non è possibile utilizzare i comandi nlb-dns health-monitor per creare un controllo di integrità personalizzato. Viene invece utilizzato il controllo di integrità predefinito del bilanciatore di carico VPC, previsto per il nome host predefinito dell'ALB VPC. Per ulteriori informazioni, consulta la documentazione VPC.

Prima di iniziare

• Imposta un VPC ALB. Assicurati di definire una porta HTTPS nel servizio Kubernetes LoadBalancer che configura l'ALB VPC.
• Per utilizzare il certificato TLS per accedere alla tua app tramite HTTPS, la tua app deve essere in grado di chiudere le connessioni TLS.

Per registrare un nome host ALB VPC con un dominio secondario DNS,

1. Richiama il nome host per il tuo ALB VPC eseguendo il comando get svc. Nell'output, cerca il nome host nella colonna EXTERNAL-IP. Ad esempio, 1234abcd-us-south.lb.appdomain.cloud.

   oc get svc -o wide
   

   Output di esempio

   NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                            PORT(S)     AGE       SELECTOR
   ...
   webserver-lb    LoadBalancer   172.21.xxx.xxx   1234abcd-us-south.lb.appdomain.cloud   8080:30532/TCP     1d       run=webserver
   

2. Creare un sottodominio DNS personalizzato o fornito da IBM per il nome host del bilanciatore di carico.

   • Dominio personalizzato: inserisci il tuo dominio personalizzato e assegnagli un alias specificando l’IP esterno del bilanciatore di carico, nel formato 1234abcd-us-south.lb.appdomain.cloud come record di nome canonico (CNAME).

     1. Registra un dominio personalizzato lavorando con il tuo provider DNS (Domain Name Service) o il DNS IBM Cloud.
     2. Definisci un alias per il tuo dominio personalizzato specificando l'IP esterno del bilanciatore di carico come record di nome canonico (CNAME). Nel seguente esempio, il programma di bilanciamento del carico con l'IP esterno di 1234abcd-us-south.lb.appdomain.cloud è raggiungibile in www.your-custom-domain.com.

     Host / Servizio

     Il prefisso dove vuoi raggiungere la tua applicazione come, www.

     Tipo di risorsa

     Selezionare CNAME.

     TTL

     Selezionare una durata.

     Valore / Destinazione

     L'IP esterno LoadBalancer che hai richiamato in precedenza. Ad esempio 1234abcd-us-south.lb.appdomain.cloud.. Nota che quando utilizzi il DNS IBM Cloud, assicurati di immettere un periodo finale.

   • IBM-sottodominio fornito: utilizzare i comandi nlb-dns per generare un sottodominio con un certificato TLS per il nome host dell'ALB della VPC. IBM Cloud si occupa di generare e gestire per conto dell'utente il certificato TLS con caratteri jolly per il sottodominio.

     1. Crea un sottodominio DNS e un certificato TLS.

        ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_id> --lb-host <vpc_lb_hostname> --type (public|private)
        

     2. Verifica che il dominio secondario sia stato creato. Per ulteriori informazioni, vedi Descrizione del formato del dominio secondario.

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

        Output di esempio

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>
        

3. Se hai creato un sottodominio per un ALB VPC pubblico, apri un browser web e digita l'indirizzo URL per accedere alla tua app tramite il sottodominio, come nell'esempio www.your-custom-domain.com. Se hai creato un sottodominio per un ALB VPC privato, devi essere connesso alla tua rete VPC privata per verificare l'accesso al sottodominio.

Per utilizzare il certificato TLS per accedere alla tua app tramite HTTPS, assicurati di aver definito una porta HTTPS nel tuo servizio Kubernetes LoadBalancer. È possibile verificare che le richieste vengano correttamente instradate attraverso la porta HTTPS eseguendo il comando curl -v --insecure https://<domain>. Un errore di connessione indica che sul servizio non è aperta alcuna porta HTTPS. Inoltre, assicurati che la tua applicazione possa terminare le connessioni TLS. È possibile verificare che l'applicazione si chiuda correttamente TLS eseguendo curl -v https://<domain>. Un errore di certificato indica che la tua applicazione non sta terminando correttamente le connessioni TLS.

Registrazione di un record DNS privato per un ALB VPC privato

Nella versione4.15 o successivamente è possibile utilizzare le seguenti annotazioni opzionali per associare un proprio DNS instance che serve un DNS personalizzato zone con un ALB VPC privato. Per questo è necessario impostare entrambe le annotazioni opzionali. Se non sono specificati, DNS A record per questo bilanciatore del carico hostname La proprietà verrà aggiunta alla zona DNS pubblica lb.appdomain.cloud.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

L' instance e DNS da associare a questo bilanciatore di carico. L'istanza specificata potrebbe trovarsi in una regione o un account diverso, soggetto alle policy IAM. Valori possibili: 9 ≤ lunghezza ≤ 512

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

L' zone e DNS da associare a questo bilanciatore di carico. La zona specificata potrebbe trovarsi in una regione o in un account diverso, soggetto alle policy IAM. Valori possibili: 1 ≤ lunghezza ≤ 128; il valore deve corrispondere all'espressione regolare ^[1]*[a-z0-9]$

È necessario effettuare le seguenti operazioni come prerequisito prima di poter utilizzare questa funzione:

• Crea la zona DNS che può essere associata a un bilanciatore del carico
• Abilita l'autorizzazione da servizio a servizio tra LB VPC eDNS Services
• Aggiungi il VPC del cluster alle reti consentite della zona

Per informazioni dettagliate, consultare i documenti “Integrazione di un bilanciatore di carico delle applicazioni con IBM Cloud DNS Services ” e “Aggiunta di una VPC come rete consentita alla zona DNS ”.

Esempio:

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "crn:v1:bluemix:public:dns-svcs:global:a/bb1b52262f7441a586f49068482f1e60:f761b566-030a-4696-8649-cc9d09889e88::"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "d66662cc-aa23-4fe1-9987-858487a61f45"
spec:
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 169.60.115.164
...

Scollegamento di un programma di bilanciamento del carico VPC da un cluster

I bilanciatori di carico VPC sono associati alla definizione del servizio " Kubernetes " ( LoadBalancer ) con cui sono stati creati. Per scollegare un programma di bilanciamento del carico VPC persistente da un cluster, devi interrompere il link al servizio LoadBalancer per ridenominazione del programma di bilanciamento del carico VPC o rimuovendo l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name dalla definizione del servizio LoadBalancer originale. Puoi anche scollegare un programma di bilanciamento del carico VPC persistente da un cluster eliminandolo.

Se rimuovi l'annotazione, il servizio LoadBalancer originale ripristina e crea un programma di bilanciamento del carico VPC provvisorio nel cluster originale. Questo programma di bilanciamento del carico VPC provvisorio segue la convenzione di denominazione kube-<cluster_ID>-<kubernetes_lb_service_UID>.

Collegamento di un programma di bilanciamento del carico VPC a un cluster

Dopo che un bilanciatore di carico VPC persistente è stato scollegato da un cluster, è possibile collegarlo a un altro cluster creando una nuova definizione del servizio " Kubernetes " ( LoadBalancer ) che faccia riferimento al bilanciatore di carico VPC.

Quando crei un nuovo servizio LoadBalancer nel nuovo cluster, puoi utilizzare l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name per specificare il nome del programma di bilanciamento del carico VPC che vuoi collegare.

Quando crei un servizio LoadBalancer, il tipo di programma di bilanciamento del carico VPC (ALB, NLB) e il tipo IP (pubblico, privato) devono corrispondere alle specifiche nel servizio LoadBalancer. Ad esempio, non è possibile utilizzare un servizio LoadBalancer esistente sul nuovo cluster che specifica un tipo NLB per collegare un ALB VPC al cluster. Le annotazioni che specificano il tipo di programma di bilanciamento del carico e il tipo IP sono rispettivamente service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features e service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type.

Le porte porta e nodo specificate nel servizio LoadBalancer non devono necessariamente corrispondere a quelle con cui è stato creato il programma di bilanciamento del carico VPC. Il programma di bilanciamento del carico VPC riconfigura le definizioni di porta del servizio LoadBalancer a cui è associato nel nuovo cluster.

Personalizzazione dei controlli di integrità per i programmi di bilanciamento del carico VPC

Per un maggiore controllo sui tuoi controlli di integrità del programma di bilanciamento del carico VPC, puoi utilizzare le annotazioni facoltative per personalizzare i tuoi controlli di integrità con configurazioni avanzate per intervalli di test, timeout e tentativi. È possibile modificare o rimuovere tali personalizzazioni in qualsiasi momento.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

Facoltativo: questa annotazione imposta il protocollo di controllo dell'integrità nella risorsa del programma di bilanciamento del carico VPC associata al servizio del programma di bilanciamento del carico Kubernetes. Normalmente, il protocollo di controllo dell'integrità del LB VPC è determinato dal valore dell'impostazione externalTrafficPolicy nella specifica del servizio del programma di bilanciamento del carico Kubernetes. Questa annotazione sovrascrive tale logica. Questa annotazione non modifica il funzionamento di Kubernetes, e in particolare di kube - proxy, in relazione alle diverse impostazioni di externalTrafficPolicy.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

Facoltativo. La porta dell' TCP e utilizzata per i controlli di integrità. Questa annotazione si applica solo se è specificato anche ibm-load-balancer-cloud-provider-vpc-health-check-protocol.

• Se la porta TCP specificata non rientra nell'intervallo di porte dei nodi Kubernetes (30.000-32.767), è necessario modificare il gruppo di sicurezza VPC applicato ai nodi di lavoro del cluster per consentire il traffico in entrata su tale porta.
• Se questa annotazione viene applicata a un servizio di bilanciamento del carico di tipo " Kubernetes " associato a un VPC ALB, è necessario modificare le regole in uscita del gruppo di sicurezza assegnato al VPC ALB per consentire il traffico in uscita verso la porta TCP specificata.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

Facoltativo. Il percorso "Health check URL " per i controlli di integrità HTTP e HTTPS. Questa annotazione si applica solo se ibm-load-balancer-cloud-provider-vpc-health-check-protocol è impostato su http o https.

• Il percorso URL deve avere il formato di una destinazione di richiesta in forma di origine.
• Se questa annotazione non è specificata e l'annotazione ibm-load-balancer-cloud-provider-vpc-health-check-protocol è impostata su http o https, viene applicato il valore predefinito /.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

Facoltativo. Il numero di secondi di attesa tra i tentativi di controllo di integrità. Per impostazione predefinita, questo valore è impostato su 5 e ha un minimo di 2 e un massimo di 60. Questo valore deve essere maggiore del valore ibm-load-balancer-cloud-provider-vpc-health-check-timeout, che per impostazione predefinita è impostato su 2.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

Facoltativo. Il numero di secondi di attesa per una risposta a un controllo di integrità. Per impostazione predefinita, questo valore è impostato su 2 e ha un minimo di 1 e un massimo di 59. Questo valore deve essere inferiore al valore ibm-load-balancer-cloud-provider-vpc-health-check-delay, che è impostato su 5 per impostazione predefinita.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

Il numero massimo di tentativi di controllo di integrità per il programma di bilanciamento del carico VPC. Per impostazione predefinita, questo valore è impostato su 2 e ha un minimo di 1 e un massimo di 10.

Attivazione dei controlli di integrità “ TCP ” per i bilanciatori di carico “ UDP ”

Poiché non sono disponibili controlli di integrità UDP, i bilanciatori di carico UDP che utilizzano controlli di integrità TCP devono avere una porta TCP aggiuntiva specificata con l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp.

È possibile specificare la porta del nodo TCP per un altro bilanciatore di carico o per un’istanza di NodePort in esecuzione nel proprio cluster. Tuttavia, se la porta del nodo si trova al di fuori dell'intervallo 30000-32767, è necessario modificare il gruppo di sicurezza del cluster VPC kube-<cluster-ID> per consentire il traffico in entrata alla porta specificata.

Si noti che, se il valore della porta specificato si riferisce a un servizio che smette di funzionare in modo imprevisto o il cui valore della porta viene riconfigurato, i controlli di integrità di TCP smettono di funzionare fino a quando il servizio non torna operativo oppure non si riconfigura l’annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp con un nuovo valore della porta TCP. Per evitare ciò, è possibile specificare la kubelet porta 10250, che è un valore di porta statico che non subisce interruzioni del servizio. Tuttavia, devi modificare il gruppo di sicurezza del cluster VPC kube-<cluster-ID> per accettare il traffico in entrata dalla porta kubelet.

Vuoi evitare la complessità derivante dalla necessità di specificare porte TCP aggiuntive per i controlli di integrità in un bilanciatore di carico UDP? Impostare externalTrafficPolicy su Local per utilizzare i controlli di integrità di HTTP, che non richiedono specifiche aggiuntive relative alle porte.