Risolvere i problemi

Le sezioni seguenti descrivono i problemi che potresti riscontrare durante l'utilizzo di GKE On-Prem e come risolverli.

Prima di iniziare

Controlla le sezioni seguenti prima di iniziare a risolvere un problema.

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:

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

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

Installazione

Eseguire il debug dei problemi di BIG-IP di F5 utilizzando il nodo kubeconfig del piano di controllo del cluster di amministrazione

Dopo un'installazione, GKE On-Prem genera un file kubeconfig nella home directory della workstation di amministrazione denominata internal-cluster-kubeconfig-debug. Questo file kubeconfig è identico a kubeconfig del tuo cluster di amministrazione, tranne per il fatto che rimanda direttamente al nodo del piano di controllo del cluster di amministrazione, dove viene eseguito il piano di controllo dell'amministratore. Puoi utilizzare il file internal-cluster-kubeconfig-debug per eseguire il debug dei problemi di BIG-IP di F5.

La convalida di gkectl check-config non riesce: non riesce a trovare le partizioni BIG-IP di F5.

Sintomi

La convalida non riesce perché non è possibile trovare le partizioni BIG-IP di F5, anche se esistono.

Potenziali cause

Un problema con l'API F5 BIG-IP può causare la mancata convalida della convalida.

Risoluzione

Prova a eseguire di nuovo gkectl check-config.

gkectl prepare --validate-attestations non riuscito: impossibile convalidare l'attestazione build

Sintomi

L'esecuzione di gkectl prepare con il flag --validate-attestations facoltativo restituisce il seguente errore:

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY

Potenziali cause

Potrebbe non esistere un'attestazione per le immagini interessate.

Risoluzione

Prova a scaricare ed eseguire nuovamente il deployment dell'OVA della workstation di amministrazione, come indicato in Creare una workstation di amministrazione. Se il problema persiste, contatta Google per ricevere assistenza.

Debug utilizzando i log del cluster di bootstrap

Durante l'installazione, GKE On-Prem crea un cluster di bootstrap temporaneo. Una volta completata l'installazione, GKE On-Prem elimina il cluster bootstrap, lasciando il cluster di amministrazione e il cluster utente. In genere, non dovrebbe esserci alcun motivo per interagire con questo cluster.

Se si verifica un problema durante un'installazione e hai superato il comando --cleanup-external-cluster=false per gkectl create cluster, potrebbe essere utile eseguire il debug utilizzando i log del cluster di bootstrap. Puoi trovare il pod e recuperare i relativi log:

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

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

Plug-in di autenticazione per Anthos

Mantenere aggiornata l'interfaccia a riga di comando di gcloud anthos auth

Molti problemi comuni possono essere evitati controllando che i componenti dell'installazione di gcloud anthos auth siano aggiornati con le correzioni della release più recente.

Ci sono due parti da verificare perché il comando gcloud anthos auth ha una logica nel componente principale gcloud e in un componente anthos-auth pacchettizzato separatamente.

• Il componente principale di gcloud.

  • Per aggiornare il componente principale gcloud, esegui

    gcloud components update

  • Verifica che l'installazione di gcloud non sia obsoleta eseguendo il comando seguente e verificando che la data di stampa sia compresa negli ultimi 12 giorni.

    gcloud version

• Il componente anthos-auth.

  • Per aggiornare il componente anthos-auth, esegui

    gcloud components install anthos-auth

  • Verifica che la tua installazione anthos-auth non sia obsoleta eseguendo il comando seguente e verificando che la versione sia 1.1.3 o successiva.

    gcloud anthos auth version

apt-get installazioni di gcloud

Per controllare se l'installazione di gcloud è gestita tramite apt-get, esegui il comando gcloud components update e controlla che non si sia verificato il seguente errore.

$ gcloud components update
ERROR: (gcloud.components.update)
You cannot perform this action because the gcloud CLI component manager
is disabled for this installation. You can run the following command
to achieve the same result for this installation:
...

Problema: non puoi eseguire questa azione perché il gestore componenti dell'interfaccia a riga di comando gcloud è disabilitato per questa installazione:

Per le installazioni gestite tramite apt-get, l'esecuzione dei comandi gcloud components riportati sopra non funzionerà direttamente e genererà un messaggio di errore simile a quello riprodotto sopra. Tuttavia, l'esecuzione dei comandi gcloud components update e gcloud components install anthos-auth stamperà i comandi apt-get specifici che puoi eseguire per aggiornare l'installazione.

