Versione 1.7. Questa versione è supportata come descritto nel criterio di supporto per le versioni di Anthos, che offre le patch e gli aggiornamenti più recenti per vulnerabilità di sicurezza, esposizioni e problemi che interessano i cluster Anthos su VMware (GKE on-prem). Per ulteriori informazioni, leggi le note di rilascio. Questa non è la versione più recente.

Versioni disponibili

Risoluzione dei problemi relativi alla creazione e all'upgrade dei cluster

Questa pagina mostra come esaminare i problemi relativi alla creazione, all'upgrade e al ridimensionamento dei cluster nei cluster Anthos su VMware (GKE on-prem).

Comportamento di registrazione predefinito per `gkectl` e `gkeadm`

Per gkectl e gkeadm è sufficiente utilizzare le impostazioni di logging predefinite:

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 viene eseguito gkectl.
Per gkeadm, il file di log predefinito è logs/gkeadm-$(date).log nella directory locale in cui esegui gkeadm.
Il livello di dettaglio predefinito di -v5 copre tutte le voci di log necessarie al team di assistenza.

Il file di log include il comando eseguito e il messaggio di errore.

Quando hai bisogno di aiuto, ti consigliamo di inviare il file di log al team di assistenza.

Specificare posizioni diverse da quelle predefinite per i 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 viene 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 esaminare il problema esaminando i log dal pod del controller dell'API Cluster nel cluster di amministrazione.

Trova il nome del pod dei controller dell'API Cluster:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    get pods | grep clusterapi-controllers

Visualizza i log di vsphere-controller-manager. Per iniziare, specifica il pod, ma nessun container:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME

L'output indica che devi specificare un container e i nomi dei container nel pod. Ad esempio:

... a container name must be specified ...,
choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]

Scegli un container e visualizza i relativi log:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME --container CONTAINER_NAME

Utilizzo di `govc` per risolvere i problemi relativi a vSphere

Puoi utilizzare govc per esaminare i problemi relativi a vSphere. Ad esempio, puoi confermare le autorizzazioni e l'accesso per i tuoi account utente vCenter e puoi raccogliere i log vSphere.

Debug utilizzando i log del cluster di bootstrap

Durante l'installazione, i cluster Anthos su VMware creano un cluster di bootstrap temporaneo. Una volta completata l'installazione, i cluster Anthos su VMware eliminano il cluster di bootstrap, lasciando il cluster di amministrazione e il cluster utente. In genere, non dovrebbe esserci alcun motivo per interagire con il cluster di bootstrap.

Se passi --cleanup-external-cliuster=false a gkectl create cluster, il cluster di bootstrap non viene eliminato e puoi utilizzare i log del cluster di bootstrap per eseguire il debug dei problemi di installazione.

Trova i nomi dei pod in esecuzione nello spazio dei nomi kube-system:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

Visualizza i log di un pod:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME

Modifica del certificato vCenter

Se stai utilizzando un server vCenter in modalità di configurazione predefinita o di valutazione e ha un certificato TLS generato, il certificato potrebbe cambiare nel tempo. Se il certificato è cambiato, devi informare i cluster in esecuzione del nuovo certificato:

Recupera il nuovo certificato vCenter e decomprimilo:
```
curl -k -o certs.zip https://VCENTER_IP_ADDRESS/certs/download.zip
unzip certs.zip
```
Il flag -k consente i certificati sconosciuti. per evitare problemi con i certificati che potresti riscontrare durante l'accesso a vCenter.
Salva il certificato Linux in un file denominato vcenter-ca.pem:
```
cat certs/lin/*.0 > vcenter-ca.pem
```
Nel file di configurazione del cluster di amministrazione, imposta vCenter.caCertPath il percorso del nuovo file vcenter-ca.pem.
Utilizza SSH per connetterti al nodo del piano di controllo del tuo cluster di amministrazione.

Nel nodo, sostituisci i contenuti di /etc/vsphere/certificate/ca.crt con i contenuti di vcenter.pem.

Esci dalla connessione SSH.

Elimina i ConfigMap vcenter-ca-certificate. Ne esiste uno nello spazio dei nomi kube-system e uno in ogni spazio dei nomi del cluster utente. Ad esempio:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete configmap vsphere-ca-certificate \
    --namespace kube-system
...
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete configmap vsphere-ca-certificate \
    --namespace user-cluster1

Creare nuovi oggetti ConfigMap con il nuovo certificato. Ad esempio:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create configmap \
    --namespace kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem \
    --output yaml  | kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f -
...
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create configmap \
    --namespace user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem \
    --output yaml  | kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f -

Riavvia il container che contiene i pod statici nel piano di controllo dell'amministratore:
- SSH nella VM dell'amministratore.
- Esegui docker restart.
Successivamente, aggiorna i dati del certificato CA nel secret di creazione dell'amministratore.
- Recupera il secret e decodifica il valore data.cfg dall'output:
```
kubectl get secret create-config -n kube-system -o jsonpath={.data.cfg} | base64 -d > admin-create-config.yaml
```
  "
