Configurazione di un Network Load Balancer for VPC

Rendi accessibile la tua app alla rete pubblica o a quella privata configurando un servizio " Kubernetes " ( LoadBalancer ) pubblico o privato in ciascuna zona del tuo cluster VPC. A questo punto, è possibile, se lo si desidera, registrare il VPC NLB con un record DNS e un certific TLS. Gli NLB VPC supportano sia il protocollo “ TCP ” che “ UDP ”.

Impostazione di un VPC NLB pubblico o privato

Esponi la tua app al traffico di rete configurando un servizio Kubernetes LoadBalancer in ciascuna zona del tuo cluster. Quando si crea il servizio Kubernetes LoadBalancer, viene automaticamente creato un VPC NLB ( Network Load Balancer for VPC ) pubblico o privato all’interno del proprio VPC, al di fuori del cluster, che instrada le richieste verso l’applicazione.

Prima di iniziare

Assicurarsi di avere il ruolo di accesso al servizio IAM Writer o Manager IBM Cloud per lo spazio dei nomi in cui si distribuisce il servizio Kubernetes LoadBalancer per il VPC NLB.
Accedi al tuo cluster Red Hat OpenShift.
Per visualizzare i VPC NLB, installare il plug-in infrastructure-service. Il prefisso per l'esecuzione dei comandi è ibmcloud is.
```
ibmcloud plugin install infrastructure-service
```
Per gli NLB VPC privati: Collegarsi alla rete privata VPC, ad esempio tramite una connessione VPC VPN.
Per i VPC NLB privati: Abilitare l'applicazione a ricevere richieste di rete private.
1. Creare una sottorete VPC dedicata al VPC NLB. Questa sottorete deve esistere nella stessa VPC e nella stessa posizione del cluster, ma non può essere collegata al cluster o ai nodi worker. 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. Dopo il provisioning della sottorete, prendere nota del suo ID.
2. Se il client che si connette all'applicazione attraverso il VPC NLB si trova al di fuori della VPC e della zona della subnet VPC dedicata, è necessario creare una tabella di routing in ingresso personalizzata. Per ulteriori informazioni, consultare la tabella delle limitazioni note e Informazioni sulle tabelle di routing e sulle rotte. Selezionare una delle seguenti sorgenti di traffico per la tabella di routing in ingresso personalizzata: Per il traffico proveniente da una rete locale, scegliere Collegamento diretto. Per il traffico proveniente da un'altra VPC o dall'infrastruttura classica, scegliere Gateway di transito. Per il traffico da un'altra zona all'interno della stessa VPC, scegliere Zona VPC. Per ulteriori informazioni, vedere Impostazione della connettività VPC VPN.

Configurare il servizio " `LoadBalancer` "

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.

Creare un file YAML di configurazione per il servizio Kubernetes LoadBalancer. Nel file YAML, specificare l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type come "public" o "private". La sezione annotations nel file di esempio include solo alcune annotazioni disponibili. Per un elenco completo delle annotazioni VPC NLB necessarie e opzionali, vedere Annotazioni e specifiche.

Per rendere il vostro VPC NLB facilmente identificabile, prendete in considerazione la possibilità di nominare il 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: "public"
    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>"
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.

Crea il servizio LoadBalancer Kubernetes nel tuo cluster.
```
oc apply -f <filename>.yaml -n <namespace>
```
Verifica che il servizio LoadBalancer Kubernetes sia stato creato correttamente nel tuo cluster. Quando il servizio viene creato, il campo LoadBalancer Ingress viene popolato con un indirizzo IP esterno assegnato dal VPC NLB.