Errore durante l'esecuzione di gkectl create-login-config

Problema 1:

Sintomi

Quando esegui gkectl create-login-config, si verifica il seguente errore:

Error getting clientconfig using [user_cluster_kubeconfig]

Potenziali cause

Questo errore indica che il file kubeconfig passato a gkectl create-login-config non riguarda un cluster utente o che il CRD di ClientConfig non è stato visualizzato durante la creazione del cluster.

Risoluzione

Esegui questo comando per vedere se il CRD ClientConfig è nel cluster:

kubectl --kubeconfig
  [user_cluster_kubeconfig] get clientconfig default -n kube-public

Problema 2:

Sintomi

Quando esegui gkectl create-login-config, si verifica il seguente errore:

error merging with file [merge_file] because [merge_file] contains a
  cluster with the same name as the one read from [kubeconfig]. Please write to
  a new output file

Potenziali cause

Ogni file di configurazione di accesso deve contenere nomi di cluster univoci. Se viene visualizzato questo errore, il file in cui stai scrivendo i dati di configurazione dell'accesso contiene un nome cluster già esistente nel file di destinazione.

Risoluzione

Scrivi su un nuovo file --output. Tieni presente quanto segue:

• Se --output non viene fornito, i dati di configurazione dell'accesso saranno scritti in un file chiamato kubectl-anthos-config.yaml nella directory attuale per impostazione predefinita.
• Se --output esiste già, il comando tenterà di unire la nuova configurazione di accesso a --output.

Errore durante l'esecuzione di gcloud anthos auth login

Nota: il plug-in di autenticazione per Anthos avvia un browser per autenticare gli utenti.

Problema 1:

Sintomi

L'esecuzione di login utilizzando il plug-in di autenticazione e il file YAML di configurazione dell'accesso generato non riescono.

Potenziali cause

Potrebbe esserci un errore nei dettagli di configurazione OIDC.

Risoluzione

Verifica la registrazione del client OIDC con l'amministratore.

Problema 2:

Sintomi

Quando un proxy è configurato per il traffico HTTPS, l'esecuzione del comando gcloud anthos auth login non riesce con proxyconnect tcp nel messaggio di errore. Ecco un esempio del tipo di messaggio che potresti visualizzare: proxyconnect tcp: tls: first record does not look like a TLS handshake.

Potenziali cause

Potrebbe esserci un errore nelle configurazioni delle variabili di ambiente https_proxy o HTTPS_PROXY. Se è presente un elemento https:// specificato nelle variabili di ambiente, le librerie client HTTP GoLang potrebbero non riuscire se il proxy è configurato per gestire le connessioni HTTPS utilizzando altri protocolli, come SOCK5.

Risoluzione

Modifica le variabili di ambiente https_proxy e HTTPS_PROXY in modo da omettere il prefisso https://. Su Windows, modifica le variabili di ambiente del sistema. Ad esempio, cambia il valore della variabile di ambiente https_proxy da https://webproxy.example.com:8000 a webproxy.example.com:8000.

Errore durante l'utilizzo di kubeconfig generato da gcloud anthos auth login per accedere al cluster

Sintomi

Errore "Non autorizzato"

Se si verifica un errore "Non autorizzato" quando utilizzi kubeconfig generato da gcloud anthos auth login per accedere al cluster, significa che l'apiserver non è in grado di autorizzare l'utente.

Potenziali cause

I RBAC appropriati sono mancanti o errati oppure è presente un errore nella configurazione OIDC per il cluster.

Risoluzione

Prova a risolvere il problema seguendo questi passaggi:

1. Analizza id-token da kubeconfig.

   Nel file kubeconfig generato dal comando di accesso, copia il file id-token:

   kind: Config
   …
   users:
   - name: …
     user:
       auth-provider:
         config:
           id-token: [id-token]
           …
   

   Segui i passaggi per installare jwt-cli ed eseguire:

   jwt [id-token]

