Problemi noti di Google Distributed Cloud (solo software) per VMware

Questa pagina elenca tutti i problemi noti di Google Distributed Cloud su VMware. Questa pagina è rivolta agli amministratori IT e agli operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica di base e rispondono agli avvisi e alle pagine quando gli SLO (obiettivi a livello di servizio) non vengono raggiunti o le applicazioni non funzionano. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Se partecipi al programma per sviluppatori Google, salva questa pagina per ricevere notifiche quando viene pubblicata una nota di rilascio relativa a questa pagina. Per approfondire, consulta la sezione Pagine salvate.

Per filtrare i problemi noti in base a una versione o categoria di prodotto, seleziona i filtri che preferisci dai menu a discesa riportati di seguito.

Seleziona la versione di Google Distributed Cloud:

  • 1,31
  • 1,30
  • 1,29
  • 1,28
  • 1,16
  • 1,15
  • 1,14
  • 1,13
  • 1,12

Seleziona la categoria del problema:

  • Configurazione
  • Installazione
  • Upgrade
  • Aggiornamenti
  • Operazione
  • Logging e monitoraggio
  • Networking
  • Sicurezza
  • Archiviazione
  • Sistema operativo
  • VMware
  • Identità
  • Migrazione
  • Altro

In alternativa, cerca il problema:

Categoria Versioni identificate Problema e soluzione alternativa
Upgrade 1,28, 1,29, 1,30

Dopo aver eseguito il comando gkectl repair admin-master, un node del piano di controllo amministrativo potrebbe mostrare una versione precedente a quella prevista.

Questo problema si verifica perché il modello VM di cui è stato eseguito il backup utilizzato per la riparazione del nodo del piano di controllo amministrativo HA non viene aggiornato in vCenter dopo un upgrade, perché il modello VM di cui è stato eseguito il backup non è stato clonato durante la creazione della macchina se il nome della macchina rimane invariato.

Soluzione:

  1. Scopri il nome della macchina che utilizza la versione precedente di Kubernetes: 
        kubectl get machine -o wide --kubeconfig=ADMIN_KUBECONFIG
  2. Rimuovi l'annotazione onprem.cluster.gke.io/prevented-deletion: 
        kubectl edit machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG

    Salva la modifica.

  3. Esegui questo comando per eliminare la macchina: 
        kubectl delete machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG

    Verrà creata una nuova macchina con la versione corretta.
Installazione, upgrade e aggiornamenti 1,31

Nella versione 1.31 di Google Distributed Cloud, potresti ricevere errori quando provi a creare risorse personalizzate, come cluster (di tutti i tipi) e carichi di lavoro. Il problema è causato da una modifica incompatibile introdotta in Kubernetes 1.31 che impedisce al campo caBundle in una definizione di risorsa personalizzata di passare da uno stato valido a uno non valido. Per ulteriori informazioni sulla modifica, consulta il log delle modifiche di Kubernetes 1.31.

Prima di Kubernetes 1.31, il campo caBundle veniva spesso impostato su un valore provvisorio di \n, perché nelle versioni precedenti di Kubernetes il server API non consentiva contenuti del bundle CA vuoti. L'utilizzo di \n è stato una soluzione ragionevole per evitare confusione, in quanto \n in genere aggiorna caBundle in un secondo momento.cert-manager

Se il caBundle è stato sottoposto a patch una volta da uno stato non valido a uno stato valido, non dovrebbero esserci problemi. Tuttavia, se la definizione della risorsa personalizzata viene riconciliata con \n (o un altro valore non valido), potresti riscontrare il seguente errore:

...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block]

Soluzione

Se hai una definizione di risorsa personalizzata in cui caBundle è impostato su un valore non valido, puoi rimuovere completamente il campo caBundle in tutta sicurezza. Il problema dovrebbe risolversi.
Sistema operativo 1,31