L'implementazione 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>
```
Output della CLI di esempio per un servizio `LoadBalancer` pubblico:
```sh {: screen}
NAME:                     myapp-vpc-nlb-us-east
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     169.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.
```

Verifica che il VPC NLB sia stato creato correttamente nella tua VPC. Nell'output, verificare che il VPC NLB presenti uno stato operativo (Operating Status ) pari a " online " e uno stato di provisioning (Provision Status ) pari a " active".

ibmcloud is load-balancers

Nell'esempio seguente, che riporta l'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       yes         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.241.0.7               active             169.63.99.184                 c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62

Accedere all'indirizzo IP del servizio Kubernetes LoadBalancer trovato al punto 4 e alla porta dell'applicazione nel formato <external_IP>:<app_port>.
Facoltativo: Ripetere questi passaggi per distribuire un VPC NLB pubblico in ogni zona in cui si desidera esporre l'applicazione. Quindi, è possibile registrare gli indirizzi IP esterni del VPC NLB in ogni zona con un sottodominio DNS.

Non eliminare le sottoreti che hai collegato al tuo cluster durante la sua creazione o quando aggiungi nodi di lavoro in una zona. Se si elimina una sottorete VPC utilizzata dal proprio cluster, gli NLB VPC che utilizzano indirizzi IP di quella sottorete potrebbero riscontrare problemi e potrebbe non essere possibile creare nuovi bilanciatori di carico.

Impostazione di un NLB pubblico utilizzando un intervallo di porte

Gli intervalli di porte possono essere utilizzati in 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 una configurazione manuale. Innanzitutto, è necessario impostare l'opzione ibm-load-balancer-cloud-provider-vpc-port-range. Può includere uno o più intervalli, ciascuno delimitato da una virgola. Anche il valore spec.ports.port deve essere impostato sul valore minimo dell'intervallo di porte.

Nell'esempio seguente, 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 rientrare nell'intervallo di porte configurato nel servizio NLB.

Nel seguente diagramma di esempio, per l'installazione client 1 viene creato un servizio Nodeport con porta 30000, mentre per l'installazione client 2 viene creato un servizio Nodeport con porta 30001.

L'utente effettua una richiesta alla porta 30001 dell'NLB contenente l'intervallo di porte. Questa richiesta viene indirizzata al servizio NLB del VPC, che la indirizza al servizio Nodeport del cluster, anch'esso in ascolto sulla porta 30001, che in questo caso è quella dell'installazione client 2. Il servizio Nodeport indirizza quindi la richiesta alla porta di destinazione dei pod selezionati dell'installazione client 2.

VPC NLB che utilizza un intervallo di porte. — VPC NLB con intervallo di porte

Creare un NLB che utilizzi un intervallo di porte utilizzando il seguente esempio. Il selettore e i pod di backend devono essere associati al servizio di bilanciamento del carico dell'intervallo di porte, in modo che i controlli sullo stato di salute abbiano esito positivo e i dati vengano consegnati alle porte dell'intervallo di porte. Per utilizzare l'intervallo di porte, è necessario creare servizi NodePort aggiuntivi che abbiano valori di porta nell'intervallo definito dal servizio di bilanciamento del carico.

Salvate il seguente esempio di configurazione LoadBalancer in un file chiamato 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

Creare il servizio.
```
oc apply -f loadbalancer.yaml
```

Creare un servizio NodePort con valori di porta compresi nell'intervallo di porte specificato in LoadBalancer 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

Crea il servizio " NodePort ".
```
oc apply -f nodeport.yaml
```
Per accedere a una porta che rientra nell'intervallo fornito da NLB.
```
curl https://<public ip assigned to NLB>:30003
```
- 30003 = È una porta del nodo nell'intervallo che risponde alla richiesta
- Le altre porte dell'intervallo non rispondono, a meno che non vengano creati servizi di porta del nodo aggiuntivi.

Registrazione di un record DNS e di un certificato TLS

I VPC NLB forniscono indirizzi IP esterni statici attraverso i quali è possibile accedere alla propria applicazione. 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, si supponga di avere un cluster multizona e di eseguire repliche della propria applicazione su nodi worker in ogni zona del cluster. Si crea un VPC NLB per zona per esporre le repliche delle applicazioni. Quindi, è possibile registrare gli indirizzi IP esterni forniti da ogni VPC NLB 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 dello stato di salute della VPC predefinito. Per ulteriori informazioni, consulta la documentazione VPC.

Creare un VPC NLB per zona per la propria 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.

Seguire i passaggi per registrare gli indirizzi IP di VPC NLB con un sottodominio DNS.

Recuperare l'indirizzo IP esterno del bilanciatore di 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

Creare un sottodominio DNS personalizzato o fornito da IBM per 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. Definire un alias per il proprio dominio personalizzato specificando gli indirizzi IP del bilanciatore di 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 SSL con caratteri jolly 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>
```
Aprite un browser web e inserite l'indirizzo URL per accedere alla vostra applicazione attraverso 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'app si chiuda correttamente all'indirizzo TLS eseguendo il comando curl -v https://<domain>. Un errore di certificato indica che la tua applicazione non sta terminando correttamente le connessioni TLS.