- Confronta il valore in admincluster.spec.cluster.vsphere.cacertdata con il nuovo certificato CA vCenter.
- Se i due valori sono diversi, devi modificare il secret create-config dell'amministratore per aggiungere il nuovo certificato CA. Nel file admin-create-config.yaml, copia il risultato dalla decodifica in base-64 e sostituisci il valore di admincluster.spec.cluster.vsphere.cacertdata con il nuovo certificato CA vCenter.
- Codifica il valore del passaggio precedente: cat admin-create-config.yaml | base64 -w0 > admin-create-config.b64
- Modifica il secret di create-config e sostituisci il valore data.cfg con il valore codificato:
```
kubectl --kubeconfig ADMIN_KUBECONFIG edit secrets -n kube-system create-config
```
Ora aggiorna i dati del certificato CA nei secret di create-config per i cluster utente.

Modifica il secret di create-config e sostituisci il valore data.cfg con il valore codificato base64 che hai creato nel passaggio precedente. Ad esempio:
```
kubectl --kubeconfig ADMIN_KUBECONFIG edit secrets -n user-cluster-1 create-config
```

Elimina i seguenti pod nei cluster utente.

controller-api
kube-controller-manager
kube-apiserver
controller-sfera-csi
esportatore vSphere-metrics

Per ottenere i nomi dei pod, esegui:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep clusterapi
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep kube-controller-manager
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep kube-apiserver
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep vsphere-csi-controller
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep vsphere-metrics-exporter

Elimina i pod che hai trovato nel passaggio precedente:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace NAMESPACE \
    delete pod POD_NAME

Quando i pod si riavviano, usano il nuovo certificato.

Debug dei problemi BIG-IP di F5 utilizzando il file kubeconfig interno

Dopo l'installazione, Cluster Anthos su VMware genera un file kubeconfig denominato internal-cluster-kubeconfig-debug nella home directory della workstation di amministrazione. Questo file kubeconfig è identico al file kubeconfig del cluster di amministrazione, ad eccezione del fatto che rimanda direttamente al nodo del piano di controllo del cluster di amministrazione, dove viene eseguito il server API Kubernetes. Puoi utilizzare il file internal-cluster-kubeconfig-debug per eseguire il debug dei problemi relativi a BIG-IP di F5.

Ridimensionamento di un cluster utente non riuscito

Se un ridimensionamento di un cluster utente non riesce:

Trova i nomi dei MachineDeployment e dei Machines:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

Descrivi un MachineDeployment per visualizzare i relativi log:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME

Verifica la presenza di errori sui computer appena creati:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Non è possibile assegnare indirizzi per il ridimensionamento del cluster

Questo problema si verifica se non sono disponibili indirizzi IP sufficienti per ridimensionare un cluster utente.

kubectl describe machine mostra il seguente errore:

Events:
Type     Reason  Age                From                    Message
----     ------  ----               ----                    -------
Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated

Per risolvere il problema, alloca più indirizzi IP per il cluster. Quindi, elimina il computer interessato:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME

I cluster Anthos su VMware creano una nuova macchina e gli assegna uno degli indirizzi IP appena disponibili.

Numero sufficiente di indirizzi IP allocati, ma la macchina non riesce a registrarsi con il cluster

Questo problema può verificarsi in caso di conflitto di indirizzi IP. Ad esempio, un indirizzo IP specificato per una macchina viene utilizzato per un bilanciatore del carico.

Per risolvere questo problema, aggiorna il file di blocco IP del cluster in modo che gli indirizzi delle macchine non siano in conflitto con gli indirizzi specificati nel file di configurazione del cluster o nel file di blocco IP di Seesaw.

Lo snapshot viene creato automaticamente quando la creazione o l'upgrade del cluster di amministrazione non riesce

Se provi a creare o eseguire l'upgrade di un cluster di amministrazione e l'operazione non riesce, Cluster Anthos su VMware crea uno snapshot esterno del cluster di bootstrap, ovvero un cluster temporaneo utilizzato per creare o eseguire l'upgrade del cluster di amministrazione. Anche se questo snapshot del cluster di bootstrap è simile allo snapshot eseguito eseguendo il comando gkectl diagnose snapshot sul cluster di amministrazione, viene attivato automaticamente. Questo snapshot del cluster di bootstrap contiene informazioni di debug importanti per il processo di creazione e upgrade del cluster di amministrazione. Se necessario, puoi fornire questo snapshot all'assistenza Google Cloud.

Il processo di upgrade si blocca

I cluster Anthos su VMware, dietro le quinte, utilizzano il comando drain di Kubernetes durante un upgrade. Questa procedura di drain può essere bloccata da un deployment con una sola replica creata mediante un PodDisruptionBudget (PDB) con minAvailable: 1.

In tal caso, salva il PDB e rimuovilo dal cluster prima di tentare l'upgrade. Potrai quindi aggiungere nuovamente il PDB al termine dell'upgrade.