Quando esegui l'upgrade a 1.31 di un cluster che utilizza l'immagine del sistema operativo Container-Optimized OS (COS), il comando cloud-init status non va a buon fine anche se cloud-init è terminato senza errori.

Soluzione:

Esegui il seguente comando per controllare lo stato di cloud-init:

    systemctl show -p Result cloud-final.service

Se l'output è simile al seguente, significa che cloud-init è stato completato correttamente:

    Result=success
Upgrade 1,28

Durante l'upgrade di un cluster alla versione 1.28, il comando gkectl prepare non riesce durante l'esecuzione dei controlli preliminari della workstation di amministrazione se la dimensione del disco della workstation di amministrazione è inferiore a 100 GB. In questo caso, il comando mostra un messaggio di errore simile al seguente:

    Workstation Hardware: Workstation hardware requirements are not satisfied

Nella versione 1.28, il prerequisito della dimensione del disco della stazione di lavoro dell'amministratore è stato aumentato da 50 GB a 100 GB.

Soluzione:

  1. Esegui il rollback della workstation di amministrazione.
  2. Aggiorna il file di configurazione della workstation di amministrazione per aumentare le dimensioni del disco ad almeno 100 GB.
  3. Esegui l'upgrade della workstation di amministrazione.
Upgrade 1,30

Il comando gkectl upgrade restituisce un errore errato relativo allo storage class NetApp. Il messaggio di errore è simile al seguente: 

    detected unsupported drivers:
      csi.trident.netapp.io

Soluzione:

Esegui gkectl upgrade con il flag `--skip-pre-upgrade-checks`.
VMware, upgrade 1,16

Durante un upgrade del cluster, gli oggetti macchina potrebbero bloccarsi nella fase "Creazione" e non riuscire a collegarsi agli oggetti nodo a causa di una regola del gruppo anti-affinità (AAG) mancante in vCenter.

Se descrivi gli oggetti macchina problematici, puoi vedere messaggi ricorrenti come "Reconfigure DRS rule task "task-xxxx" complete"

    kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME

Soluzione:

Disattiva l'impostazione del gruppo anti-affinità sia nella configurazione del cluster di amministrazione sia nella configurazione del cluster utente e attiva il comando di aggiornamento forzato per sbloccare l'upgrade del cluster:

    gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
    
    gkectl update cluster --config USER_CLUSTER_CONFIG_FILE --kubeconfig USER_CLUSTER_KUBECONFIG --force
Upgrade 1,16

Durante l'upgrade di un cluster utente da 1.16 a 1.28, viene eseguito il backup del cluster di amministrazione. Il processo di backup del cluster amministrativo mostra il messaggio di errore "etcdctl: command not found". L'upgrade del cluster utente riesce e il cluster di amministrazione rimane in uno stato integro. L'unico problema è che il file dei metadati nel cluster di amministrazione non è sottoposto a backup.

Il problema è dovuto al fatto che il file binario etcdctl è stato aggiunto in 1.28 e non è disponibile sui nodi 1.16.

Il backup del cluster di amministrazione prevede diversi passaggi, tra cui l'acquisizione di un'istantanea di etcd e la scrittura del file dei metadati per il cluster di amministrazione. Il backup di etcd riesce comunque perché etcdctl può essere attivato anche dopo un comando exec nel pod etcd. Tuttavia, la scrittura del file dei metadati non va a buon fine perché si basa ancora sul file binario etcdctl da installare sul nodo. Tuttavia, il backup del file dei metadati non impedisce di eseguire un backup, pertanto il processo di backup e l'upgrade del cluster utente vanno a buon fine.

Soluzione:

Se vuoi eseguire il backup del file dei metadati, segui la procedura Eseguire il backup e il ripristino di un cluster di amministrazione con gkectl per attivare un backup distinto del cluster di amministrazione utilizzando la versione di gkectl corrispondente alla versione del tuo cluster di amministrazione.
Installazione 1,16-1,29