Annotazioni e specifiche

Esaminare le annotazioni e le specifiche VPC NLB necessarie e opzionali.

Annotazioni e specifiche richieste

service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb": Annotazione per creare un VPC NLB. Se non si include questa annotazione e si specifica nlb, viene creato un ALB VPC per impostazione predefinita.
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private": (Richiesto per gli NLB privati) Annotazione per specificare un servizio che accetta richieste private. Se questa annotazione non è inclusa, viene creato un VPC NLB pubblico.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: (Obbligatorio per gli NLB privati, facoltativo per gli NLB pubblici) Annotazione per specificare la sottorete dedicata su cui si distribuisce il VPC NLB. Il valore può essere specificato come ID di sottorete VPC, nome di sottorete VPC o CIDR di sottorete VPC. È necessario specificare una sola sottorete. La sottorete deve esistere nella stessa VPC del cluster e in una zona in cui il cluster ha nodi worker, ma nessun nodo worker può essere collegato a questa sottorete. I nodi worker presenti nella stessa zona di questa sottorete sono configurati per ricevere il traffico dal VPC NLB. Per vedere le sottoreti in tutti i gruppi di risorse, eseguire ibmcloud oc subnets --provider vpc-gen2 --vpc-id VPC_ID --zone ZONE.
externalTrafficPolicy: 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 salute di HTTP.; Se Cluster è impostato, il DSR viene implementato solo dal nodo worker a cui il VPC NLB inoltra inizialmente la richiesta in arrivo. Dopo l'arrivo della richiesta, questa viene inoltrata a un nodo worker che contiene l'app pod, che potrebbe trovarsi in una zona diversa. La risposta dell'app pod viene inviata al nodo worker originale, che utilizza DSR per inviare la risposta direttamente al client, bypassando il VPC NLB. 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 ".

