Gestione dei bilanciatori di carico VPC

Apportare le modifiche ai bilanciatori di carico VPC esistenti.

Non rinominare alcun VPC NLB o ALB. La ridenominazione di un bilanciatore di carico VPC genera un errore nel servizio Kubernetes LoadBalancer, il che potrebbe causare interruzioni nel carico di lavoro.

Bilanciatori di carico VPC persistenti

Per impostazione predefinita, i bilanciatori di carico VPC vengono eliminati quando viene eliminato il cluster a cui sono associati. Tuttavia, quando si crea una definizione di servizio LoadBalancer, si può rendere persistente il bilanciatore di carico, in modo che rimanga disponibile anche dopo la cancellazione del cluster. Un bilanciatore di carico VPC persistente può essere applicato a un altro cluster dopo la cancellazione del cluster precedente.

I nomi dei bilanciatori di carico VPC sono formattati come kube-<cluster_ID>-<kubernetes_lb_service_UID> per impostazione predefinita. Quando un cluster viene eliminato, questo formato di nome specifica i bilanciatori di carico associati che vengono anch'essi eliminati. Per assicurarsi che il bilanciatore di carico non venga cancellato quando si elimina un cluster, includere l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name nella definizione del servizio LoadBalancer per dare al bilanciatore di carico un nome univoco. Il nome del bilanciatore di carico deve essere unico all'interno della VPC e può includere solo caratteri alfanumerici minuscoli e trattini (-). L'annotazione può essere applicata a tutti i tipi di bilanciatori di carico VPC.

L'utente è responsabile dell'eliminazione dei bilanciatori di carico VPC persistenti quando non sono più necessari. Per eliminare un bilanciatore di carico VPC persistente, eliminare la definizione di servizio Kubernetes LoadBalancer a cui è associato il bilanciatore di carico VPC.

Spostamento di un bilanciatore di carico VPC da un cluster a un altro

I bilanciatori di carico VPC persistenti possono essere staccati da un cluster VPC e quindi collegati a un altro. Il nuovo cluster deve trovarsi all'interno dello stesso VPC del cluster originale.

Rimozione di un bilanciatore di carico VPC da un cluster

I bilanciatori di carico VPC sono collegati alla definizione di servizio Kubernetes LoadBalancer con cui sono stati creati. Per staccare un bilanciatore di carico VPC persistente da un cluster, è necessario interrompere il collegamento con il servizio LoadBalancer. In questo modo il servizio LoadBalancer diventa inutilizzabile e può essere tranquillamente cancellato. Il bilanciatore di carico VPC può quindi essere attaccato a un cluster diverso.

Per interrompere il collegamento tra il bilanciatore di carico VPC e il servizio LoadBalancer, si può o rinominare il bilanciatore di carico VPC o rimuovere l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name dalla definizione originale del servizio LoadBalancer. Si noti che questa è l'unica circostanza in cui si dovrebbe rinominare un bilanciatore di carico VPC, poiché così facendo si crea un errore per la risorsa Kubernetes. Tuttavia, se l'obiettivo finale è quello di utilizzare il bilanciatore di carico VPC su un cluster diverso, questo errore non interrompe il carico di lavoro. Non rinominare il bilanciatore di carico VPC se si vuole mantenere il bilanciatore di carico sullo stesso cluster.

Collegamento di un bilanciatore di 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 si crea un nuovo servizio LoadBalancer sul nuovo cluster, si può usare l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name per specificare il nome del bilanciatore di carico VPC da collegare.

Quando si crea il servizio LoadBalancer, il tipo di bilanciatore di carico VPC (ALB, NLB) e il tipo di IP (pubblico, privato) devono corrispondere alle specifiche del servizio LoadBalancer. Ad esempio, un servizio LoadBalancer esistente sul nuovo cluster che specifica un tipo NLB non può essere usato per collegare un VPC ALB al cluster. Le annotazioni che specificano il tipo di bilanciatore di carico e il tipo di IP sono service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features e service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type.

Le porte e i nodi specificati nel servizio LoadBalancer non devono necessariamente corrispondere a quelli con cui è stato creato il bilanciatore di carico VPC. Il bilanciatore di carico VPC si riconfigura con le definizioni delle porte del servizio LoadBalancer a cui è associato nel nuovo cluster.

Controlli di integrità per i bilanciatori di carico

I bilanciatori di carico VPC sono configurati automaticamente con controlli di salute, che si configurano con l'annotazione externalTrafficPolicy. È possibile utilizzare annotazioni aggiuntive per personalizzare i controlli di salute sui bilanciatori di carico.

Se l'opzione " externalTrafficPolicy " è impostata su " Cluster", vengono applicati i controlli di integrità " TCP ". Se si sta configurando un bilanciatore di carico UDP, è necessario specificare ulteriori impostazioni relative alle porte.
Se externalTrafficPolicy è impostato su Local, vengono applicati controlli sanitari HTTP. Il traffico in entrata viene consegnato solo all'application pod che risiede su quel nodo specifico. Se non c'è un pod applicativo su quel nodo specifico, il traffico in entrata viene interrotto.

L'impostazione externalTrafficPolicy: Local potrebbe far fallire i controlli sullo stato di salute dei nodi worker del bilanciatore di carico. Di solito, questo risultato è il comportamento previsto e non indica necessariamente un problema, poiché il traffico viene interrotto intenzionalmente se il bilanciatore di carico tenta di connettersi a qualsiasi nodo che non abbia un pod applicativo. Per ulteriori informazioni, vedere Perché i controlli di salute del bilanciatore di carico VPC non riescono sui miei nodi worker?.