Quando viene creato un cluster di utenti configurato per il bilanciamento del carico manuale, si verifica un errore gkectl check-config che indica che il valore ingressHTTPNodePort deve essere almeno 30000, anche quando l'ingresso in bundle è disattivato.

Questo problema si verifica indipendentemente dal fatto che i campi ingressHTTPNodePort e ingressHTTPSNodePort siano impostati o lasciati vuoti.

Soluzione:

Per risolvere il problema, ignora il risultato restituito da gkectl check-config. Per disattivare il traffico in entrata in bundle, consulta Disattivare il traffico in entrata in bundle.
Logging e monitoraggio 1,14

Prometheus potrebbe segnalare avvisi simili al seguente esempio:

Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.

Per verificare se questo avviso è un falso positivo che può essere ignorato: completa i seguenti passaggi:

  1. Confronta la metrica non elaborata grpc_server_handled_total con il valore grpc_method indicato nel messaggio di avviso. In questo esempio, controlla l'etichetta grpc_code per Watch.

    Puoi controllare questa metrica utilizzando Cloud Monitoring con la seguente query MQL: 
    fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
  2. Un avviso su tutti i codici diversi da OK può essere tranquillamente ignorato se il codice non è uno dei seguenti: 
    Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Soluzione:

Per configurare Prometheus in modo da ignorare questi avvisi di falsi positivi, esamina le seguenti opzioni:

  1. Silenzia l'avviso dall'interfaccia utente di Alert Manager.
  2. Se non puoi disattivare l'avviso, segui i passaggi riportati di seguito per eliminare i falsi positivi:
    1. Riduci l'operatore di monitoraggio a 0 repliche in modo che le modifiche possano essere permanenti.
    2. Modifica il ConfigMap prometheus-config e aggiungi grpc_method!="Watch" alla configurazione dell'avviso etcdHighNumberOfFailedGRPCRequests come mostrato nell'esempio seguente:
      • Originale: 
        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
      • Modificata: 
        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])
         Sostituisci il seguente CLUSTER_NAME con il nome del tuo cluster.
    3. Riavvia lo stato set di Prometheus e Alertmanager per acquisire la nuova configurazione.
  3. Se il codice rientra in uno dei casi problematici, controlla il log etcd e il log kube-apiserver per eseguire ulteriori operazioni di debug.
Upgrade, aggiornamenti 1,16

Per un cluster di amministrazione non ad alta disponibilità e un cluster utente del control plane versione 1, quando esegui l'upgrade o l'aggiornamento del cluster di amministrazione, la ricreazione della macchina principale del cluster di amministrazione potrebbe avvenire contemporaneamente al riavvio della macchina principale del cluster utente, il che può causare una condizione di gara. Di conseguenza, i pod del piano di controllo del cluster utente non riescono a comunicare con il piano di controllo del cluster di amministrazione, causando problemi di attacco dei volumi per kube-etcd e kube-apiserver sul piano di controllo del cluster utente.

Per verificare il problema, esegui i seguenti comandi per il pod interessato:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
 e vedrai eventi come: 
Events:
  Type     Reason       Age                  From               Message
  ----     ------       ----                 ----               -------
  Warning  FailedMount  101s                 kubelet            Unable to attach or mount volumes: unmounted volumes=[kube-audit], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
  Warning  FailedMount  86s (x2 over 3m28s)  kubelet            MountVolume.SetUp failed for volume "pvc-77cd0635-57c2-4392-b191-463a45c503cb" : rpc error: code = FailedPrecondition desc = volume ID: "bd313c62-d29b-4ecd-aeda-216648b0f7dc" does not appear staged to "/var/lib/kubelet/plugins/kubernetes.io/csi/csi.vsphere.vmware.com/92435c96eca83817e70ceb8ab994707257059734826fedf0c0228db6a1929024/globalmount"