Annotazioni e specifiche facoltative

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: Includere un nome unico per rendere persistente il bilanciatore di carico VPC. I bilanciatori di carico VPC persistenti non vengono eliminati quando viene eliminato il cluster a cui appartengono. Per ulteriori informazioni, vedere Bilanciatori di carico VPC persistenti. Questa annotazione può essere impostata solo alla creazione del bilanciatore di carico. Non può essere utilizzato in un'operazione di aggiornamento.
service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: Annotazione per specificare una zona VPC a cui è collegato il tuo cluster. Il VPC NLB viene distribuito nella stessa sottorete di quella zona a cui sono collegati i nodi di lavoro. Se in seguito si modifica questa annotazione indicando una zona diversa, il VPC NLB non viene spostato nella nuova zona. Se non si specifica questa annotazione o service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets annotation, il VPC NLB viene distribuito nella zona più ottimale (ad esempio una zona che ha nodi worker nello stato Ready ). Se l'etichetta dedicated: edge è impostata sui nodi worker e si specifica questa annotazione, solo i nodi edge della 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. Per visualizzare le zone, esegui il comando ibmcloud ks zone ls --provider vpc-gen2``.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: Annotazione per specificare un selettore di etichetta del nodo lavoratore. È possibile configurare nodi worker specifici nel cluster per ricevere il traffico specificando le chiavi di selezione delle etichette. È possibile includere un solo selettore di etichetta nell'annotazione e il selettore deve essere specificato nel formato "key=value". Se questa annotazione non è specificata, tutti i nodi worker del cluster sono configurati per ricevere traffico dal VPC NLB. Questa annotazione ha la precedenza sull'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-zone e qualsiasi etichetta dedicated: edge sui nodi lavoratori viene ignorata. Per limitare il traffico a una zona specifica, si può usare questa annotazione per specificare i nodi worker in quella zona. Si noti che l'impostazione di una nuova etichetta su un nodo worker del cluster non configura automaticamente il nodo worker per ricevere il traffico; è necessario ricreare o aggiornare il VPC NLB affinché il nodo worker con la nuova etichetta riceva il traffico.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp: La porta del nodo " TCP " da utilizzare per i controlli di integrità " 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 il valore di una 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: Questa annotazione imposta il protocollo di controllo dello stato di salute sulla risorsa VPC load balancer associata al servizio Kubernetes load balancer. Le opzioni disponibili sono http, https, o tcp. Di solito, il protocollo di controllo dello stato di salute del VPC LB è determinato dal valore dell'impostazione externalTrafficPolicy nelle specifiche del servizio di bilanciamento del carico Kubernetes. Tuttavia, questa annotazione annulla questa logica. Questa annotazione non modifica il comportamento di Kubernetes, e di kube-proxy in particolare, rispetto alle varie impostazioni di externalTrafficPolicy.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: 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 specificata per il servizio " TCP " 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. Per ulteriori informazioni, vedere Comprendere la rete VPC sicura per impostazione predefinita del cluster e Creare e gestire i gruppi di sicurezza VPC.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: Il percorso del controllo di salute URL per i controlli di salute 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 essere nel formato di una richiesta di destinazione origin-form. Se questa annotazione non viene 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 da attendere tra i tentativi di controllo dello stato di salute. Per impostazione predefinita, questo valore è impostato su 5, con 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 sanitario. Per impostazione predefinita, questo valore è impostato su 2, con 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 dello stato di salute per il bilanciatore di carico VPC. Per impostazione predefinita, questo valore è impostato su 2, con un minimo di 1 e un massimo di 10.
service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud": Versione 4.16 o successive.; Registra l'indirizzo IP del bilanciatore di carico con il dominio di ingresso specificato. Se il dominio specificato non esiste, viene creato un dominio che utilizza il provider interno gestito da IBM (IBM NS1). Per creare un nuovo dominio, il nome deve essere unico per tutti i domini esistenti (non solo per quelli del cluster). L'eliminazione del servizio di load balancer rimuove l'indirizzo IP dal dominio. Tuttavia, la rimozione dell'annotazione non rimuove l'indirizzo IP dal dominio.
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. Nel caso di un cluster con nodi di lavoro distribuiti in tre zone, ciò comporta che il bilanciatore di carico indirizzi il traffico verso un totale di 24 nodi di lavoro. Il numero totale di nodi worker in tutte le zone verso cui il bilanciatore di carico esegue il percorso non può essere superiore a 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: Versione 1.30 e e successive.; 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-managed, specificare un gruppo di sicurezza di cui si è proprietari e che si gestisce. Questa opzione rimuove il gruppo di sicurezza IBM-managed e lo sostituisce con il gruppo di sicurezza specificato dall'utente. La rimozione dell'annotazione da un bilanciatore di carico esistente sostituisce il gruppo di sicurezza aggiunto con il gruppo di sicurezza IBM-managed. È possibile aggiungere o rimuovere questa annotazione in qualsiasi momento. L'utente è responsabile della gestione del proprio gruppo di sicurezza e del suo aggiornamento.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-allow-outbound-traffic: Disponibile per i cluster che eseguono Secure by Default. Per creare gruppi di sicurezza per ogni indirizzo IP di un ALB associato a una porta esterna specificata dall'utente. Queste regole vengono create nel gruppo di sicurezza del cluster. Specificare le porte esterne valide in un elenco separato da virgole, come 80,443. In questo esempio, se ogni ALB pubblico associato a ciascun valore di porta esterna ha due indirizzi IP, viene creata una regola in uscita per ogni indirizzo IP, per un totale di 4 nuove regole. È possibile aggiungere o rimuovere questa annotazione in qualsiasi momento.
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 e 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 sul VPC LB.

Configurazione di un Network Load Balancer for VPC

Configurazione di un Network Load Balancer for VPC

Impostazione di un VPC NLB pubblico o privato

Prima di iniziare

Configurare il servizio " LoadBalancer "

Impostazione di un NLB pubblico utilizzando un intervallo di porte

Registrazione di un record DNS e di un certificato TLS

Annotazioni e specifiche

Annotazioni e specifiche richieste

Annotazioni e specifiche facoltative

Configurare il servizio " `LoadBalancer` "