Versione 1.11. Questa versione non è più supportata. Per ulteriori informazioni, consulta le norme relative all'assistenza per le versioni. Per informazioni su come eseguire l'upgrade alla versione 1.12, consulta la pagina relativa all'upgrade di Anthos su Bare Metal nella documentazione della versione 1.12.

Versioni supportate disponibili: 1.14 | 1.13 | 1.12

Configura il bilanciamento del carico in bundle

Questa pagina descrive come configurare il bilanciamento del carico in bundle per Cluster Anthos on bare metal. Cluster Anthos on bare metal esegue il deployment di bilanciatori del carico di livello 4 che vengono eseguiti su un pool dedicato di nodi worker o sugli stessi nodi del piano di controllo.

Consulta la panoramica dei bilanciatori del carico per esempi di topologie di bilanciamento del carico disponibili nei cluster Anthos su Bare Metal.

Requisiti

Tutti i nodi del bilanciatore del carico devono trovarsi nella stessa subnet di livello 2.
Tutti i VIP devono trovarsi nella subnet dei nodi del bilanciatore del carico ed essere instradabili tramite il gateway della subnet.
Il gateway della subnet del bilanciatore del carico deve ascoltare i messaggi ARP senza costi e inoltrare i pacchetti ARP ai nodi del bilanciatore del carico.

Campi di configurazione

Modifica la sezione cluster.spec.loadBalancer del file di configurazione del cluster per configurare il bilanciamento del carico in bundle. Per informazioni sui file di configurazione del cluster ed esempi di configurazioni valide, consulta una delle seguenti pagine:

loadBalancer.mode

Questo valore deve essere bundled per abilitare il bilanciamento del carico in bundle.

loadBalancer.ports.controlPlaneLBPort

Questo valore specifica la porta di destinazione da utilizzare per il traffico inviato al piano di controllo Kubernetes (server API Kubernetes).

loadBalancer.vips.controlPlaneVIP

Questo valore specifica l'indirizzo IP di destinazione da utilizzare per il traffico inviato al piano di controllo Kubernetes (server API Kubernetes). Questo indirizzo IP deve trovarsi nella stessa subnet di livello 2 dei nodi che eseguono i bilanciatori del carico. Non elencare questo indirizzo nella sezione address pools del file di configurazione.

loadBalancer.vip.ingressVIP

Questo valore specifica l'indirizzo IP da utilizzare per i servizi dietro il bilanciatore del carico per il traffico in entrata. Questo campo non è consentito nei file di configurazione cluster. Questo indirizzo deve essere elencato nella sezione pool di indirizzi della configurazione.

loadBalancer.addressPool

Questa sezione della configurazione contiene uno o più pool di indirizzi specificati in questo formato:

- name: pool-name
  avoidBuggyIPs: boolean
  manualAssign: boolean
  addresses:
  - ip-range
  - ip-range

name: il nome del pool di indirizzi, pool-name, a scopo organizzativo.
avoidBuggyIPs: (facoltativo) true o false. Se true, nel pool vengono omessi gli indirizzi IP che terminano con .0 e .255. Alcune risorse di rete riducono il traffico a questi indirizzi speciali. Puoi omettere questo campo, il cui valore predefinito è false.
manualAssegna: (facoltativo) true o false. Se true, gli indirizzi in questo pool non vengono assegnati automaticamente ai servizi Kubernetes. Se true, un indirizzo IP in questo pool viene utilizzato solo quando è specificato in modo esplicito da un servizio. Puoi omettere questo campo, il cui valore predefinito è false.
addresss: un elenco di uno o più intervalli di indirizzi IP non sovrapposti. ip-range può essere specificata in notazione CIDR (come 198.51.100.0/24) o notazione intervallo (come 198.51.100.0-198.51.100.10, senza spazi intorno al trattino).

Gli intervalli di indirizzi IP nell'elenco addresses non devono sovrapporsi e devono trovarsi nella stessa subnet dei nodi che eseguono i bilanciatori del carico.

loadBalancer.nodePoolSpec

Questa sezione della configurazione specifica un elenco di nodi su cui eseguire i bilanciatori del carico. I nodi del bilanciatore del carico possono eseguire carichi di lavoro normali per impostazione predefinita e non prevedono incompatibilità speciali. L'esempio seguente mostra un pool di nodi con due nodi. Il primo nodo, 1.2.3.4, utilizza il campo k8sIP per specificare l'indirizzo IP del nodo nel cluster. L'indirizzo 1.2.3.4 viene utilizzato solo per l'accesso SSH.

nodePoolSpec:
  nodes:
  - address: 1.2.3.4
    k8sIP: 10.0.0.32
  - address: 10.0.0.33