2. Verifica la configurazione OIDC.

   La sezione oidc compilata in config.yaml, utilizzata per creare il cluster, contiene i campi group e username, utilizzati per impostare i flag --oidc-group-claim e --oidc-username-claim nell'apiserver. Quando l'apiserver viene presentato con il token, cercherà quel gruppo-- rivendicazione e nome utente-rivendicazione e verificherà che il gruppo o l'utente corrispondente abbia le autorizzazioni corrette.

   Verifica che le rivendicazioni impostate per group e user nella sezione oidc di config.yaml siano presenti in id-token.

3. Controlla i RBAC che sono stati applicati.

   Verifica che ci sia un RBAC con le autorizzazioni corrette per l'utente specificato dalla rivendicazione del nome utente o per uno dei gruppi elencati nella rivendicazione del gruppo del passaggio precedente. Il nome dell'utente o del gruppo nell'RBAC deve avere come prefisso il valore usernameprefix o groupprefix fornito nella sezione oidc di config.yaml.

   Tieni presente che se usernameprefix è stato lasciato vuoto e username è un valore diverso da email, il prefisso sarà per impostazione predefinita issuerurl#. Per disabilitare i prefissi nome utente, usernameprefix deve essere impostato su - .

   Per ulteriori informazioni sui prefissi utente e gruppo, consulta la sezione Completamento delle specifiche oidc.

   Tieni presente che al momento il server API di Kubernetes tratta una barra rovesciata come un carattere di escape. Pertanto, se il nome dell'utente o del gruppo contiene \\, il server API lo leggerà come un singolo \ durante l'analisi di id_token. Di conseguenza, il valore RBAC applicato per l'utente o il gruppo deve contenere una singola barra rovesciata o potresti visualizzare un errore Unauthorized.

   Esempio:

   config.yaml:

   oidc:
       issuerurl:
       …
       username: "unique_name"
       usernameprefix: "-"
       group: "group"
       groupprefix: "oidc:"
       ...
   

   id_token:

   {
     ...
     "email": "[e-mail]",
     "unique_name": "EXAMPLE\\cluster-developer",
     "group": [
       "Domain Users",
       "EXAMPLE\\developers"
   ],
     ...
   }
   

   I seguenti RBAC concederebbero a questo utente le autorizzazioni di amministratore del cluster (nota che la singola barra è nel campo del nome invece che una doppia barra):

   Group RBAC:

   apiVersion:
   kind:
   metadata:
      name: example-binding
   subjects:
   -  kind: Group
      name: "oidc:EXAMPLE\developers"
      apiGroup: rbac.authorization.k8s.io
      roleRef:
        kind: ClusterRole
        name: pod-reader
        apiGroup: rbac.authorization.k8s.io
   

   User RBAC:

   apiVersion:
   kind:
   metadata:
      name: example-binding
   subjects:
   -  kind: User
                  name: "EXAMPLE\cluster-developer"
                  apiGroup: rbac.authorization.k8s.io
              roleRef:
              kind: ClusterRole
                  name: pod-reader
                  apiGroup: rbac.authorization.k8s.io

4. Controlla i log del server API.

   Se il plug-in OIDC configurato nell'apiserver kube non si avvia correttamente, il server API restituirà un errore"Non autorizzato"quando presentato con id-token. Per verificare se si sono verificati problemi con il plug-in OIDC nel server API, esegui:

   kubectl
         --kubeconfig=[admin_cluster_kubeconfig] logs statefulset/kube-apiserver -n
         [user_cluster_name]

Sintomi

Impossibile connettersi al server: ricevi {DISCOVERY_ENDPOINT}: x509: certificato firmato da autorità sconosciuta

Potenziali cause

Il token di aggiornamento in kubeconfig è scaduto.

Risoluzione

Esegui di nuovo il comando login.

Accesso a Google Cloud Console

Di seguito sono riportati errori comuni che potrebbero verificarsi durante l'utilizzo di Google Cloud Console per tentare di accedere:

L'accesso reindirizza alla pagina con "URL non trovato" errore

Sintomi

Google Cloud Console non è in grado di raggiungere il provider di identità on-prem di GKE.

Potenziali cause

Google Cloud Console non è in grado di raggiungere il provider di identità on-prem di GKE.

Risoluzione

Per risolvere il problema, prova i seguenti passaggi:

1. Imposta useHTTPProxy su true

   Se l'IdP non è raggiungibile sulla rete Internet pubblica, dovrai abilitare il proxy HTTP OIDC per l'accesso tramite Google Cloud Console. Nella sezione oidc di config.yaml, il valore usehttpproxy deve essere impostato su true. Se hai già creato un cluster e vuoi attivare il proxy, puoi modificare direttamente il CRD di ClientConfig. Esegui $ kubectl edit clientconfig default -n kube-public e modifica useHTTPProxy in true.

