Questo documento mostra come configurare GKE su VMware per utilizzare il bilanciamento del carico in bundle con il bilanciatore del carico MetalLB.
In GKE su VMware, MetalLB viene eseguito in modalità livello 2.
Esempio di configurazione MetalLB
Ecco un esempio di configurazione per i cluster che eseguono il bilanciatore del carico MetalLB:
Il diagramma precedente mostra un deployment MetalLB. MetalLB viene eseguito direttamente sui nodi del cluster. In questo esempio, il cluster di amministrazione e il cluster utente si trovano su due VLAN separate e ogni cluster si trova in una subnet separata:
| Cluster | Subnet |
|---|---|
| Cluster di amministrazione | 172.16.20.0/24 |
| Cluster utente | 172.16.40.0/24 |
admin-cluster.yaml
L'esempio seguente di file di configurazione del cluster di amministrazione mostra la configurazione vista nel diagramma precedente di:
Bilanciatore del carico MetalLB
VIP su MetalLB per il server API Kubernetes e componenti aggiuntivi del cluster di amministrazione
network:
hostConfig:
...
ipMode:
type: "static"
ipBlockFilePath: "config-folder/admin-cluster-ipblock.yaml"
...
loadBalancer:
kind: "MetalLB"
...
vips:
controlPlaneVIP: "172.16.20.100"
addonsVIP: "172.16.20.101"
admin-cluster-ipblock.yaml
L'esempio seguente di file di blocchi IP mostra la designazione degli indirizzi IP per i nodi nel cluster di amministrazione. Sono inclusi anche l'indirizzo per il nodo del piano di controllo per il cluster utente e un indirizzo IP da utilizzare durante l'upgrade del cluster.
blocks:
- netmask: "255.255.255.0"
gateway: "17.16.20.1"
ips:
- ip: 172.16.20.50
hostname: admin-vm-1
- ip: 172.16.20.51
hostname: admin-vm-2
- ip: 172.16.20.52
hostname: admin-vm-3
- ip: 172.16.20.53
hostname: admin-vm-4
- ip: 172.16.20.54
hostname: admin-vm-5
user-cluster.yaml
L'esempio seguente di file di configurazione del cluster utente mostra la configurazione di:
Pool di indirizzi che il controller MetalLB può scegliere e assegnare ai servizi di tipo
LoadBalancer. Il VIP in entrata si trova in uno di questi pool.VIP designato per il server API Kubernetes del cluster utente e per il VIP in entrata che hai scelto di configurare per il proxy in entrata. Il VIP del server API Kubernetes si trova nella subnet del cluster di amministrazione, perché il piano di controllo per un cluster utente viene eseguito su un nodo nel cluster di amministrazione.
Un pool di nodi abilitato per l'utilizzo di MetalLB. Verrà eseguito il deployment di MetalLB sui nodi del cluster utente che appartengono a quel pool di nodi.
network:
hostConfig:
...
ipMode:
type: "static"
ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...
loadBalancer:
kind: MetalLB
metalLB:
addressPools:
- name: "address-pool-1"
addresses:
- "172.16.40.100/32"
- "172.16.40.101-172.16.40.112
avoidBuggyIPs: true
...
vips:
controlPlaneVIP: "172.16.20.102"
ingressVIP: "172.16.40.102"
...
nodePools:
- name: "node-pool-1"
cpus: 4
memoryMB: 8192
replicas: 3
enableLoadBalancer: true
La configurazione nell'esempio precedente specifica un insieme di indirizzi disponibili per i servizi. Quando uno sviluppatore di applicazioni crea un servizio di tipo LoadBalancer nel cluster utente, il controller MetalLB sceglie un indirizzo IP da questo pool.
user-cluster-ipblock.yaml
Il seguente esempio di file di blocchi IP mostra la designazione degli indirizzi IP per i nodi nel cluster utente. Include un indirizzo IP da utilizzare durante l'upgrade del cluster.
blocks:
- netmask: "255.255.255.0"
gateway: "17.16.40.1"
ips:
- ip: 172.16.40.21
hostname: user-vm-1
- ip: 172.16.40.22
hostname: user-vm-2
- ip: 172.16.40.23
hostname: user-vm-3
- ip: 172.16.40.24
hostname: user-vm-4
- ip: 172.16.40.25
hostname: user-vm-5
Configura MetalLB
Porte firewall aperte
MetalLB utilizza la raccolta dell'elenco dei membri Go per svolgere l'elezione dei leader. La libreria memberlist utilizza le porte TCP 7946 e UDP 7946 per scambiare informazioni. Assicurati che queste porte siano accessibili per il traffico in entrata e in uscita su tutti i nodi del bilanciatore del carico.
Abilita MetalLB per un nuovo cluster di amministrazione
Nel
file di configurazione del cluster di amministrazione,
imposta loadBalancer.kind su "MetalLB".
loadBalancer: kind: "MetalLB"
Compila il resto del file di configurazione del cluster di amministrazione e crea il cluster di amministrazione come descritto in Creare un cluster di amministrazione.
Specifica pool di indirizzi
Il controller MetalLB si occupa della gestione degli indirizzi IP per i servizi. Quindi, quando uno sviluppatore di applicazioni crea un servizio di tipo LoadBalancer in un cluster utente, non è necessario specificare manualmente un indirizzo IP per il servizio. Invece, il controller MetalLB sceglie un indirizzo IP da un pool di indirizzi da te specificato al momento della creazione del cluster.
Pensa a quanti servizi di tipo LoadBalancer sono probabilmente attivi nel tuo cluster utente in un dato momento. Quindi, nella sezione loadBalancer.metalLB.addressPools del file di configurazione del cluster utente, specifica un numero sufficiente di indirizzi IP per questi servizi.
Il VIP in entrata per il cluster utente deve essere compreso tra gli indirizzi specificati in un pool di indirizzi. Questo perché il proxy in entrata è esposto da un servizio di tipo LoadBalancer.
Se gli sviluppatori di applicazioni non hanno bisogno di creare servizi di tipo LoadBalancer, non devi specificare indirizzi diversi dal VIP in entrata.
Gli indirizzi devono essere in formato CIDR o intervallo. Se vuoi specificare un singolo indirizzo, utilizza un CIDR /32. Ad esempio:
addresses: - "192.0.2.0/26" - "192.0.2.64-192.0.2.72" - "192.0.2.75/32
Se devi modificare gli indirizzi in un pool dopo la creazione del cluster, puoi utilizzare gkectl update cluster. Per ulteriori informazioni, consulta la pagina relativa all'aggiornamento di MetalLB.
Abilita MetalLB per un nuovo cluster utente
Nel file di configurazione del cluster utente:
- Imposta
loadBalancer.kindsu"MetalLB". - Specifica uno o più pool di indirizzi per i servizi. Il VIP in entrata deve trovarsi in uno di questi pool.
- Imposta
enableLoadBalancersutrueper almeno un pool di nodi nel cluster.
Compila il resto del file di configurazione del cluster utente e crea il cluster utente come descritto in Creare un cluster utente.
Assegnazione manuale degli indirizzi di emergenza
Se non vuoi che il controller MetalLB assegni automaticamente gli indirizzi IP di un determinato pool ai servizi, imposta il campo manualAssign del pool su true. Uno sviluppatore può quindi creare un servizio di tipo LoadBalancer
e specificare manualmente uno degli indirizzi del pool. Ad esempio:
loadBalancer:
metalLB:
addressPools:
- name: "my-address-pool-2"
addresses:
- "192.0.2.73-192.0.2.80"
manualAssign: true
Evitare gli indirizzi IP con bug
Se imposti il campo avoidBuggyIPs di un pool di indirizzi su true, il controller MetalLB non utilizzerà indirizzi del pool che terminano con .0 o .255. In questo modo si evita il problema dei dispositivi consumer con bug che eliminano erroneamente il traffico inviato a questi indirizzi IP speciali. Ad esempio:
loadBalancer:
metalLB:
addressPools:
- name: "my-address-pool-1"
addresses:
- "192.0.2.0/24"
avoidBuggyIPs: true
Crea un servizio di tipo LoadBalancer
Ecco due manifest: uno per un deployment e uno per un servizio:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
selector:
matchLabels:
greeting: hello
replicas: 3
template:
metadata:
labels:
greeting: hello
spec:
containers:
- name: hello
image: gcr.io/google-samples/hello-app:2.0
---
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: LoadBalancer
selector:
greeting: hello
ports:
- name: metal-lb-example-port
protocol: TCP
port: 60000
targetPort: 8080
Tieni presente che il manifest del servizio non specifica un indirizzo IP esterno. Il controller MetalLB sceglierà un indirizzo IP esterno dal pool di indirizzi specificato nel file di configurazione del cluster utente.
Salva i manifest in un file denominato my-dep-svc.yaml. Quindi crea gli oggetti Deployment
e servizio:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-dep-svc.yaml
Visualizza il servizio:
kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get service my-service --output wide
L'output mostra l'indirizzo IP esterno che è stato assegnato automaticamente al servizio. Ad esempio:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR my-service LoadBalancer 10.96.2.166 192.0.2.2 60000:31914/TCP 28s
Verifica che l'indirizzo IP esterno assegnato sia stato acquisito dal pool di indirizzi specificato nel file di configurazione del cluster utente. Ad esempio, 192.0.2.2 si trova in questo pool di indirizzi:
metalLB:
addressPools:
- name: "address-pool-1"
addresses:
- "192.0.2.0/24"
- "198.51.100.1-198.51.100.3"
Chiama il servizio:
curl EXTERNAL_IP_ADDRESS:60000
L'output mostra un messaggio Hello, world!:
Hello, world! Version: 2.0.0
Aggiorna MetalLB
Dopo aver creato il cluster, puoi aggiornare i pool di indirizzi MetalLB e il campo enableLoadBalancer nei pool di nodi. Apporta le modifiche desiderate nel file di configurazione del cluster utente, quindi chiama gkectl update cluster:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONIFG --config USER_CLUSTER_CONFIG
Pod MetalLB e ConfigMap
Il controller MetalLB viene eseguito come Deployment e l'altoparlante MetalLB viene eseguito come DaemonSet sui nodi nei pool in cui enableLoadBalancer è impostato su true. Il controller MetalLB gestisce gli indirizzi IP assegnati ai servizi. Il relatore di MetalLB
fa l'elezione dei leader e annuncia i VIP del servizio.
Visualizza tutti i pod MetalLB:
kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get pods --namespace kube-system --selector app=metallb
Puoi utilizzare i log dei pod MetalLB per la risoluzione dei problemi.
La configurazione MetalLB viene archiviata in un ConfigMap in un formato noto da MetalLB.
Non modificare direttamente il ConfigMap. Utilizza invece gkectl update cluster come
descritto in precedenza. Per visualizzare il ConfigMap per la risoluzione dei problemi:
kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get configmap metallb-config --namespace kube-system
Vantaggi dell'utilizzo di MetalLB
MetalLB viene eseguito direttamente sui nodi del cluster, quindi non richiede VM aggiuntive.
Il controller MetalLB si occupa della gestione degli indirizzi IP per i servizi, quindi non devi scegliere manualmente un indirizzo IP per ogni servizio.
Le istanze attive di MetalLB per servizi diversi possono essere eseguite su nodi diversi.
Puoi condividere un indirizzo IP tra diversi servizi.
Confronto tra MetalLB e F5 BIG-IP e Seesaw
I VIP devono trovarsi nella stessa subnet dei nodi del cluster. Questo è un requisito anche per Seesaw, ma non per F5 BIG-IP.
Non sono disponibili metriche per il traffico.
Non esiste un failover senza hit; le connessioni esistenti vengono reimpostate durante il failover.
Il traffico esterno verso i pod di un determinato servizio passa attraverso un singolo nodo che esegue lo speaker MetalLB. Ciò significa che l'indirizzo IP del client di solito non è visibile ai container in esecuzione nel pod.