Tutti i nodi nel pool di nodi del bilanciatore del carico devono trovarsi nella stessa subnet di livello 2 dei VIP del bilanciatore del carico configurati nella sezione loadBalancer.addressPools del file di configurazione. Se per un nodo è stato configurato k8sIP, solo quell'indirizzo deve trovarsi nella stessa subnet di livello 2 degli altri VIP del bilanciatore del carico.

Se nodePoolSpec non è impostato, i bilanciatori del carico in bundle vengono eseguiti sui nodi del piano di controllo. Ti consigliamo di eseguire i bilanciatori del carico su pool di nodi separati, se possibile.

Bilanciamento del carico del piano di controllo

Il bilanciatore del carico del piano di controllo gestisce l'indirizzo IP virtuale del piano di controllo. I cluster Anthos su Bare Metal eseguono Keepalive e HAProxy come pod statici di Kubernetes sui nodi del bilanciatore del carico per annunciare il VIP del piano di controllo. Keepalive utilizza il protocollo VRRP (Virtual Router Redundancy Protocol) sui nodi del bilanciatore del carico per un'alta disponibilità.

Bilanciamento del carico del piano dati

Il bilanciatore del carico del piano dati è per tutti i servizi Kubernetes di tipo LoadBalancer. Cluster Anthos on bare metal utilizza MetalLB in esecuzione in modalità Livello 2 per il bilanciamento del carico del piano dati. Il bilanciamento del carico del piano dati può essere configurato solo tramite i cluster Anthos su Bare Metal, non modificare direttamente il ConfigMap di MetalLB. Puoi utilizzare tutte le funzionalità MetalLB, inclusa la condivisione di indirizzi IP tra i servizi. Per informazioni sulle funzionalità, consulta la documentazione di MetalLB.

MetalLB esegue un pod dello speaker su ogni nodo utilizzando un daemonset, utilizzando l'elenco dei membri per un'alta disponibilità. È disponibile un nodo del bilanciatore del carico dedicato MetalLB per ogni servizio Kubernetes, anziché un nodo per l'intero cluster. In questo modo il traffico viene distribuito tra i nodi del bilanciatore del carico in caso di più servizi.

I bilanciatori del carico del piano dati possono essere eseguiti sui nodi del piano di controllo o su un sottoinsieme di nodi worker. Raggruppare i bilanciatori del carico dei piani dati sui nodi del piano di controllo aumenta l'utilizzo dei nodi del piano di controllo. Tuttavia, il raggruppamento in nodi del piano di controllo aumenta anche il rischio di sovraccarico del piano di controllo e aumenta il profilo di rischio delle informazioni riservate sul piano di controllo, ad esempio le chiavi SSH.

Conservazione dell'indirizzo IP dell'origine client

Il servizio LoadBalancer creato con la soluzione di bilanciamento del carico di livello 2 in bundle utilizza l'impostazione Cluster predefinita per il criterio del traffico esterno. Questa impostazione, spec.externalTrafficPolicy: Cluster, instrada il traffico esterno agli endpoint a livello di cluster, ma nasconde anche l'indirizzo IP dell'origine client.

Le seguenti sezioni descrivono come configurare il cluster per conservare l'indirizzo IP dell'origine client.

`NodePort` servizi

Kubernetes fornisce il servizio NAT (Network Address Translation) per i servizi NodePort. Per conservare gli indirizzi IP dell'origine client, imposta service.spec.externalTrafficPolicy su Local. Kubernetes non eseguirà più il NAT di origine, ma devi assicurarti che siano presenti pod in esecuzione esattamente sull'IP del nodo che hai scelto.

`LoadBalancer` servizi

Quando utilizzi externalTrafficPolicy: Local nei servizi LoadBalancer, imposta i pod dell'applicazione in modo che vengano eseguiti esattamente sui nodi del bilanciatore del carico. Aggiungi i seguenti nodeSelector ai pod della tua applicazione per apportare questa modifica:

apiVersion: v1
kind: Pod
...
spec:
  nodeSelector:
      baremetal.cluster.gke.io/lbnode: "true"
...

Ingress

Se le tue applicazioni sono servizi HTTP, puoi ottenere la visibilità IP client configurando i componenti in entrata:

Apri il servizio istio-ingress per la modifica:

kubectl edit service -n gke-system istio-ingress

Aggiungi externalTrafficPolicy: Local a spec, salva ed esci dall'editor.

apiVersion: v1
kind: Service
...
spec:
...
  externalTrafficPolicy: Local

Apri il deployment di istio-ingress per la modifica:

kubectl edit deployment -n gke-system istio-ingress

Aggiungi nodeSelector al deployment, salva ed esci dall'editor.

apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      ...
      nodeSelector:
          baremetal.cluster.gke.io/lbnode: "true"
...

Ora, tutti i tuoi servizi dietro a Ingress visualizzano un'intestazione X-Forwarded-For con IP client, come nell'esempio seguente:

X-Forwarded-For: 21.0.104.4