Soluzione:

  1. Esegui SSH sul nodo del control plane utente, poiché si tratta di un cluster utente del control plane v1, il nodo del control plane utente si trova nel cluster di amministrazione.
  2. Riavvia kubelet utilizzando il seguente comando: 
        sudo systemctl restart kubelet
    Dopo il riavvio, kubelet può ricostruire correttamente il montaggio globale della fase.
Operazione 1,16

L'upgrade di un cluster 1.15 o la creazione di un cluster 1.16 con IP statici non riesce se esistono nomi host duplicati nello stesso data center. Questo errore si verifica perché il gestore del controller cloud vSphere non riesce ad aggiungere un ID provider e un indirizzo IP esterno nell'oggetto del nodo. Di conseguenza, l'upgrade/la creazione del cluster scade.

Per identificare il problema, recupera i log del pod del gestore del controller cloud vSphere per il cluster. Il comando utilizzato dipende dal tipo di cluster, come segue:

  • Cluster di amministrazione: 
          kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
  • Cluster di utenti (kubeception): 
          kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
  • Cluster utente: (Control plane V2): 
          kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system

Ecco un esempio di messaggio di errore:

    I1003 17:17:46.769676       1 search.go:152] Finding node admin-vm-2 in vc=vcsa-53598.e5c235a1.asia-northeast1.gve.goog and datacenter=Datacenter
    E1003 17:17:46.771717       1 datacenter.go:111] Multiple vms found VM by DNS Name. DNS Name: admin-vm-2

Controlla se il nome host è duplicato nel data center:

Puoi utilizzare il seguente approccio per verificare se il nome host è duplicato e, se necessario, applicare una soluzione alternativa. 
          export GOVC_DATACENTER=GOVC_DATACENTER
          export GOVC_URL=GOVC_URL
          export GOVC_USERNAME=GOVC_USERNAME
          export GOVC_PASSWORD=GOVC_PASSWORD
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName HOSTNAME
Comandi e output di esempio: 
          export GOVC_DATACENTER=mtv-lifecycle-vc01
          export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
          export GOVC_USERNAME=xxx
          export GOVC_PASSWORD=yyy
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
          ./vm/gke-admin-node-6b7788cd76-wkt8g
          ./vm/gke-admin-node-6b7788cd76-99sg2
          ./vm/gke-admin-master-5m2jb

La soluzione alternativa che esegui dipende dall'operazione non riuscita.

Soluzione alternativa per gli upgrade:

Applica la soluzione alternativa per il tipo di cluster applicabile.

  • Cluster di utenti:
    1. Aggiorna il nome host della macchina interessata in user-ip-block.yaml con un nome univoco e attiva un aggiornamento forzato:
                gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
    2. Esegui di nuovo gkectl upgrade cluster
  • Cluster di amministrazione:
    1. Aggiorna il nome host della macchina interessata in admin-ip-block.yaml con un nome univoco e attiva un aggiornamento forzato:
                gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
    2. Se si tratta di un cluster amministrativo non HA e scopri che la VM principale amministrativa utilizza un nome host duplicato, devi anche:
      Ottenere il nome della macchina principale amministrativa 
                kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
      Aggiorna l'oggetto della macchina principale dell'amministratore
      Nota: NEW_ADMIN_MASTER_HOSTNAME deve essere uguale a quello impostato in admin-ip-block.yaml nel passaggio 1.
                kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
      Verifica che il nome host sia aggiornato nell'oggetto della macchina principale dell'amministratore:
                kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
    3. Esegui di nuovo l'upgrade del cluster di amministrazione con il checkpoint disattivato:
                gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

Soluzione alternativa per le installazioni:

Applica la soluzione alternativa per il tipo di cluster applicabile.
Operazione 1.13.1 e versioni successive, 1.14, 1., 1,16

Quando utilizzi Terraform per eliminare un cluster di utenti con un bilanciatore del carico F5 BIG-IP, i server virtuali F5 BIG-IP non vengono rimossi dopo l'eliminazione del cluster.


Soluzione:

Per rimuovere le risorse F5, segui i passaggi per ripulire una partizione F5 di un cluster utente

