Versione 1.1. Questa versione non è più supportata come descritto nelle norme relative al supporto delle versioni di Anthos. Per le patch e gli aggiornamenti più recenti per vulnerabilità di sicurezza, esposizioni e problemi che interessano i cluster Anthos su VMware (GKE on-prem), esegui l'upgrade a una versione supportata. La versione più recente è disponibile qui.

Versioni disponibili

Upgrade di GKE On-Prem

Questo argomento spiega come eseguire l'upgrade di GKE On-Prem.

Per eseguire l'upgrade di GKE On-Prem, devi eseguire l'upgrade della workstation di amministrazione. Quindi, esegui l'upgrade dei cluster.

Prima di iniziare

Assicurati di seguire queste istruzioni nella workstation o nel laptop locali. Non seguire queste istruzioni nella workstation di amministrazione esistente.
Controlla la versione corrente dei cluster.
Consulta le Note di rilascio.
Esamina Versioni

Inoltre, leggi le seguenti considerazioni:

Informazioni sul tempo di inattività durante gli upgrade

Risorsa	Descrizione
Cluster di amministrazione	Quando un cluster di amministrazione è inattivo, i piani di controllo e i carichi di lavoro dei cluster utente sui cluster utente continuano a essere eseguiti, a meno che non siano stati interessati da un errore che ha causato il tempo di inattività
Piano di controllo del cluster utente	In genere, non sono previsti tempi di inattività visibili per i piani di controllo del cluster utente. Tuttavia, le connessioni a lunga durata al server API Kubernetes potrebbero interrompersi e dovrebbero essere ripristinate. In questi casi, il chiamante dell'API deve riprovare finché non stabilisce una connessione. Nel peggiore dei casi, può essere necessario fino a un minuto di tempo di inattività durante un upgrade. Nota: se i nodi del cluster utente non sono in grado di raggiungere il piano di controllo dell'utente durante l'upgrade, i nuovi carichi di lavoro non vengono pianificati nel cluster. I carichi di lavoro esistenti non sono interessati.
Nodi del cluster utente	Se un upgrade richiede una modifica ai nodi del cluster utente, GKE On-Prem ricrea i nodi in modo continuativo e ripianifica i pod in esecuzione su questi nodi. Puoi evitare l'impatto sui tuoi carichi di lavoro configurando PodDisruptionBudget e regole di affinità appropriati.

Upgrade sequenziale

GKE On-Prem supporta l'upgrade sequenziale. Per eseguire l'upgrade di un cluster a una nuova versione, il cluster deve essere già alla versione più recente.

Non puoi eseguire l'upgrade dei cluster direttamente alla versione più recente da una versione con più versioni precedenti. Se il tuo cluster è indietro di più di una versione, devi eseguire l'upgrade del cluster in sequenza.

Esempio

Supponi che siano disponibili le seguenti versioni e che la tua workstation di amministrazione e i tuoi cluster utilizzino la versione meno recente:

1.0.1 (versione precedente)
1.0.2
1.1 (versione più recente)

In questo caso, 1.1 è l'ultima versione. Per eseguire l'upgrade da 1.0.1 a 1.1, devi seguire questi passaggi:

Aggiorna la tua workstation di amministrazione da 1.0.1 a 1.0.2.
Aggiorna i tuoi cluster da 1.0.1 a 1.0.2.
Esegui l'upgrade della workstation di amministrazione da 1.0.2 a 1.1.
Aggiorna i tuoi cluster da 1.0.2 a 1.1.

Esegui il backup dei file di configurazione GKE On-Prem e kubeconfig

Quando esegui l'upgrade della workstation di amministrazione, Terraform elimina la VM della workstation di amministrazione e la sostituisce con una workstation di upgrade aggiornata. Prima di eseguire l'upgrade della workstation di amministrazione, devi eseguire il backup del file di configurazione di GKE On-Prem e dei file kubeconfig dei cluster. Successivamente, copi i file nella workstation di amministrazione che hai eseguito.