2. useHTTPProxy è già impostato su true

   Se il proxy HTTP è abilitato e ricevi ancora questo errore,potrebbe esserci un problema di avvio del proxy. Per recuperare i log del proxy, esegui $ kubectl logs deployment/clientconfig-operator -n kube-system. Tieni presente che, anche se il tuo IDP ha una CA nota, per poter avviare il proxy http, devi fornire il campo capath nella sezione oidc di config.yaml.

3. Richieste di consenso per l'IdP

   Se il server di autorizzazione richiede il consenso e non hai incluso il parametro aggiuntivo prompt=consent, potresti visualizzare questo errore. Esegui $ kubectl edit clientconfig default -n kube-public e aggiungi prompt=consent a extraparams e riprova ad accedere.

4. I RBAC sono configurati in modo errato

   Se non lo hai già fatto, prova a eseguire l'autenticazione utilizzando il plug-in di autenticazione per Anthos. Se viene visualizzato un errore di autorizzazione durante l'accesso con il plug-in, segui la procedura di risoluzione dei problemi relativa al problema con il plug-in e riprova ad accedere tramite Google Cloud Console.

5. Prova a uscire e riaccedere

   In alcuni casi, se alcune impostazioni vengono modificate sul servizio di archiviazione, potrebbe essere necessario uscire in modo esplicito. Vai alla pagina dei dettagli del cluster, fai clic su Esci e prova ad accedere di nuovo.

Workstation di amministrazione

openssl non può convalidare l'OVA della workstation di amministrazione

Sintomi

L'esecuzione di openssl dgst sul file OVA della workstation di amministrazione non restituisce Verified OK

Potenziali cause

Nel file OVA è presente un problema che impedisce la convalida.

Risoluzione

Prova a scaricare e a eseguire nuovamente il deployment dell'OVA della workstation di amministrazione, come indicato in Scaricare l'OVA della workstation di amministrazione. Se il problema persiste, contatta Google per ricevere assistenza.

Connetti

Impossibile registrare un cluster utente

Se riscontri problemi con la registrazione dei cluster utente, contatta Google per l'assistenza.

Il cluster creato durante la fase alpha è stato annullato

Fai riferimento all'articolo Registrare un cluster utente nella documentazione di Connect.

Puoi anche scegliere di eliminare e ricreare il cluster.

Archiviazione

Il volume non viene collegato

Sintomi

L'output di gkectl diagnose cluster ha il seguente aspetto:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status
1 storage errors

Uno o più pod sono bloccati nello stato ContainerCreating con un avviso simile al seguente:

Events:
  Type     Reason              Age               From                     Message
  ----     ------              ----              ----                     -------
  Warning  FailedAttachVolume  6s (x6 over 31s)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.

Potenziali cause

Se un disco virtuale è collegato alla macchina virtuale sbagliata, potrebbe essere dovuto al problema #32727 in Kubernetes 1.12.

Risoluzione

Se un disco virtuale è collegato alla macchina virtuale sbagliata, potresti dover scollegarlo manualmente:

1. Svuota il nodo. Consulta Svuotamento sicuro di un nodo. Potresti includere i flag --ignore-daemonsets e --delete-local-data nel comando kubectl drain.
2. Spegni la VM.
3. Modifica la configurazione hardware della VM in vCenter per rimuovere il volume.
4. Accendi la VM
5. Contrassegna il nodo come non pianificabile.

Volume perso

Sintomi

L'output di gkectl diagnose cluster ha il seguente aspetto:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found
1 storage errors

Uno o più pod sono bloccati nello stato ContainerCreating con un avviso simile al seguente:

Events:
  Type     Reason              Age                   From                                    Message
  ----     ------              ----                  ----                                    -------
  Warning  FailedAttachVolume  71s (x28 over 42m)    attachdetach-controller                 AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/
  kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found

Potenziali cause

Se vedi un errore "non trovato" relativo al file VMDK, è probabile che il disco virtuale sia stato eliminato definitivamente. Questo può accadere se un operatore elimina manualmente un disco virtuale o la macchina virtuale a cui è collegato. Per evitare questo problema, gestisci le tue macchine virtuali come descritto in Ridimensionamento di un cluster utente e Upgrade dei cluster

Risoluzione

Se un disco virtuale è stato eliminato definitivamente, potrebbe essere necessario eseguire manualmente la pulizia delle risorse Kubernetes correlate:

1. Elimina la PVC che ha fatto riferimento al PV eseguendo kubectl delete pvc [PVC_NAME].
2. Elimina il pod che fa riferimento alla PVC eseguendo kubectl delete pod [POD_NAME].
3. Ripeti il passaggio 2. (Sì, davvero. Consulta il problema con Kubernetes 74374.

Il volume CSI vSphere non si scollega

Sintomi

Se trovi pod bloccati nella fase ContainerCreating con avvisi FailedAttachVolume, ciò potrebbe essere dovuto a uno scollegamento non riuscito su un nodo diverso.

Esegui il comando seguente per trovare gli errori di scollegamento CSI:

kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message

L'output dovrebbe avere l'aspetto seguente:

NAME                                                                   DETACH_ERROR
csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5   rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission
csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d   
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c   
csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8   

Potenziali cause

Il privilegio CNS > Searchable non è stato concesso all'utente vSphere.

Risoluzione

Aggiungi il privilegio CNS > Searchable al tuo account utente vCenter. L'operazione di scollegamento viene tentata di nuovo automaticamente fino al completamento dell'operazione.

Upgrade

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.

Prima di un upgrade del cluster di amministrazione potrebbe essere necessario rinnovare i certificati

Prima di iniziare il processo di upgrade del cluster di amministrazione, devi assicurarti che i certificati del cluster di amministrazione siano attualmente validi e rinnovarli se non lo sono.

Nota: se hai iniziato la procedura di upgrade e hai rilevato un errore con scadenza del certificato, contatta l'Assistenza Google.

Nota: queste indicazioni riguardano esclusivamente il rinnovo dei certificati del cluster di amministrazione.

Procedura di rinnovo dei certificati del cluster di amministrazione

1. Assicurati che OpenSSL sia installato sulla workstation di amministrazione prima di iniziare.

2. Imposta la variabile KUBECONFIG:

   KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
   

   Sostituisci ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG con il percorso assoluto al file kubeconfig del cluster di amministrazione.

3. Recupera l'indirizzo IP e le chiavi SSH per il nodo master dell'amministratore:

   kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \
   -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
   ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key
   
   export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \
   jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
   --selector='node-role.kubernetes.io/master')
   

4. Controlla se i certificati sono scaduti:

   ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
   "sudo kubeadm alpha certs check-expiration"
   

   Se i certificati sono scaduti, devi rinnovarli prima di eseguire l'upgrade del cluster di amministrazione.

5. Esegui il backup dei certificati precedenti:

   Si tratta di un passaggio facoltativo, ma consigliato.

   # ssh into admin master
   ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
   
   # on admin master
   sudo tar -czvf backup.tar.gz /etc/kubernetes
   logout
   
   # on worker node
   sudo scp -i ~/.ssh/admin-cluster.key \
   ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
   

6. Rinnova i certificati con kubeadm:

    # ssh into admin master
    ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
    # on admin master
    sudo kubeadm alpha certs renew all
    