Networking 1,14

La versione 1.14 di Google Distributed Cloud è soggetta a errori di inserimento della tabella di monitoraggio delle connessioni (conntrack) di netfilter quando si utilizzano immagini del sistema operativo Ubuntu o COS. I fallimenti di inserimento comportano timeout dell'applicazione casuali e possono verificarsi anche quando la tabella conntrack ha spazio per nuove voci. Gli errori sono causati da modifiche nel kernel 5.15 e versioni successive che limitano le inserzioni di tabelle in base alla lunghezza della catena.

Per verificare se il problema riguarda il tuo sistema, puoi controllare le statistiche del sistema di monitoraggio delle connessioni in-kernel su ogni nodo con il seguente comando:

sudo conntrack -S

La risposta è simile alla seguente:

cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

Se un valore chaintoolong nella risposta è un numero diverso da zero, il problema ti riguarda.

Soluzione

La mitigazione a breve termine consiste nell'aumentare le dimensioni sia della tabella hash di netfilter (nf_conntrack_buckets) sia della tabella di monitoraggio delle connessioni di netfilter (nf_conntrack_max). Utilizza i seguenti comandi su ogni nodo del cluster per aumentare le dimensioni delle tabelle:

sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

Sostituisci TABLE_SIZE con le nuove dimensioni in byte. Il valore predefinito della dimensione della tabella è 262144. Ti consigliamo di impostare un valore uguale a 65.536 volte il numero di core del nodo. Ad esempio, se il tuo nodo ha otto core, imposta la dimensione della tabella su 524288.
Installazione 1,12

Potresti notare un errore di installazione a causa di cert-manager-cainjector in crashloop, quando apiserver/etcd è lento:

# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
  cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition

E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
  Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded

I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition

E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

Soluzione:

Esegui i seguenti comandi per attenuare il problema.

Per prima cosa, esegui lo scale down di monitoring-operator in modo che non ripristini le modifiche al deployment di cert-manager:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=0

Modifica il deployment cert-manager-cainjector per disattivare l'elezione del leader, perché abbiamo una sola replica in esecuzione. Non è obbligatoria per una singola replica:

# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
    -n kube-system deployment cert-manager-cainjector

Lo snippet YAML pertinente per il deployment di cert-manager-cainjector dovrebbe avere il seguente aspetto:

...
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cert-manager-cainjector
  namespace: kube-system
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
      - name: cert-manager
        image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
        args:
        ...
        - --leader-elect=false
...

Mantieni le repliche monitoring-operator a 0 come misura di mitigazione fino al termine dell'installazione. In caso contrario, la modifica verrà annullata.

Al termine dell'installazione e quando il cluster è attivo e funzionante, attiva monitoring-operator per le operazioni del secondo giorno:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=1

Dopo ogni upgrade, le modifiche vengono annullate. Ripeti gli stessi passaggi per attenuare il problema fino a quando non verrà risolto in una release futura.
Sicurezza 1,13

esiste un breve periodo in cui il nodo è pronto, ma il certificato del server kubelet non è pronto. kubectl exec e kubectl logs non sono disponibili per alcune decine di secondi. Questo perché è necessario del tempo per consentire all'approvatore del nuovo certificato del server di vedere gli IP validi aggiornati del nodo.

Questo problema riguarda solo il certificato del server kubelet e non influisce sulla programmazione dei pod.
Upgrade, aggiornamenti 1,12

L'upgrade del cluster utente non è riuscito con:

.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

L'upgrade del cluster di amministrazione non è stato completato e la versione dello stato è ancora 1.10. L'upgrade del cluster utente alla versione 1.12 non verrà bloccato da alcun controllo preflight e non andrà a buon fine a causa di un problema di sfasamento della versione.


Soluzione:

Esegui l'upgrade del cluster di amministrazione alla versione 1.11 e poi del cluster utente alla versione 1.12.
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.