Upgrade della workstation di amministrazione

L'upgrade della workstation di amministrazione include le seguenti entità nella stessa versione del file Open Virtual Appliance (OVA) della workstation di amministrazione:

gkectl
gruppo completo

Dopo aver eseguito l'upgrade della workstation di amministrazione, esegui l'upgrade dei cluster.

Download dell'OVA

Da Download, scarica il file OVA della workstation di amministrazione per la versione di cui stai eseguendo l'upgrade.

Per scaricare l'OVA più recente, esegui il comando seguente:

gsutil cp gs://gke-on-prem-release/admin-appliance/1.1.2-gke.0/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.{ova,ova.sig} ~/

Importazione dell'OVA in vSphere e contrassegno come modello VM

Nelle sezioni seguenti:

Crea alcune variabili che dichiarano gli elementi del tuo ambiente vCenter Server e vSphere.
Importa l'OVA della workstation di amministrazione in vSphere e contrassegnalo come modello VM.

Creazione delle variabili per `govc` in corso...

Prima di importare l'OVA della workstation di amministrazione in vSphere, devi fornire govc alcune variabili che dichiarano gli elementi del tuo ambiente vCenter Server e vSphere:

export GOVC_URL=https://[VCENTER_SERVER_ADDRESS]/sdk
export GOVC_USERNAME=[VCENTER_SERVER_USERNAME]
export GOVC_PASSWORD=[VCENTER_SERVER_PASSWORD]
export GOVC_DATASTORE=[VSPHERE_DATASTORE]
export GOVC_DATACENTER=[VSPHERE_DATACENTER]
export GOVC_INSECURE=true

Puoi scegliere di utilizzare il pool di risorse predefinito di vSphere o di crearne uno tuo:

# If you want to use a resource pool you've configured yourself, export this variable:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources/[VSPHERE_RESOURCE_POOL]

# If you want to use vSphere's default resource pool, export this variable instead:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources

dove:

[VCENTER_SERVER_ADDRESS] è l'indirizzo o il nome host del tuo vCenter Server.
[VCENTER_SERVER_USERNAME] è il nome utente di un account con il ruolo Amministratore o privilegi equivalenti in vCenter Server.
[VCENTER_SERVER_PASSWORD] è la password dell'account vCenter Server.
[VSPHERE_DATASTORE] è il nome del datastore che hai configurato nel tuo ambiente vSphere.
[VSPHERE_DATACENTER] è il nome del data center che hai configurato nel tuo ambiente vSphere.
[VSPHERE_CLUSTER] è il nome del cluster configurato nel tuo ambiente vSphere.
[VSPHERE_RESOURCE_POOL] è il nome del pool di risorse che hai configurato nel tuo ambiente vSphere.

Importazione dell'OVA in vSphere: passaggio standard

Se utilizzi un vSphere Standard Switch, importa l'OVA in vSphere utilizzando questo comando:

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true
}
EOF

Importazione dell'OVA in vSphere: sensore distribuito

Se utilizzi uno scambio vSphere, importa l'OVA in vSphere tramite questo comando, dove [YOUR_DISTRIBUTED_PORT_GROUP_NAME] è il nome del tuo gruppo di porte distribuito:

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true,
  "NetworkMapping": [
      {
          "Name": "VM Network",
          "Network": "[YOUR_DISTRIBUTED_PORT_GROUP_NAME]"
      }
  ]
}
EOF

Impostazione della variabile del modello Terraform per la nuova VM della workstation di amministrazione

Nel tuo file TFVARS della workstation di amministrazione, imposta vm_template sulla versione su cui stai eseguendo l'upgrade. Il valore di vm_template ha il seguente aspetto, dove [VERSION] è la versione dell'OVA:

gke-on-prem-admin-appliance-vsphere-[VERSION]

Utilizzo di Terraform per eseguire l'upgrade della workstation di amministrazione

