Questa pagina descrive come ridimensionare un cluster utente GKE On-Prem. Il ridimensionamento di un cluster utente comporta l'aggiunta o la rimozione di nodi da tale cluster. La rimozione dei nodi da un cluster deve rilasciare gli indirizzi IP del cluster, rendendoli disponibili per l'utilizzo da parte di altri nodi. Per aggiungere nodi è necessario che gli indirizzi IP siano disponibili per tali nodi.
Per ridimensionare un cluster utente, modifica i campi replicas
nella configurazione MachineDeployment del cluster. Puoi applicare una patch alla configurazione dalla riga di comando utilizzando kubectl patch
.
Per informazioni sui limiti massimo e minimo per i cluster utente, consulta Quote e limiti.
Verifica che siano disponibili indirizzi IP sufficienti
Se aggiungi nodi aggiuntivi a un cluster, assicurati che il cluster abbia un numero di indirizzi IP sufficiente. La verifica di disporre di indirizzi IP sufficienti dipende dal fatto che il cluster utilizzi un server DHCP o IP statici.
DHCP
Se il cluster utilizza DHCP, verifica che il server DHCP nella rete in cui sono creati i nodi abbia un numero sufficiente di indirizzi IP. Dovrebbero esserci più indirizzi IP di quanti sono i nodi in esecuzione nel cluster utente.
IP statici
Se il cluster utilizza IP statici, verifica di aver allocato un numero sufficiente di indirizzi IP nel cluster:
kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ -n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml
dove:
- [ADMIN_CLUSTER_KUBECONFIG] indica a kubectl di utilizzare la versione kubeconfig di cluster di amministrazione, utilizzata per visualizzare e/o modificare le configurazioni dei cluster utente.
-n [USER_CLUSTER_NAME]
indica a kubectl di cercare uno spazio dei nomi chiamato in base al cluster utente.[USER_CLUSTER_NAME] -o yaml
indica a kubectl il cluster utente in cui esegui il comando.-o yaml
mostra la configurazione del cluster utente.
Nell'output del comando, cerca il campo reservedAddresses
. Nel campo dovrebbero essere presenti più indirizzi IP di quanti sono i nodi in esecuzione nel cluster utente.
Se devi aggiungere altri indirizzi al campo reservedAddresses
, procedi
nel seguente modo:
Apri la risorsa del cluster utente per la modifica:
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \ -n [USER_CLUSTER_NAME]
La configurazione del cluster è aperta nell'editor predefinito della shell.
Aggiungi tutti i blocchi IP statici aggiuntivi che vuoi. Un blocco IP è composto da campi
gateway
,hostname
,ip
enetmask
.
Di seguito è riportato un esempio di campo reservedAddresses
con i suoi quattro blocchi IP statici evidenziati:
... networkSpec: dns: - 172.x.x.x ntp: 129.x.x.x reservedAddresses: - gateway: 100.x.x.x hostname: host-1 ip: 100.x.x.x netmask: x - gateway: 100.x.x.x hostname: host-2 ip: 100.x.x.x netmask: x - gateway: 100.x.x.x hostname: host-3 ip: 100.x.x.x netmask: x - gateway: 100.x.x.x hostname: host-4 ip: 100.x.x.x netmask: x ...
Prima di iniziare
Esporta una variabile di ambiente KUBECONFIG
che punta al kubeconfig del cluster utente
che vuoi ridimensionare:
export KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
Ridimensionamento di un cluster utente
Per ridimensionare un cluster, modifica la risorsa MachineDeployment del cluster utente. Per trovare il nome della risorsa MachineDeployment del cluster utente, esegui il comando seguente:
kubectl get machinedeployments
MachineDeployment il cluster utente include il nome del cluster utente.
Per ridimensionare il cluster utente, devi applicare una patch alla configurazione MachineDeployment del cluster. Modifica il valore del campo replicas
della configurazione,
che indica quanti nodi devono essere eseguiti dal cluster:
kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p "{\"spec\": {\"replicas\": [INT] }}" --type=merge
dove [INT] è il numero di nodi in cui deve essere eseguito il cluster utente.
Verifica ridimensionamento
Per verificare che il ridimensionamento sia riuscito, esegui:
kubectl get nodes kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME] | grep Replicas
Il numero di nodi che hai scelto deve essere indicato in questo output'
Risolvere i problemi
Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi.
Ridimensionamento di un cluster utente non riuscito
- Sintomi
Un'operazione di ridimensionamento di un cluster utente non riuscita.
- Potenziali cause
L'esito negativo delle operazioni di ridimensionamento potrebbe essere diverso.
- Risoluzione
Se il ridimensionamento non riesce, segui questi passaggi:
Controlla lo stato MachineDeployment del cluster per verificare se sono presenti eventi o messaggi di errore:
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
Verifica se sono presenti errori nelle macchine appena create:
kubectl describe machine [MACHINE_NAME]
Errore: "Impossibile assegnare indirizzi".
- Sintomi
Dopo aver ridimensionato un cluster utente,
kubectl describe machine [MACHINE_NAME]
visualizza il seguente errore:Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
- Potenziali cause
Non sono disponibili indirizzi IP sufficienti per il cluster utente.
- Risoluzione
Assegna più indirizzi IP per il cluster. Quindi, elimina il computer interessato:
kubectl delete machine [MACHINE_NAME]
Se il cluster è configurato correttamente, viene creata una macchina sostitutiva con un indirizzo IP.
Numero sufficiente di indirizzi IP allocati, ma la macchina non riesce a registrarsi con il cluster
- Sintomi
La rete ha un numero sufficiente di indirizzi allocati, ma la macchina non riesce ancora a registrarsi con il cluster utente.
- Cause possibili
Potrebbe esserci un conflitto IP. L'IP potrebbe essere richiesto da un'altra macchina o dal tuo bilanciatore del carico.
- Risoluzione
Verifica che l'indirizzo IP della macchina interessata non sia stato utilizzato. In caso di conflitto, devi risolvere il conflitto nel tuo ambiente.
Nuovi nodi creati ma non integri
- Sintomi
I nuovi nodi non si registrano al piano di controllo del cluster utente quando utilizzi la modalità di bilanciamento del carico manuale.
- Cause possibili
La convalida Ingress in nodo può essere abilitata che blocca il processo di avvio dei nodi.
- Risoluzione
Per disattivare la convalida, esegui:
kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge
Diagnostica dei problemi del cluster con gkectl
Utilizza i comandi gkectl diagnose
per identificare i problemi del cluster e condividerli con Google. Consulta
Diagnosi dei problemi del cluster.
Comportamento di logging predefinito
Per gkectl
e gkeadm
è sufficiente utilizzare le impostazioni di logging predefinite:
-
Per impostazione predefinita, le voci di log vengono salvate come segue:
-
Per
gkectl
, il file di log predefinito è/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
e il file è collegato direttamente al filelogs/gkectl-$(date).log
nella directory locale in cui viene eseguitogkectl
. -
Per
gkeadm
, il file di log predefinito èlogs/gkeadm-$(date).log
nella directory locale in cui eseguigkeadm
.
-
Per
- Tutte le voci di log vengono salvate nel file di log, anche se non sono stampate
nel terminale (quando
--alsologtostderr
èfalse
). - Il livello di dettaglio
-v5
(predefinito) copre tutte le voci di log necessarie al team di assistenza. - Il file di log contiene anche il comando eseguito e il messaggio di errore.
Se hai bisogno di aiuto, ti consigliamo di inviare il file di log al team di assistenza.
Specificare una posizione non predefinita per il file di log
Per specificare una posizione non predefinita per il file di log gkectl
, utilizza il flag --log_file
. Il file di log specificato non verrà collegato direttamente alla directory locale.
Per specificare una posizione non predefinita per il file di log gkeadm
, utilizza il flag --log_file
.
Localizzazione dei log dell'API Cluster nel cluster di amministrazione
Se l'avvio di una VM non riesce dopo l'avvio del piano di controllo dell'amministratore, puoi provare a eseguire il debug controllando i controller dell'API cluster nel log:
Trova il nome del pod dei controller API del cluster nello spazio dei nomi
kube-system
, dove [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Apri i log del pod, dove [POD_NAME] è il nome del pod. Se preferisci, utilizza
grep
o uno strumento simile per cercare errori:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager