Tipi di bilanciatori di carico

La tabella seguente descrive le caratteristiche di base di ciascuna opzione di bilanciamento del carico.

Bilanciatore di carico delle applicazioni per VPC

Configurare un (VPC layer-7 ALB Application Load Balancer for VPC ) multizona che funga da punto di ingresso esterno per le richieste in entrata a un'app nel cluster. Tenete presente i seguenti punti quando pianificate la vostra configurazione VPC ALB.

Non confondere i Application Load Balancer for VPC con i bilanciatori di carico Red Hat OpenShift on IBM Cloud delle applicazioni Ingress. Gli Application Load Balancer per VPC (VPC ALB) vengono eseguiti all'esterno del cluster nella VPC e sono configurati dai KubernetesLoadBalancer servizi creati dall'utente. Gli application load balancer(ALB)di Ingress sono controllori di Ingress che vengono eseguiti sui nodi worker del cluster.

• I nomi degli ALB VPC hanno un formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Per vedere l'ID del cluster, eseguire 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. I trattini (-) vengono rimossi dall'UID del servizio Kubernetes LoadBalancer nel nome del VPC ALB.

• Per impostazione predefinita, quando si crea un servizio Kubernetes LoadBalancer per un'applicazione nel cluster, viene creato un Application Load Balancer for VPC nella VPC esterna al cluster. L'ALB VPC instrada le richieste alla vostra applicazione attraverso il sito NodePorts privato che viene aperto automaticamente sui vostri nodi worker.

• Se si crea un servizio Kubernetes LoadBalancer pubblico, è possibile accedere alla propria applicazione da Internet attraverso il nome host assegnato dall'ALB VPC al servizio Kubernetes LoadBalancer nel formato 1234abcd-<region>.lb.appdomain.cloud. Anche se i nodi worker sono connessi solo a una subnet VPC privata, l'ALB VPC può ricevere e instradare le richieste pubbliche al servizio che espone l'applicazione. Si noti che non è necessario un gateway pubblico sulla subnet VPC per consentire le richieste pubbliche all'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 si è connessi alla propria rete VPC privata, si può accedere alla propria applicazione attraverso l'hostname assegnato dall'ALB VPC al servizio Kubernetes LoadBalancer nel formato 1234abcd-<region>.lb.appdomain.cloud.

• È possibile utilizzare un VPC ALB esistente su un altro cluster rinominando il VPC ALB.

Il diagramma seguente illustra il modo in cui un utente accede a un'applicazione da Internet attraverso l'ALB VPC.

1. Una richiesta all'applicazione utilizza il nome host assegnato al servizio Kubernetes LoadBalancer dall'ALB VPC, ad esempio 1234abcd-<region>.lb.appdomain.cloud.
2. La richiesta viene automaticamente inoltrata dall'ALB VPC a una delle porte del nodo worker e quindi all'indirizzo IP privato dell'app pod.
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, il VPC ALB instrada le richieste ai nodi worker in tutte le sottoreti e zone del cluster.

Network Load Balancer for VPC

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

I VPC NLB offrono diversi vantaggi, come la possibilità di ottenere un throughput più elevato e prestazioni migliori grazie all'utilizzo del direct server return (DSR). Con DSR, il nodo worker può inviare i pacchetti di risposta delle app direttamente all'indirizzo IP del client e saltare il VPC NLB, riducendo la quantità di traffico che il VPC NLB deve gestire. Inoltre, è possibile configurare il VPC NLB in modo che includa la conservazione dell'indirizzo IP di origine su tutte le richieste dei client, includendo l'opzione externalTrafficPolicy: Local specifica.

• I nomi VPC NLB standard hanno un formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Per vedere l'ID del cluster, eseguire 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. I trattini (-) vengono rimossi dall'UID del servizio Kubernetes LoadBalancer nel nome VPC NLB.

• Quando si crea un servizio Kubernetes LoadBalancer per un'applicazione nel cluster e si include l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb", viene creato un VPC NLB nel VPC al di fuori del cluster. Il VPC NLB instrada le richieste per la vostra applicazione attraverso il sito NodePorts privato che viene aperto automaticamente sui vostri nodi worker.

• Se si crea un servizio public Kubernetes LoadBalancer, è possibile accedere alla propria applicazione da Internet attraverso l'indirizzo IP esterno pubblico assegnato dal VPC NLB al servizio Kubernetes LoadBalancer. Anche se i nodi worker sono connessi solo a una sottorete VPC privata, il VPC NLB può ricevere e instradare le richieste pubbliche al servizio che espone la vostra applicazione. Si noti che non è necessario un gateway pubblico sulla subnet 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 si è connessi alla rete VPC privata, si può accedere all'applicazione attraverso l'indirizzo IP esterno privato assegnato dal VPC NLB al servizio Kubernetes LoadBalancer.

Il diagramma seguente illustra come un utente accede a un'applicazione da Internet attraverso il VPC NLB.

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

Limitazioni

Esaminare le seguenti impostazioni e limitazioni predefinite.