Per eseguire l'upgrade della workstation di amministrazione, esegui questo comando: Questo comando elimina la VM della workstation di amministrazione attuale e la sostituisce con una VM aggiornata:

terraform init && terraform apply -auto-approve -input=false

Connessione alla workstation di amministrazione in corso...

Accedi tramite SSH alla workstation di amministrazione:

ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

Se utilizzi un proxy, devi configurare Google Cloud CLI per il proxy, in modo da poter eseguire i comandi gcloud e gsutil. Per le istruzioni, consulta la pagina sulla configurazione dell'interfaccia a riga di comando gcloud da utilizzare dietro un proxy/firewall.
Accedi a Google Cloud utilizzando le credenziali del tuo account:
```
gcloud auth login
```
Registra gcloud come assistente delle credenziali Docker. Scopri di più su questo comando:
```
gcloud auth configure-docker
```
Crea una chiave privata per il tuo account di servizio incluso nella lista consentita.

Copia l'indirizzo email dell'account di servizio:
```
gcloud iam service-accounts list
```
Crea la chiave privata dell'account di servizio, dove [KEY_FILE]è un nome che scegli per il file. Questo comando salva il file nella directory di lavoro attuale:
```
gcloud iam service-accounts keys create key.json \
--project [PROJECT_ID] --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]
```
dove:
- [PROJECT_ID] è l'ID progetto.
- [KEY_FILE] è un nome e un percorso in cui salvare la chiave privata dell'account di servizio, ad esempio /home/ubuntu/key.json.
- [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email dell'account di servizio incluso nella lista consentita.

Attiva il tuo account di servizio incluso nella lista consentita:

gcloud auth activate-service-account --project [PROJECT_ID] \
--key-file [KEY_FILE]

Copia i file di configurazione e kubeconfig di cui hai effettuato il backup

In precedenza, hai eseguito il backup del file di configurazione GKE On-Prem e dei file dei cluster kubeconfig. Ora, devi copiare i file nella workstation di amministrazione aggiornata.

Aggiornamento dei cluster

Dopo aver eseguito l'upgrade della workstation di amministrazione e aver effettuato la connessione, procedi nel seguente modo:

Verifica che siano disponibili indirizzi IP sufficienti

Prima di eseguire l'upgrade, assicurati di avere a disposizione un numero sufficiente di indirizzi IP per i tuoi cluster.

DHCP

Se i relativi indirizzi IP del cluster sono assegnati da un server DHCP, verifica che il server DHCP nella rete in cui vengono creati i nodi abbia un numero di indirizzi IP sufficiente. Dovrebbero esserci più indirizzi IP di quanti nodi sono in esecuzione nel cluster utente.

IP statici

Se il cluster ha indirizzi 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 il kubeconfig del cluster di amministrazione, utilizzato per visualizzare e/o modificare le configurazioni dei cluster utente.
-n [USER_CLUSTER_NAME] indica a kubectl di cercare in uno spazio dei nomi denominato in base al cluster utente.
[USER_CLUSTER_NAME] -o yaml indica a kubectl il cluster utente su cui esegui il comando. -o yaml visualizza la configurazione del cluster utente.

Nell'output del comando, cerca il campo reservedAddresses. Nel campo dovrebbero essere presenti più indirizzi IP rispetto al numero di nodi in esecuzione nel cluster utente.

Se devi aggiungere altri indirizzi nel campo reservedAddresses, segui questi passaggi:

Apri il file di configurazione del cluster utente per la modifica:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \
-n [USER_CLUSTER_NAME] --validate=false
```
La configurazione del cluster è aperta nell'editor predefinito della tua shell.
Aggiungi tutti i blocchi IP statici aggiuntivi che vuoi. Si compone di un blocco IP composto da campi gateway, hostname, ip e netmask.

Nota: è sempre sicuro aggiungere più blocchi IP al campo reservedAddresses, ma non è sicuro rimuovere gli indirizzi IP in uso.

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
...

Modificare il file di configurazione

Sulla VM della workstation di amministrazione, modifica il file di configurazione. Imposta il valore di bundlepath, dove [VERSION] è la versione di GKE On-Prem su cui stai eseguendo l'upgrade dei tuoi cluster:

bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz

Informazioni sulle funzionalità attivate automaticamente

Una nuova versione di GKE On-Prem potrebbe includere nuove funzionalità o supporto per specifiche funzionalità VMware vSphere. A volte l'upgrade a una versione GKE On-Prem abilita automaticamente tali funzionalità. Scopri le nuove funzionalità nelle Note di rilascio di GKE On-Prem. Nel nuovo file di configurazione di GKE On-Prem sono presenti nuove funzionalità.

Disattivazione di nuove funzionalità tramite il file di configurazione

Se devi disabilitare una nuova funzionalità abilitata automaticamente in una nuova versione di GKE On-Prem e basata sul file di configurazione, esegui i passaggi seguenti prima di eseguire l'upgrade del cluster:

Dalla workstation di amministrazione aggiornata, crea un nuovo file di configurazione con un nome diverso da quello in uso:
```
gkectl create-config --config [CONFIG_NAME]
```
Apri il nuovo file di configurazione e il campo della funzionalità. Chiudi il file.
Apri il file di configurazione attuale e aggiungi il campo della nuova funzionalità nella specifica appropriata.
Specifica nel campo un valore false o equivalente.
Salva il file di configurazione. Procedi all'upgrade dei cluster.

Controlla sempre le Note di rilascio prima di eseguire l'upgrade dei cluster. Non puoi modificare in modo dichiarativo una configurazione del cluster esistente dopo aver eseguito l'upgrade.

`gkectl prepare` in esecuzione

Esegui questo comando:

gkectl prepare --config [CONFIG_FILE]

Il comando gkectl prepare esegue le seguenti attività:

Se necessario, copia una nuova immagine del sistema operativo nodo nel tuo ambiente vSphere e contrassegna l'immagine sistema operativo come modello.
Esegui il push di immagini Docker aggiornate, specificate nel nuovo bundle, al tuo registro Docker privato, se ne hai configurato una.

Upgrade del cluster di amministrazione

Esegui questo comando:

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

dove [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione e [CONFIG_FILE] è il file di configurazione di GKE On-Prem che stai utilizzando per eseguire l'upgrade.

Upgrade del cluster utente

Per eseguire l'upgrade di un cluster utente, il cluster di amministrazione deve avere una versione almeno pari alla versione di destinazione del cluster utente. Se la versione del tuo cluster di amministrazione non è elevata, esegui l'upgrade del cluster di amministrazione prima di eseguire l'upgrade del cluster utente.

Gkectl

Dalla workstation di amministrazione, esegui il comando seguente:

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME]

dove [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione, [CLUSTER_NAME] è il nome del cluster utente che stai aggiornando e [CONFIG_FILE] è il file di configurazione di GKE On-Prem che stai utilizzando per eseguire l'upgrade.

console

Puoi scegliere di registrare i tuoi cluster utente con Google Cloud Console durante l'installazione o dopo averli creati. Puoi visualizzare e accedere ai tuoi cluster GKE On-Prem registrati e ai tuoi cluster Google Kubernetes Engine dal menu GKE di Google Cloud Console.

Quando diventa disponibile un upgrade per i cluster utente GKE On-Prem, viene visualizzata una notifica in Google Cloud Console. Se fai clic su questa notifica viene visualizzato un elenco delle versioni disponibili e un comando gkectl che puoi eseguire per eseguire l'upgrade del cluster:

Vai al menu GKE in Google Cloud Console.

Visita il menu GKE On-Prem
Nella colonna Notifiche per il cluster utente, fai clic su Upgrade disponibile, se disponibile.
Copia il comando gkectl upgrade cluster.
Dalla workstation, esegui il comando gkectl upgrade cluster, dove [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione, [CLUSTER_NAME] è il nome del cluster utente di cui esegui l'upgrade e [CONFIG_FILE] è il file di configurazione di GKE On-Prem che stai utilizzando per eseguire l'upgrade.

Ripresa dell'upgrade

Se un upgrade del cluster utente viene interrotto, ma è stato eseguito l'upgrade del cluster di amministrazione, puoi riprendere l'upgrade eseguendo di nuovo gkectl upgrade cluster con lo stesso file di configurazione di GKE On-Prem e il cluster di amministrazione kubeconfig.

Informazioni sul ripristino di un upgrade del cluster di amministrazione

Non interrompere un upgrade del cluster di amministrazione. Al momento gli upgrade dei cluster di amministrazione non sono sempre ripristinabili. Se un upgrade del cluster di amministrazione viene interrotto per qualsiasi motivo, devi contattare l'assistenza.

Problemi noti

I seguenti problemi noti interessano l'upgrade dei cluster.

Interruzione per i carichi di lavoro con PodDisruptionBudget

Attualmente, l'upgrade dei cluster può causare interruzioni o tempi di inattività per i carichi di lavoro che utilizzano PodDisruptionBudget (PDB).

Versione 1.1.1-gke.2: il disco dati nella cartella del datastore vSAN può essere eliminato

Se utilizzi un datastore vSAN, devi creare una cartella in cui salvare il VMDK. Attualmente, un problema noto richiede che il percorso dell'identificatore univoco universale (UUID) della cartella, anziché il suo percorso file, venga inviato a vcenter.datadisk. Questa mancata corrispondenza può causare errori degli upgrade.

È stata applicata una correzione per la versione 1.1.2. Prima di eseguire l'upgrade, esegui questi passaggi per il nodo del piano di controllo dell'amministratore come soluzione alternativa:

Dall'interfaccia di vCenter, recupera l'UUID della cartella nel tuo datastore vSAN.
Elenca le risorse del computer nei tuoi cluster. Queste macchine corrispondono ai nodi nei cluster:
```
kubectl get machines -n all
```
Per la macchina del piano di controllo dell'amministratore (gke-admin-master), apri la configurazione per la modifica:
```
kubectl edit machine [MACHINE_NAME]
```

Modifica il campo spec.providerSpec.value.machineVariables.data_disk_path. Sostituisci il percorso del file VMDK con l'UUID. Ad esempio:

spec:
providerSpec:
 value:
   apiVersion: vsphereproviderconfig.k8s.io/v1alpha1
   kind: VsphereMachineProviderConfig
   machineVariables:
     data_disk_path: 14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk
     datacenter: datacenter
     datastore: datastore

Salva il file.
Apri il file di configurazione GKE On-Prem.
Da vcenter.datadisk, sostituisci la cartella nel percorso del file con l'UUID della cartella. Ad esempio:
```
vcenter:
 ...
 datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
```
Procedi all'upgrade dei cluster.

Upgrade alla versione 1.1.0-gke.6 dalla versione 1.0.2-gke.3: problema OIDC

Non è possibile eseguire l'upgrade dei cluster della versione 1.0.11, 1.0.1-gke.5 e 1.0.2-gke.3 in cui è configurato OpenID Connect (OIDC). Questo problema è stato risolto nella versione 1.1.1-gke.2.

Se hai configurato un cluster versione 1.0.11, 1.0.1-gke.5 o 1.0.2-gke.3 con OIDC durante l'installazione, non puoi eseguirne l'upgrade. Devi invece creare nuovi cluster.

Upgrade alla versione 1.0.2-gke.3 dalla versione 1.0.11

La versione 1.0.2-gke.3 introduce i seguenti campi OIDC (usercluster.oidc). Questi campi consentono di accedere a un cluster da Google Cloud Console:

usercluster.oidc.kubectlredirecturl
usercluster.oidc.clientsecret
usercluster.oidc.usehttpproxy

Se vuoi utilizzare OIDC, il campo clientsecret è obbligatorio anche se non vuoi accedere a un cluster da Google Cloud Console. Per utilizzare OIDC, potrebbe essere necessario fornire un valore segnaposto per clientsecret:

oidc:
  clientsecret: "secret"

Appendice

Informazioni sulle regole DRS di VMware abilitate nella versione 1.1.0-gke.6

A partire dalla versione 1.1.0-gke.6, GKE On-Prem crea automaticamente le regole anti-affinità di VMware Distributed Resource Scheduler (DRS) per i nodi del cluster utente, determinando la loro distribuzione in almeno tre host fisici del data center. A partire dalla versione 1.1.0-gke.6, questa funzionalità è abilitata automaticamente per i nuovi cluster e i cluster esistenti.

Prima di eseguire l'upgrade, assicurati che il tuo ambiente vSphere soddisfi le seguenti condizioni:

VMware DRS è abilitato. VMware DRS richiede la versione di licenza vSphere Enterprise Plus. Per informazioni su come abilitare gli DRS, consulta Abilitare DRS VMware in un cluster
L'account utente vSphere fornito nel campo vcenter dispone dell'autorizzazione Host.Inventory.EditCluster.
Sono disponibili almeno tre host fisici.

Disabilitazione di DRS VMware prima dell'upgrade a 1.1.0-gke.6

Se non vuoi abilitare questa funzionalità per i cluster utente esistenti, ad esempio se non disponi di un numero sufficiente di host per ospitare la funzionalità, esegui i passaggi seguenti prima di eseguire l'upgrade dei cluster utente:

Apri il file di configurazione GKE On-Prem esistente.
Sotto la specifica usercluster, aggiungi il campo antiaffinitygroups come descritto nella documentazione di antiaffinitygroups:
```
usercluster:
      ...
      antiaffinitygroups:
        enabled: false
```
Salva il file.
Utilizza il file di configurazione per eseguire l'upgrade. Viene eseguito l'upgrade dei cluster, ma la funzionalità non è abilitata.

Scenario di upgrade alternativo

Questo argomento descrive il modo più semplice per eseguire l'upgrade di GKE On-Prem. La tabella riportata di seguito descrive uno scenario di upgrade alternativo. In questo scenario, eseguirai l'upgrade solo a gkectl e ai tuoi cluster, senza eseguire l'upgrade della workstation di amministrazione:

Scenario	Procedura
La release non ha aggiornamenti della sicurezza per la workstation di amministrazione.	Scarica `gkectl`. Scarica il pacchetto. Segui le istruzioni fornite in questa pagina.

Risolvere i problemi

Per saperne di più, consulta la sezione Risoluzione dei problemi.

Nuovi nodi creati ma non integri

Sintomi

I nuovi nodi non vengono registrati nel piano di controllo del cluster utente quando utilizzi la modalità di bilanciamento del carico manuale.

Cause possibili

La convalida di Ingress in-node 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 utilizzando `gkectl`

Utilizza i comandi gkectl diagnoseper identificare i problemi del cluster e condividere le informazioni sul cluster con Google. Consulta la sezione 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 automaticamente al file logs/gkectl-$(date).log nella directory locale in cui esegui gkectl.
- Per gkeadm, il file di log predefinito è logs/gkeadm-$(date).log nella directory locale in cui esegui gkeadm.
Tutte le voci di log vengono salvate nel file di log, anche se non vengono 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.

Ti consigliamo di inviare il file del log al team di assistenza quando hai bisogno di aiuto.

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 alla directory locale.

Per specificare una posizione non predefinita per il file di log gkeadm, utilizza il flag --log_file.

Individuare i log dell'API del cluster nel cluster di amministrazione

Se l'avvio di una VM non va a buon fine dopo l'avvio del piano di controllo dell'amministratore, puoi tentare di eseguire il debug controllando i controller dell'API del cluster' log nel cluster di amministrazione:

Trova il nome del pod dei controller dell'API 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. Facoltativamente, utilizza grep o uno strumento simile per cercare gli errori:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
```