7. Riavvia il nodo master dell'amministratore:

     # on admin master
     cd /etc/kubernetes
     sudo mkdir tempdir
     sudo mv manifests/*.yaml tempdir/
     sleep 5
     echo "remove pods"
     # ensure kubelet detect those change remove those pods
     # wait until the result of this command is empty
     sudo docker ps | grep kube-apiserver
   
     # ensure kubelet start those pods again
     echo "start pods again"
     sudo mv tempdir/*.yaml manifests/
     sleep 30
     # ensure kubelet start those pods again
     # should show some results
     sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd
   
     # clean up
     sudo rm -rf tempdir
   
     logout
    

8. Dato che anche il file kubeconfig del cluster di amministrazione scade, alla scadenza dei certificati di amministratore devi eseguire il backup di questo file prima della scadenza.

   • Esegui il backup del file kubeconfig del cluster di amministrazione:

     ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 
     
     "sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
     vi "${KUBECONFIG}"
     

   • Sostituisci client-certificate-data e client-key-data in kubeconfig con client-certificate-data e client-key-data nel file new_admin.conf che hai creato.

9. Devi convalidare i certificati rinnovati e il certificato di kube-apiserver.

   • Controlla la scadenza dei certificati:

     ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 
     
     "sudo kubeadm alpha certs check-expiration"
     

   • Controlla il certificato di kube-apiserver:

     # Get the IP address of kube-apiserver
     cat $KUBECONFIG | grep server
     # Get the current kube-apiserver certificate
     openssl s_client -showcerts -connect : 
     
     | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  
     
     > current-kube-apiserver.crt
     # check expiration date of this cert
     openssl x509 -in current-kube-apiserver.crt -noout -enddate
     

Ridimensionare i cluster utente

Ridimensionamento di un cluster utente non riuscito

Sintomi

Un'operazione di ridimensionamento su un cluster utente non riesce.

Potenziali cause

Esistono diversi fattori che potrebbero impedire l'esecuzione delle operazioni di ridimensionamento.

Risoluzione

Se il ridimensionamento non va a buon fine, procedi nel seguente modo:

1. Controlla lo stato MachineDeployment del cluster per verificare se sono presenti eventi o messaggi di errore:

   kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]

2. Verifica la presenza di errori sulle macchine appena create:

   kubectl describe machine [MACHINE_NAME]

Errore: "Non è possibile allocare alcun indirizzo".

Sintomi

Dopo il ridimensionamento di 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 continua a non essere registrata nel cluster utente.

Cause possibili

Potrebbe esserci un conflitto di indirizzi IP. L'IP potrebbe essere utilizzato da un'altra macchina o dal bilanciatore del carico.

Risoluzione

Verifica che l'indirizzo IP della macchina interessata non sia in uso. Se esiste un conflitto, devi risolverlo nel tuo ambiente.

vSphere

Debug con govc

In caso di problemi specifici di vSphere, puoi utilizzare govc per la risoluzione dei problemi. Ad esempio, puoi verificare facilmente le autorizzazioni e l'accesso per i tuoi account utente vCenter e raccogliere i log di vSphere.

Modifica del certificato vCenter

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

1. Recupera il nuovo certificato vCenter e salvalo in un file:

   true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

2. Ora, per ogni cluster, elimina il ConfigMap contenente il certificato vSphere e vCenter per ogni cluster e crea un nuovo ConfigMap con il nuovo certificato. Ad esempio:

   kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system

   kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1

   kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -

   kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -

3. Elimina il pod clusterapi-controllers per ogni cluster. Il pod inizia a utilizzare il nuovo certificato. Ad esempio:

   kubectl --kubeconfig kubeconfig -n kube-system get pods

   kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...

Vari

Limite di sessioni del provider Terraform vSphere

GKE On-Prem utilizza il provider vSphere di Terraform per attivare le VM nell'ambiente vSphere. Il limite di sessioni del provider è di 1000 sessioni. L'implementazione attuale non chiude le sessioni attive dopo l'utilizzo. Potresti riscontrare errori 503 se hai troppe sessioni in esecuzione.

Le sessioni vengono chiuse automaticamente dopo 300 secondi.

Sintomi

Se hai troppe sessioni in esecuzione, potresti riscontrare il seguente errore:

Error connecting to CIS REST endpoint: Login failed: body:
  {"type":"com.vmware.vapi.std.errors.service_unavailable","value":
  {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is
  limited to 1000. Existing sessions are 1000.",
  "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}},
  status: 503 Service Unavailable

Potenziali cause

Sono presenti troppe sessioni provider Terraform in esecuzione nel tuo ambiente.

Risoluzione

Attualmente, questa operazione funziona come previsto. Le sessioni vengono chiuse automaticamente dopo 300 secondi. Per ulteriori informazioni, fai riferimento al problema GitHub #618.

Utilizzo di un proxy per Docker: oauth2: cannot fetch token

Sintomi

Quando utilizzi un proxy riscontri il seguente errore:

oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527

Potenziali cause

Potresti avere fornito un proxy HTTPS anziché HTTP.

Risoluzione

Nella configurazione Docker, cambia l'indirizzo proxy in http:// anziché in https://.

Verifica della validità delle licenze

Ricorda di verificare la validità delle tue licenze, soprattutto se utilizzi queste licenze. Se le tue licenze F5, ESXi o vCenter sono scadute, potresti riscontrare errori imprevisti.