• Rivedere le limitazioni note per gli ALB VPC e le limitazioni note per gli NLB VPC.
• Gli ALB VPC privati non accettano tutto il traffico, ma solo quello RFC 1918.
• Gli NLB VPC privati devono essere creati su una sottorete VPC dedicata che deve esistere nella stessa VPC e nella stessa posizione del cluster, ma la sottorete non può essere collegata al cluster o ai nodi worker.
• Red Hat OpenShift: Sebbene il Kubernetes protocollo SCTP sia generalmente disponibile nella release della comunità Kubernetes, la creazione di bilanciatori di carico che utilizzano questo protocollo non è supportata nei cluster IBM Cloud Kubernetes Service.
• Un programma di bilanciamento del carico VPC viene creato per ogni servizio LoadBalancer Kubernetes che crei e instrada le richieste solo al servizio LoadBalancer Kubernetes. Tra tutti i cluster VPC del VPC, è possibile creare un massimo di 50 bilanciatori di carico VPC. Per ulteriori informazioni, consultare la documentazione Le quote VPC.
• Il bilanciatore di carico VPC può instradare le richieste a un numero limitato di nodi worker. Il numero massimo di nodi a cui è possibile indirizzare le richieste dipende da come è stata impostata l'annotazione externalTrafficPolicy.
  • Se si imposta externalTrafficPolicy: Cluster nella configurazione del bilanciatore di carico:
    • Il bilanciatore di carico VPC esegue il percorso verso i primi 8 nodi worker rilevati in ciascuna zona. Per un cluster con nodi worker in tre zone, il risultato è che il bilanciatore di carico esegue il routing su 24 nodi worker in totale. Per un cluster a zona singola, il bilanciatore di carico instrada verso 8 nodi worker in totale. È possibile modificare il numero di nodi worker per zona a cui il bilanciatore di carico esegue il routing con l'opzione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota, ma il numero totale in tutte le zone 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. L'opzione kube-proxy configura le tabelle IP per instradare il traffico in entrata dal nodo worker all'application pod su qualunque nodo risieda l'application pod.
  • Se si imposta externalTrafficPolicy: Local nella configurazione del bilanciatore di carico, il bilanciatore di carico VPC viene creato solo se ci sono 50 o meno nodi worker nel cluster. Questo limite è fissato dalle limitazioni della quota VPC di 50 membri del pool per pool di bilanciatori di carico VPC. Per evitare questa limitazione, utilizzare l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector per limitare i nodi worker nel pool del bilanciatore di carico. Ad esempio, si può usare questa annotazione per forzare il traffico in arrivo a uno specifico pool di lavoratori. Se si usa questa annotazione per forzare il traffico verso uno specifico pool di lavoratori, bisogna anche assicurarsi che il pod dell'applicazione venga eseguito nello stesso pool di lavoratori.
• Quando definisci il file YAML di configurazione per un servizio LoadBalancer Kubernetes, le seguenti annotazioni e impostazioni non sono supportate:
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
  • spec.loadBalancerIP
  • spec.loadBalancerSourceRanges
  • Solo VPC NLB: service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
  • Solo gli ALB VPC: L'impostazione externalTrafficPolicy: Local è supportata, ma non conserva l'IP di origine della richiesta.
• Quando si elimina un cluster VPC, vengono eliminati automaticamente anche gli eventuali bilanciatori di carico VPC non persistenti, denominati nel formato kube-<cluster_ID>-<kubernetes_lb_service_UID> e creati automaticamente da Red Hat OpenShift on IBM Cloud per i servizi Kubernetes LoadBalancer di quel cluster. Tuttavia, i bilanciatori di carico persistenti con nomi unici e i bilanciatori di carico VPC creati manualmente nella VPC non vengono eliminati.
• Puoi registrare fino a 128 domini secondari per i nomi host del programma di bilanciamento del carico VPC. Questo limite può essere innalzato su richiesta, aprendo un caso di supporto.
• I sottodomini registrati per i bilanciatori di carico VPC sono limitati a 130 caratteri o meno.
• Gli ALB VPC sono in ascolto sulle stesse sottoreti VPC su cui sono allocati i nodi worker del cluster, a meno che il servizio Kubernetes load balancer non venga creato con le annotazioni service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets o service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, che limitano il traffico a nodi specifici.
  • Le sottoreti e le zone dell'ALB VPC possono essere aggiornate o modificate dopo la creazione dell'ALB. Se si aggiungono altre zone al cluster o si aggiorna il servizio Kubernetes load balancer con le annotazioni service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets o service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, il VPC ALB viene aggiornato per ascoltare sulle nuove sottoreti.
• Gli NLB VPC ascoltano solo su una singola subnet VPC in una singola zona. Non possono essere configurati per ascoltare su più sottoreti VPC o per ascoltare su più zone. È possibile specificare la singola sottorete su cui ascoltare un NLB con le annotazioni service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets o service.kubernetes.io/ibm-load-balancer-cloud-provider-zone.
  • I VPC NLB inoltrano il traffico in entrata a tutti i nodi worker del cluster, a meno che non si limiti il traffico in entrata a specifici nodi worker con le opzioni service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector o service.kubernetes.io/ibm-load-balancer-cloud-provider-zone annotations. Per limitare il traffico a una zona specifica, è possibile utilizzare queste annotazioni per specificare i nodi worker in quella zona.
• La disabilitazione dell'allocazione del bilanciatore di carico NodePort non è supportata per i bilanciatori di carico VPC.
• I VPC NLB possono essere configurati sia con UDP che con TCP sullo stesso VPC LB, ma la porta di ascolto deve essere diversa.