Personalizzazione dei controlli di salute per i bilanciatori di carico VPC

Per un maggiore controllo sui controlli di salute del bilanciatore di carico VPC, è possibile utilizzare le annotazioni opzionali per personalizzare i controlli di salute con configurazioni avanzate per intervalli di test, timeout e tentativi. È possibile modificare o rimuovere queste personalizzazioni in qualsiasi momento.

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

Opzionale: Questa annotazione imposta il protocollo di controllo dello stato di salute sulla risorsa VPC del bilanciatore di carico associata al servizio Kubernetes del bilanciatore di carico. Normalmente, il protocollo di controllo dello stato di salute del VPC LB è determinato dal valore dell'impostazione externalTrafficPolicy nelle specifiche del servizio Kubernetes load balancer. Questa annotazione annulla questa logica. Questa annotazione fa sì che non alteri 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

Facoltativo. La porta dell' TCP e utilizzata per i controlli di integrità. Questa annotazione si applica solo se viene 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.

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

Facoltativo. URL Il percorso di controllo dello stato di salute per i controlli dello stato di salute di 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 dell' URL e deve essere nel formato di un'origine-forma richiesta-destinazione.
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 da attendere tra i tentativi di controllo dello stato di salute. 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 è impostato di default 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 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 di default 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 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. Per i cluster 4.14 e versioni precedenti, 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 verso la porta specificata.

Si noti che, se il valore della porta specificato si riferisce a un servizio che smette di funzionare in modo imprevisto o la cui porta viene riconfigurata, 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 per la porta TCP. Per evitare ciò, è possibile specificare la porta kubelet 10250, che è un valore di porta statico che non subisce interruzioni di servizio. Tuttavia, per le versioni del cluster 4.14 e precedenti, è necessario modificare il gruppo di sicurezza del cluster VPC kube-<cluster-ID> in modo che accetti il traffico in entrata dalla porta kubelet.

Vuoi evitare la complessità legata alla configurazione di 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.

Modifica della sottorete o della zona di un bilanciatore di carico

Dopo aver creato un VPC NLB, non è possibile riconfigurare la sottorete di ascolto con cui è stato creato. Se si desidera modificare la sottorete di ascolto di un VPC NLB esistente, è necessario eliminare, aggiornare e riapplicare il servizio " Kubernetes " LoadBalancer corrispondente.

Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

Elencare i servizi Kubernetes e trovare il nome del servizio LoadBalancer che si desidera modificare.

oc get services

Output di esempio.

NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                        AGE
my-load-balancer         LoadBalancer   172.21.77.198   52.118.150.107   8080:32767/TCP,443:30943/TCP   5d

Trovare il bilanciatore di carico VPC che corrisponde al servizio Kubernetes LoadBalancer.

I nomi dei bilanciatori di carico VPC sono nel formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Per visualizzare l'ID del cluster, esegui il comando ibmcloud ks cluster get --cluster CLUSTER_NAME``. Per visualizzare l'UID del servizio " Kubernetes " ( LoadBalancer ), eseguire il comando oc get svc LOAD_BALANCER_NAME -o yaml e individuare il campo " metadata.uid " nell'output. Nel nome del bilanciatore di carico VPC, i trattini (-) vengono rimossi dall'UID del servizio Kubernetes LoadBalancer.
```
ibmcloud is load-balancers
```
Output di esempio.
```
ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group      
r000-5aaaa11f6-c111-111f-b2e0-1c11aaaaf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf11111111fe4ca3f11111cb   Network       subnet-1                                  true        active             online             default                                                    Application      
```
Ottenere la definizione del servizio Kubernetes LoadBalancer e salvare l'output come file yaml chiamato my-lb.yaml.
```
oc describe service my-load-balancer -o yaml
```
Eliminare il servizio Kubernetes LoadBalancer. In questo modo si elimina anche il bilanciatore di carico VPC corrispondente.
```
oc delete service my-load-balancer
```
Aggiornare il file di definizione del servizio Kubernetes LoadBalancer con le modifiche alla sottorete o alla zona che si desidera implementare. Non modificare il nome del servizio LoadBalancer. Per informazioni dettagliate su come specificare le sottoreti o le zone per i bilanciatori di carico di rete, vedere Impostazione di un Network Load Balancer for VPC.
Applicare il nuovo file di definizione LoadBalancer.
```
oc apply -f my-lb.yaml
```

Verificare che il servizio Kubernetes LoadBalancer sia stato ricreato correttamente nel proprio cluster. Quando il servizio viene creato, il campo LoadBalancer Ingress viene popolato con un indirizzo IP esterno per l'NLB.

oc describe service my-load-balancer

Output di esempio.

NAME:                     my-load-balancer
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.X.XXX.XX
LoadBalancer Ingress:     169.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.XX.XX.XXX:8080,172.XX.XX.XX:8080,172.XX.XX.XX:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
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/my-load-balancer with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.

Verificare che il bilanciatore di carico VPC sia ricreato e che la sottorete o la zona sia aggiornata. Si noti che il provisioning del bilanciatore di carico VPC richiede alcuni minuti e che potrebbe essere visualizzato uno stato create_pending fino a quando il provisioning non è completo.

ibmcloud is load-balancers

Output di esempio.

ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group     
r006-5ecc68f6-c751-409f-b2e0-1c69babf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf03445796fe4ca3f73885cb   Network       subnet-2                                  true        active             online             default