Problemi noti di GKE su VMware

Questa pagina elenca tutti i problemi noti di GKE su VMware. Per filtrare i problemi noti per una versione o una categoria di prodotto, seleziona i filtri desiderati dai seguenti menu a discesa.

Seleziona la versione di GKE su VMware:

Seleziona la categoria del problema:

In alternativa, cerca il tuo problema:

Categoria Versioni identificate Problema e soluzione alternativa
Installazione, sistema operativo 1.28.0-1.28.500, 1.29.0

L'IP del bridge Docker utilizza 172.17.0.1/16 per i nodi del piano di controllo del cluster COS

GKE su VMware specifica una subnet dedicata, --bip=169.254.123.1/24, per l'IP del bridge Docker nella configurazione Docker in modo da impedire la prenotazione della subnet 172.17.0.1/16 predefinita. Tuttavia, nelle versioni 1.28.0-1.28.500 e 1.29.0, il servizio Docker non è stato riavviato dopo che GKE su VMware ha personalizzato la configurazione Docker a causa di una regressione nell'immagine del sistema operativo COS. Di conseguenza, Docker sceglie 172.17.0.1/16 predefinito come subnet di indirizzo IP bridge. Questo potrebbe causare un conflitto di indirizzi IP se hai già un carico di lavoro in esecuzione all'interno di quell'intervallo di indirizzi IP.

Soluzione alternativa:

Per risolvere questo problema, devi riavviare il servizio Docker:

sudo systemctl restart docker

Verifica che Docker scelga l'indirizzo IP del bridge corretto:

ip a | grep docker0

Questa soluzione non viene mantenuta durante le ricreazioni di VM. Devi applicare nuovamente questa soluzione alternativa ogni volta che vengono ricreate le VM.
update 1.28.0-1.28.400, 1.29.0

L'utilizzo di più interfacce di rete con CNI standard non funziona

I programmi binari CNI standard bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap non sono inclusi nelle immagini del sistema operativo delle versioni interessate. Questi programmi binari CNI non vengono utilizzati dal piano dati v2, ma possono essere utilizzati per interfacce di rete aggiuntive nella funzionalità con più interfacce di rete.

Non è possibile usare più interfacce di rete con questi plug-in CNI.

Soluzione alternativa:

Se utilizzi questa funzionalità, esegui l'upgrade alla versione con la correzione.
update 1,15; 1,16; 1,28

Le dipendenze trident Netapp interferiscono con il driver CSI vSphere

L'installazione di multipathd sui nodi cluster interferisce con il driver CSI vSphere e impedisce l'avvio dei carichi di lavoro degli utenti.

Soluzione alternativa:

  • Disabilita multipathd
Aggiornamenti 1,15, 1,16

Il webhook del cluster di amministrazione potrebbe bloccare gli aggiornamenti quando aggiungi le configurazioni richieste

Se alcune configurazioni obbligatorie sono vuote nel cluster di amministrazione perché le convalide sono state ignorate, la loro aggiunta potrebbe essere bloccata dal webhook del cluster di amministrazione. Ad esempio, se il campo gkeConnect non è stato impostato in un cluster di amministrazione esistente, aggiungendolo con il comando gkectl update admin potrebbe essere visualizzato il seguente messaggio di errore:

admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters

Soluzione alternativa:

  • Per cluster di amministrazione 1.15, esegui il comando gkectl update admin con il flag --disable-admin-cluster-webhook. Ad esempio: 
            gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
  • Per cluster di amministrazione 1.16, esegui i comandi gkectl update admin con il flag --force. Ad esempio: 
            gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
Configurazione 1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200

Il valore predefinito del campo controlPlaneNodePort è 30968 quando la specifica manualLB è vuota

Se utilizzi un bilanciatore del carico manuale (loadBalancer.kind è impostato su "ManualLB"), non devi configurare la sezione loadBalancer.manualLB nel file di configurazione per un cluster di amministrazione ad alta disponibilità nelle versioni 1.16 e successive. Tuttavia, quando questa sezione è vuota, GKE su VMware assegna valori predefiniti a tutte le NodePort, tra cui manualLB.controlPlaneNodePort, causando un errore di creazione del cluster e il seguente messaggio di errore:

- Validation Category: Manual LB
  - [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must
   not be set when using HA admin cluster, got: 30968

Soluzione alternativa:

Specifica manualLB.controlPlaneNodePort: 0 nella configurazione del cluster di amministrazione per il cluster di amministrazione ad alta disponibilità:

loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...
Storage 1.28.0-1.28.100

nfs-common non è presente nell'immagine del sistema operativo Ubuntu

nfs-common non è presente nell'immagine del sistema operativo Ubuntu, il che potrebbe causare problemi ai clienti che utilizzano driver dipendenti NFS come NetApp.

Se il log contiene una voce simile alla seguente dopo l'upgrade alla versione 1.28, questo problema ti riguarda: 
Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32".

Soluzione alternativa:

Assicurati che i nodi possano scaricare pacchetti da Canonical.

Successivamente, applica il seguente DaemonSet al tuo cluster per installare nfs-common:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: install-nfs-common
  labels:
    name: install-nfs-common
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: install-nfs-common
  minReadySeconds: 0
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        name: install-nfs-common
    spec:
      hostPID: true
      hostIPC: true
      hostNetwork: true
      initContainers:
      - name: install-nfs-common
        image: ubuntu
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
        command:
        - chroot
        - /host
        - bash
        - -c
        args:
        - |
          apt install -y nfs-common
        volumeMounts:
        - name: host
          mountPath: /host
      containers:
      - name: pause
        image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5
        imagePullPolicy: IfNotPresent
      volumes:
      - name: host
        hostPath:
          path: /
Storage 1.28.0-1.28.100

Campo dei criteri di archiviazione mancante nel modello di configurazione del cluster di amministrazione

SPBM nei cluster di amministrazione è supportato nella versione 1.28.0 e successive. Tuttavia, il campo vCenter.storagePolicyName non è presente nel modello di file di configurazione.

Soluzione alternativa:

Aggiungi il campo "vCenter.storagePolicyName" nel file di configurazione del cluster di amministrazione se vuoi configurare il criterio di archiviazione per il cluster di amministrazione. Consulta le instructions.
Logging e monitoraggio 1.28.0-1.28.100

L'API Kubernetes Metadata non supporta VPC-SC

L'API kubernetesmetadata.googleapis.com aggiunta di recente non supporta VPC-SC. Questo impedirà all'agente di raccolta dei metadati di raggiungere questa API in VPC-SC. In seguito, mancheranno le etichette dei metadati delle metriche.

Soluzione alternativa:

Imposta nello spazio dei nomi "kube-system" la CR "stackdriver" imposta il campo "featureGates.disableSperimentaMetadataAgent" su "true" eseguendo il comando

`kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`

quindi esegui

`kubectl -n kube-system patch deployment stackdriver-operator -p '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","env":[{"name":"ENABLE_LEGACY_METADATA_AGENT","value":"true"}]}]}}}}'`

Upgrade e aggiornamenti 1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

Il clusterapi-controller potrebbe arrestarsi in modo anomalo quando il cluster di amministrazione e qualsiasi cluster utente con ControlPlane V2 abilitato utilizzano credenziali vSphere diverse

Quando un cluster di amministrazione e qualsiasi cluster utente con ControlPlane V2 abilitato utilizzano credenziali vSphere diverse. Ad esempio, dopo l'aggiornamento delle credenziali di vSphere per il cluster di amministrazione, clusterapi-controller potrebbe non riuscire a connettersi a vCenter dopo il riavvio. Visualizza il log del clusterapi-controller in esecuzione nello spazio dei nomi "kube-system" del cluster di amministrazione,

kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
    -n kube-system --kubeconfig KUBECONFIG
Se il log contiene una voce come la seguente, significa che il problema che hai riscontrato è: 
E1214 00:02:54.095668       1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found

Soluzione alternativa:

Aggiorna le credenziali vSphere in modo che il cluster di amministrazione e tutti i cluster utente con Controlplane V2 abilitato utilizzino le stesse credenziali di vSphere.

Logging e monitoraggio 1,14

numero elevato di richieste GRPC non riuscite in Prometheus Alert Manager

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 passaggi seguenti:

  1. Controlla la metrica grpc_server_handled_total non elaborata rispetto al valore grpc_method specificato 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 ignorato in modo sicuro se il codice non è uno dei seguenti: 
    Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Soluzione alternativa:

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

  1. Silenzia l'avviso dall'interfaccia utente di Gestione avvisi.
  2. Se non è possibile silenziare l'avviso, consulta i seguenti passaggi per eliminare i falsi positivi:
    1. Fai lo scale down dell'operatore di monitoraggio a 0 di repliche in modo che le modifiche possano persistere.
    2. Modifica la configurazione degli avvisi prometheus-config e aggiungi grpc_method!="Watch" alla configurazione degli avvisi etcdHighNumberOfFailedGRPCRequests come mostrato nell'esempio seguente:
      • Originale: 
        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
      • Modificato: 
        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])
        Sostituisci CLUSTER_NAME con il nome del cluster.
    3. Riavvia Prometheus e Alertmanager Statefulset per recuperare 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.
Networking 1.16.0-1.16.2, 1.28.0

Le connessioni NAT di lunga durata in uscita vengono interrotte

Le connessioni NAT in uscita potrebbero interrompersi dopo 5-10 minuti dallo stabilire una connessione in assenza di traffico.

Poiché la connessione è importante solo nella direzione in entrata (connessioni esterne al cluster), questo problema si verifica solo se la connessione non trasmette alcuna informazione per un po' di tempo, dopodiché il lato di destinazione trasmette qualcosa. Se il pod NAT in uscita crea sempre un'istanza dei messaggi, questo problema non sarà rilevato.

Questo problema si verifica perché la garbage collection anetd rimuove inavvertitamente le voci conntrack che il daemon ritiene inutilizzate. Una correzione upstream è stata recentemente integrata in anetd per correggere il comportamento.


Soluzione alternativa:

Non esistono soluzioni alternative semplici e nella versione 1.16 non abbiamo riscontrato problemi con questo comportamento. Se noti che le connessioni di lunga durata sono interrotte a causa di questo problema, le soluzioni alternative potrebbero essere utilizzare un carico di lavoro sullo stesso nodo dell'indirizzo IP in uscita o inviare messaggi in modo coerente sulla connessione TCP.
Operazione 1,14; 1,15; 1,16

Il firmatario CSR ignora spec.expirationSeconds durante la firma dei certificati

Se crei una richiesta CertificateSigningRequest (CSR) con expirationSeconds impostato, expirationSeconds viene ignorato.

Soluzione alternativa:

Se questo problema ti riguarda, puoi aggiornare il cluster utente aggiungendo disableNodeIDVerificationCSRSigning: true nel file di configurazione del cluster utente ed eseguire il comando gkectl update cluster per aggiornare il cluster con questa configurazione.
Networking, upgrade e aggiornamenti 1.16.0-1.16.3

La convalida del bilanciatore del carico del cluster utente non è riuscita per disable_bundled_ingress

Se provi a disabilitare il traffico in entrata in bundle per un cluster esistente, il comando gkectl update cluster non riesce e restituisce un errore simile al seguente esempio:

[FAILURE] Config: ingress IP is required in user cluster spec

Questo errore si verifica perché gkectl verifica la presenza di un indirizzo IP in entrata del bilanciatore del carico durante i controlli preflight. Sebbene questo controllo non sia richiesto quando disabiliti il traffico in entrata in bundle, il controllo preflight gkectl non va a buon fine quando disableBundledIngress è impostato su true.


Soluzione alternativa:

Utilizza il parametro --skip-validation-load-balancer quando aggiorni il cluster, come mostrato nell'esempio seguente:

gkectl update cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG  \
  --skip-validation-load-balancer

Per maggiori informazioni, scopri come disabilitare il traffico in entrata in bundle per un cluster esistente.
Upgrade e aggiornamenti 1,13, 1,14, 1,15,0-1,15,6

Gli aggiornamenti del cluster di amministrazione non riescono dopo la rotazione della CA

Se ruoti i certificati dell'autorità di certificazione (CA) del cluster di amministrazione, i tentativi successivi di eseguire il comando gkectl update admin non andranno a buon fine. L'errore restituito è simile al seguente:

failed to get last CARotationStage: configmaps "ca-rotation-stage" not found

Soluzione alternativa:

Se questo problema ti riguarda, puoi aggiornare il cluster di amministrazione utilizzando il flag --disable-update-from-checkpoint con il comando gkectl update admin:

gkectl update admin --config ADMIN_CONFIG_file \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-update-from-checkpoint

Quando utilizzi il flag --disable-update-from-checkpoint, il comando di aggiornamento non utilizza il file del checkpoint come fonte attendibile durante l'aggiornamento del cluster. Il file del checkpoint è ancora aggiornato per uso futuro.
Storage 1.15.0-1.15.6, 1.16.0-1.16.2

Il controllo preflight del carico di lavoro CSI non riesce a causa di un errore di avvio del pod

Durante i controlli preflight, il controllo di convalida del carico di lavoro CSI installa un pod nello spazio dei nomi default. Il pod di carico di lavoro CSI verifica che il driver CSI vSphere sia installato e può eseguire il provisioning dinamico del volume. Se questo pod non si avvia, il controllo di convalida del carico di lavoro CSI non va a buon fine.

Esistono alcuni problemi noti che possono impedire l'avvio di questo pod:

  • Se per il pod non sono specificati limiti per le risorse, come nel caso di alcuni cluster con webhook di ammissione installati, il pod non viene avviato.
  • Se Anthos Service Mesh è installato nel cluster con l'inserimento automatico del sidecar Istio abilitato nello spazio dei nomi default, il pod di carico di lavoro CSI non si avvia.

Se il pod di carico di lavoro CSI non si avvia, viene visualizzato un errore di timeout come il seguente durante le convalide preflight:

- [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition

Per verificare se l'errore è causato dalla mancanza di risorse pod impostate, esegui il comando seguente per controllare lo stato del job anthos-csi-workload-writer-<run-id>:

kubectl describe job anthos-csi-workload-writer-<run-id>

Se i limiti delle risorse non sono impostati correttamente per il pod di carico di lavoro CSI, lo stato del job contiene un messaggio di errore simile al seguente:

CPU and memory resource limits is invalid, as it are not defined for container: volume-tester

Se il pod di carico di lavoro CSI non si avvia a causa dell'inserimento di file collaterali Istio, puoi disabilitare temporaneamente l'inserimento automatico del sidecar Istio nello spazio dei nomi default. Controlla le etichette dello spazio dei nomi e usa il comando seguente per eliminare l'etichetta che inizia con istio.io/rev:

kubectl label namespace default istio.io/rev-

Se il pod non è configurato correttamente, verifica manualmente che il provisioning del volume dinamico con il driver CSI vSphere funzioni:

  1. Crea un PVC che utilizzi l'oggetto StorageClass standard-rwo.
  2. Creare un pod che utilizza la PVC.
  3. Verifica che il pod possa leggere/scrivere dati nel volume.
  4. Rimuovi il pod e la PVC dopo aver verificato il corretto funzionamento.

Se il provisioning dinamico del volume con il driver CSI vSphere funziona, esegui gkectl diagnose o gkectl upgrade con il flag --skip-validation-csi-workload per saltare il controllo del carico di lavoro CSI.

Operazione 1.16.0-1.16.2

Timeout dell'aggiornamento del cluster utente quando la versione del cluster di amministrazione è 1.15

Se hai eseguito l'accesso a una workstation di amministrazione gestita dall'utente, il comando gkectl update cluster potrebbe scadere e non aggiornare il cluster utente. Questo accade se la versione del cluster di amministrazione è 1.15 e esegui gkectl update admin prima di eseguire gkectl update cluster. In questo caso, quando provi ad aggiornare il cluster viene visualizzato il seguente errore: 

      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition

Durante l'aggiornamento di un cluster di amministrazione 1.15, l'elemento validation-controller che attiva i controlli preflight viene rimosso dal cluster. Se poi provi ad aggiornare il cluster utente, il controllo preflight si blocca fino al raggiungimento del timeout.

Soluzione alternativa:

  1. Esegui questo comando per eseguire nuovamente il deployment di validation-controller: 
          gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. Al termine della preparazione, esegui di nuovo gkectl update cluster per aggiornare il cluster utente
Operazione 1.16.0-1.16.2

Timeout della creazione del cluster utente quando la versione del cluster di amministrazione è 1.15

Se hai eseguito l'accesso a una workstation di amministrazione gestita dall'utente, il comando gkectl create cluster potrebbe scadere e non creare il cluster utente. Questo accade se la versione del cluster di amministrazione è 1.15. In questo caso, quando provi a creare il cluster viene visualizzato il seguente errore: 

      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition

Poiché validation-controller è stato aggiunto nella versione 1.16, quando utilizzi il cluster di amministrazione 1.15 manca il validation-controller responsabile di attivare i controlli preflight. Di conseguenza, quando si cerca di creare un cluster utente, i controlli preflight si bloccano fino al raggiungimento del timeout.

Soluzione alternativa:

  1. Esegui questo comando per eseguire il deployment di validation-controller: 
          gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. Al termine della preparazione, esegui di nuovo gkectl create cluster per creare il cluster utente
Upgrade e aggiornamenti 1.16.0-1.16.2

L'aggiornamento o l'upgrade del cluster di amministrazione non va a buon fine se i progetti o le località dei servizi dei componenti aggiuntivi non corrispondono

Quando esegui l'upgrade di un cluster di amministrazione dalla versione 1.15.x alla versione 1.16.x o aggiungi una configurazione connect, stackdriver, cloudAuditLogging o gkeOnPremAPI quando aggiorni un cluster di amministrazione, l'operazione potrebbe essere rifiutata dal webhook del cluster di amministrazione. Potrebbe essere visualizzato uno dei seguenti messaggi di errore:

  • "projects for connect, stackdriver and cloudAuditLogging must be the same when specified during cluster creation."
  • "locations for connect, gkeOnPremAPI, stackdriver and cloudAuditLogging must be in the same region when specified during cluster creation."
  • "locations for stackdriver and cloudAuditLogging must be the same when specified during cluster creation."

Un aggiornamento o un upgrade del cluster di amministrazione richiede che onprem-admin-cluster-controller riconcilia il cluster di amministrazione in un cluster di tipo. Quando lo stato del cluster di amministrazione viene ripristinato nel cluster di tipo, il webhook del cluster di amministrazione non è in grado di capire se l'oggetto OnPremAdminCluster è destinato alla creazione di un cluster di amministrazione o di riprendere le operazioni per un aggiornamento o un upgrade. Alcune convalide solo per la creazione vengono richiamate in caso di aggiornamento e upgrade inaspettati.


Soluzione alternativa:

Aggiungi l'annotazione onprem.cluster.gke.io/skip-project-location-sameness-validation: true all'oggetto OnPremAdminCluster:

  1. Modifica la risorsa cluster onpremadminclusters: 
    kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Sostituisci quanto segue:
    • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione.
    • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
  2. Aggiungi l'annotazione onprem.cluster.gke.io/skip-project-location-sameness-validation: true e salva la risorsa personalizzata.
  3. A seconda del tipo di cluster di amministrazione, completa uno dei seguenti passaggi:
    • Per i cluster di amministrazione non ad alta disponibilità con un file di checkpoint: aggiungi il parametro disable-update-from-checkpoint nel comando di aggiornamento oppure aggiungi il parametro "disable-upgrade-from-checkpoint" nel comando di upgrade. Questi parametri sono necessari solo per la prossima volta che esegui il comando update o upgrade: 
      • gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-update-from-checkpoint

      • gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-upgrade-from-checkpoint
    • Per i cluster di amministrazione ad alta disponibilità o il file dei checkpoint è disabilitato: aggiorna o esegui l'upgrade del cluster di amministrazione come di consueto. Non sono necessari parametri aggiuntivi nei comandi update o upgrade.
Operazione 1.16.0-1.16.2

L'eliminazione del cluster utente non riesce quando viene utilizzata una workstation di amministrazione gestita dall'utente

Quando hai eseguito l'accesso a una workstation di amministrazione gestita dall'utente, il comando gkectl delete cluster potrebbe scadere e non eliminare il cluster utente. Questo accade se esegui per la prima volta gkectl sulla workstation gestita dall'utente per creare, aggiornare o eseguire l'upgrade del cluster utente. In questo caso, viene visualizzato il seguente errore quando cerchi di eliminare il cluster: 

      failed to wait for user cluster management namespace "USER_CLUSTER_NAME-gke-onprem-mgmt"
      to be deleted: timed out waiting for the condition

Durante l'eliminazione, un cluster elimina prima tutti i propri oggetti. L'eliminazione degli oggetti di convalida (creati durante la creazione, l'aggiornamento o l'upgrade) è bloccata nella fase di eliminazione. Questo accade perché un finalizzatore blocca l'eliminazione dell'oggetto, causando un errore di eliminazione del cluster.

Soluzione alternativa:

  1. Recupera i nomi di tutti gli oggetti Convalida: 
             kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
  2. Per ogni oggetto Validation, esegui questo comando per rimuovere il finalizzatore dall'oggetto Validation: 
          kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
        -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge

    Dopo la rimozione del finaler da tutti gli oggetti Validation, gli oggetti vengono rimossi e l'operazione di eliminazione del cluster utente viene completata automaticamente. Non è richiesta alcuna azione da parte tua.

Networking 1,15, 1,16

Il traffico del gateway NAT in uscita verso il server esterno non va a buon fine

Se il pod di origine e il pod del gateway NAT in uscita si trovano su due nodi worker diversi, il traffico proveniente dal pod di origine non può raggiungere alcun servizio esterno. Se i pod si trovano sullo stesso host, la connessione al servizio o all'applicazione esterni ha esito positivo.

Questo problema è causato dal fatto che vSphere ha eliminato dei pacchetti VXLAN quando è abilitata l'aggregazione del tunnel. Con NSX e VMware, si è verificato un problema noto che invia traffico aggregato solo sulle porte VXLAN note (4789).


Soluzione alternativa:

Cambia la porta VXLAN utilizzata da Cilium in 4789:

  1. Modifica il ConfigMap cilium-config: 
    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
  2. Aggiungi quanto segue a cilium-config ConfigMap: 
    tunnel-port: 4789
  3. Riavvia il DaemonSet anetd: 
    kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

Questa soluzione alternativa viene ripristinata ogni volta che viene eseguito l'upgrade del cluster. Devi riconfigurare dopo ogni upgrade. VMware deve risolvere il problema in vSphere per una correzione permanente.
Upgrade 1.15.0-1.15.4

L'upgrade di un cluster di amministrazione con la crittografia dei secret sempre attivi abilitata non riesce

L'upgrade del cluster di amministrazione da 1.14.x a 1.15.x con la crittografia dei secret sempre attivi abilitata non va a buon fine a causa di una mancata corrispondenza tra la chiave di crittografia generata dal controller e quella che persiste sul disco dati master dell'amministratore. L'output di gkectl upgrade admin contiene il seguente messaggio di errore: 

      E0926 14:42:21.796444   40110 console.go:93] Exit with error:
      E0926 14:42:21.796491   40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane

L'esecuzione di kubectl get secrets -A --kubeconfig KUBECONFIG` non riesce a causa del seguente errore: 

      Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk

Soluzione alternativa

Se hai un backup del cluster di amministrazione, segui questi passaggi per aggirare l'errore di upgrade:

  1. Disabilita secretsEncryption nel file di configurazione del cluster di amministrazione e aggiorna il cluster utilizzando questo comando: 
    gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
  2. Quando viene creata la nuova VM master dell'amministratore, accedi tramite SSH alla VM master dell'amministratore e sostituisci la nuova chiave sul disco dati con quella precedente del backup. La chiave si trova in /opt/data/gke-k8s-kms-plugin/generatedkeys sul master di amministrazione.
  3. Aggiorna il manifest statico del pod kms-plugin.yaml in /etc/kubernetes/manifests per aggiornare --kek-id in modo che corrisponda al campo kid nella chiave di crittografia originale.
  4. Riavvia il pod statico kms-plugin spostando /etc/kubernetes/manifests/kms-plugin.yaml in un'altra directory, quindi spostalo nuovamente.
  5. Riprendi l'upgrade dell'amministratore eseguendo di nuovo gkectl upgrade admin.

Come evitare l'errore dell'upgrade

Se non hai ancora eseguito l'upgrade, ti consigliamo di non eseguire l'upgrade alla versione 1.15.0-1.15.4. Se devi eseguire l'upgrade a una versione interessata, segui questi passaggi prima di eseguire l'upgrade del cluster di amministrazione:

  1. Esegui il backup del cluster di amministrazione.
  2. Disabilita secretsEncryption nel file di configurazione del cluster di amministrazione e aggiorna il cluster utilizzando questo comando: 
    gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
  3. Esegui l'upgrade del cluster di amministrazione.
  4. Riattiva la crittografia dei secret sempre attivi.
Storage 1,11-1,16

Errori del disco e errori di collegamento quando si utilizza il monitoraggio a blocchi modificati (CBT)

GKE su VMware non supporta il monitoraggio a blocchi modificati (CBT) sui dischi. Alcuni software di backup utilizzano la funzionalità CBT per monitorare lo stato del disco ed eseguire backup, il che impedisce al disco di connettersi a una VM che esegue GKE su VMware. Per maggiori informazioni, consulta l'articolo della knowledge base di VMware.


Soluzione alternativa:

Non eseguire il backup delle VM di GKE su VMware, poiché il software di backup di terze parti potrebbe causare l'abilitazione di CBT sui relativi dischi. Non è necessario eseguire il backup di queste VM.

Non abilitare la funzionalità CBT sul nodo, poiché questa modifica non verrà applicata a tutti gli aggiornamenti o gli upgrade.

Se hai già dei dischi con CBT abilitati, segui i passaggi per la risoluzione riportati nell'articolo della knowledge base di VMware per disabilitare la funzionalità CBT sul disco di prima classe.
Storage 1,14; 1,15; 1,16

Danneggiamento dei dati su NFSv3 quando le aggiunte parallele a un file condiviso vengono eseguite da più host

Se utilizzi gli array di archiviazione Nutanix per fornire condivisioni NFSv3 ai tuoi host, i dati potrebbero essere danneggiati o i pod potrebbero non essere eseguiti correttamente. Questo problema è causato da un problema di compatibilità noto tra alcune versioni di VMware e Nutanix. Per ulteriori informazioni, consulta l'articolo della knowledge base di VMware associato.


Soluzione alternativa:

L'articolo della knowledge base di VMware non è aggiornato poiché non esiste una risoluzione attuale. Per risolvere il problema, esegui l'aggiornamento all'ultima versione di ESXi sui tuoi host e all'ultima versione di Nutanix sugli array di archiviazione.
Sistema operativo 1.13.10, 1.14.6, 1.15.3

Mancata corrispondenza della versione tra kubelet e il piano di controllo Kubernetes

Per alcune release di GKE su VMware, il kubelet in esecuzione sui nodi utilizza una versione diversa rispetto al piano di controllo Kubernetes. Si è verificata una mancata corrispondenza perché il programma binario kubelet precaricato nell'immagine del sistema operativo utilizza una versione diversa.

Nella tabella seguente sono elencate le versioni non corrispondenti identificate:

Versione di GKE su VMware Versione kubelet Versione di Kubernetes
1.13.10 Versione 1.24.11-gke.1200 Versione 1.24.14-gke.2100
1.14.6 Versione 1.25.8-gke.1500 Versione 1.25.10-gke.1200
1.15.3 Versione 1.26.2-gke.1001 Versione 1.26.5-gke.2100

Soluzione alternativa:

Non è richiesto alcun intervento. L'incoerenza riguarda solo le versioni delle patch di Kubernetes e non ci sono problemi causati da questo disallineamento delle versioni.

Upgrade e aggiornamenti 1.15.0-1.15.4

L'upgrade o l'aggiornamento di un cluster di amministrazione con una versione CA maggiore di 1 non riesce

Se un cluster di amministrazione ha una versione dell'autorità di certificazione (CA) superiore a 1, un aggiornamento o un upgrade non va a buon fine a causa della convalida della versione della CA nel webhook. L'output dell'upgrade/dell'aggiornamento di gkectl contiene il seguente messaggio di errore: 

    CAVersion must start from 1

Soluzione alternativa:

  • Fai lo scale down del deployment di auto-resize-controller nel cluster di amministrazione per disabilitare il ridimensionamento automatico dei nodi. Questa operazione è necessaria perché un nuovo campo introdotto nella risorsa personalizzata del cluster di amministrazione in 1.15 può causare un errore di puntatore null in auto-resize-controller. 
     kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
  • Esegui i comandi gkectl con il flag --disable-admin-cluster-webhook.Ad esempio: 
            gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
Operazione 1,13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1

L'eliminazione del cluster V2 del piano di controllo non ad alta disponibilità è bloccata fino al timeout

Quando viene eliminato un cluster Controlplane V2 non ad alta disponibilità, rimane bloccato all'eliminazione del nodo fino al timeout.

Soluzione alternativa:

Se il cluster contiene uno StatefulSet con dati critici, contatta l'assistenza clienti Google Cloud per risolvere il problema.

In caso contrario, svolgi i seguenti passaggi:

  • Elimina tutte le VM del cluster da vSphere. Puoi eliminare le VM tramite l'interfaccia utente di vSphere o eseguire questo comando: 
          govc vm.destroy
    .
  • Forza di nuovo l'eliminazione del cluster: 
         gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force

Storage 1.15.0 e versioni successive, 1.16.0 e versioni successive

Le attività di collegamento CNS costante vengono visualizzate ogni minuto per PVC/PV in-tree dopo l'upgrade alla versione 1.15 o successive

Quando un cluster contiene volumi permanenti vSphere in-tree (ad esempio, PVC create con StorageClass standard), osserverai attività com.vmware.cns.tasks.attachvolume attivate ogni minuto da vCenter.


Soluzione alternativa:

Modifica il campo configMap della funzionalità CSI di vSphere e imposta list-volumes su false:

     kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG

Riavvia i pod del controller CSI vSphere:

     kubectl rollout restart vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Storage 1.16.0

False allerte contro le PVC

Quando un cluster contiene volumi permanenti vSphere, i comandi gkectl diagnose e gkectl upgrade potrebbero generare avvisi falsi sulle richieste di volumi permanenti (PVC) al momento della convalida delle impostazioni di archiviazione del cluster. Il messaggio di avviso è simile al seguente 

    CSIPrerequisites pvc/pvc-name: PersistentVolumeClaim pvc-name bounds to an in-tree vSphere volume created before CSI migration enabled, but it doesn't have the annotation pv.kubernetes.io/migrated-to set to csi.vsphere.vmware.com after CSI migration is enabled

Soluzione alternativa:

Esegui questo comando per controllare le annotazioni di una PVC con l'avviso riportato sopra:

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -oyaml --kubeconfig KUBECONFIG

Se il campo annotations nell'output contiene quanto segue, puoi ignorare tranquillamente l'avviso:

      pv.kubernetes.io/bind-completed: "yes"
      pv.kubernetes.io/bound-by-controller: "yes"
      volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
Upgrade e aggiornamenti 1.15.0 e versioni successive, 1.16.0 e versioni successive

La rotazione della chiave dell'account di servizio non va a buon fine quando più chiavi sono scadute

Se il cluster non utilizza un registro privato e la chiave dell'account di servizio di accesso ai componenti e le chiavi dell'account di servizio Logging-monitoring (o Connect-registra) sono scadute, quando ruoti le chiavi dell'account di servizio, l'errore gkectl update credentials genera un errore simile al seguente: 

Error: reconciliation failed: failed to update platform: ...

Soluzione alternativa:

Innanzitutto, ruota la chiave dell'account di servizio di accesso ai componenti. Anche se viene visualizzato lo stesso messaggio di errore, dovresti essere in grado di ruotare le altre chiavi dopo la rotazione della chiave dell'account di servizio di accesso ai componenti.

Se l'aggiornamento non va ancora a buon fine, contatta l'assistenza clienti Google Cloud per risolvere il problema.
Upgrade 1.16.0-1.16.5

1.15 La macchina master dell'utente riscontra una ricreazione imprevista quando viene eseguito l'upgrade del controller del cluster utente alla versione 1.16

Durante l'upgrade di un cluster utente, dopo l'upgrade del controller del cluster utente alla versione 1.16, se altri cluster utente della versione 1.15 sono gestiti dallo stesso cluster di amministrazione, la macchina master dell'utente potrebbe essere ricreata inaspettatamente.

C'è un bug nel controller del cluster utente 1.16 che può attivare la nuova creazione della macchina master degli utenti di 1.15 utenti.

La soluzione alternativa da adottare dipende da come si verifica il problema.

Soluzione alternativa quando esegui l'upgrade del cluster utente utilizzando la console Google Cloud:

Opzione 1: utilizza una versione 1.16.6 o successiva di GKE su VMware con la correzione.

Opzione 2. Procedi nel seguente modo:

  1. Aggiungi manualmente l'annotazione di ripetizione utilizzando il seguente comando: 
    kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

    La replica dell'annotazione è:

    onprem.cluster.gke.io/server-side-preflight-rerun: true
  2. Monitora l'avanzamento dell'upgrade controllando il campo status di OnPremUserCluster.

Soluzione alternativa quando esegui l'upgrade del cluster utente utilizzando la tua workstation di amministrazione:

Opzione 1: utilizza una versione 1.16.6 o successiva di GKE su VMware con la correzione.

Opzione 2. Procedi nel seguente modo:

  1. Aggiungi il file di informazioni sulla build /etc/cloud/build.info con i seguenti contenuti. In questo modo i controlli preflight vengono eseguiti localmente sulla workstation di amministrazione anziché sul server. 
    gke_on_prem_version: GKE_ON_PREM_VERSION
    Ad esempio: 
    gke_on_prem_version: 1.16.0-gke.669
  2. Esegui nuovamente il comando di upgrade.
  3. Al termine dell'upgrade, elimina il file build.info.
Crea 1.16.0-1.16.5, 1.28.0-1.28.100

Il controllo preflight non va a buon fine quando il nome host non è presente nel file di blocco IP.

Durante la creazione del cluster, se non specifichi un nome host per ogni indirizzo IP nel file di blocchi IP, il controllo preflight non va a buon fine e viene visualizzato il seguente messaggio di errore: 

multiple VMs found by DNS name  in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.`

Nel controllo preflight è presente un bug che presuppone che un nome host vuoto sia duplicato.

Soluzione alternativa:

Opzione 1: utilizza una versione con la correzione.

Opzione 2: ignora questo controllo preflight aggiungendo il flag --skip-validation-net-config.

Opzione 3: specifica un nome host univoco per ciascun indirizzo IP nel file di blocchi IP.
Upgrade e aggiornamenti 1,16

Errore di montaggio del volume durante l'upgrade o l'aggiornamento del cluster di amministrazione se utilizzi un cluster di amministrazione non ad alta disponibilità e il cluster utente del piano di controllo v1

Per un cluster di amministrazione non ad alta disponibilità e un cluster utente v1 del piano di controllo, quando esegui l'upgrade o l'aggiornamento del cluster di amministrazione, la ricreazione della macchina master del cluster di amministrazione potrebbe avvenire in concomitanza al riavvio della macchina master del cluster utente, il che può far emergere una race condition. Di conseguenza, i pod del piano di controllo del cluster utente non sono in grado di comunicare con il piano di controllo del cluster di amministrazione, causando problemi di collegamento del volume per kube-etcd e kube-apiserver sul piano di controllo del cluster utente.

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

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
Verranno visualizzati 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 alternativa:

  1. Accedi tramite SSH nel nodo del piano di controllo dell'utente, poiché si tratta del cluster utente del piano di controllo v1, il nodo del piano di controllo dell'utente si trova nel cluster di amministrazione.
  2. Riavvia il kubelet utilizzando questo comando: 
        sudo systemctl restart kubelet
    Dopo il riavvio, il kubelet può ricostruire correttamente il montaggio globale dello stage.
Upgrade e aggiornamenti 1.16.0

Impossibile creare il nodo del piano di controllo

Durante un upgrade o un aggiornamento di un cluster di amministrazione, una race condition potrebbe causare l'eliminazione imprevista di un nuovo nodo del piano di controllo da parte di vSphere Cloud Controller Manager. Questo causa il blocco di clusterapi-controller in attesa della creazione del nodo e, a sua volta, l'upgrade/aggiornamento scade. In questo caso, l'output del comando gkectl upgrade/update è simile al seguente:

    controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"...

Per identificare il sintomo, esegui il comando seguente per accedere a vSphere Cloud Controller Manager nel 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

Ecco un esempio di messaggio di errore del comando precedente:

    node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache.

Soluzione alternativa:

  1. Riavvia la macchina non riuscita per ricreare l'oggetto del nodo eliminato.
  2. Accedi tramite SSH a ciascun nodo del piano di controllo e riavvia il pod statico vSphere Cloud Controller Manager: 
          sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
      sudo crictl stop PREVIOUS_COMMAND_OUTPUT
  3. Esegui di nuovo il comando upgrade/update.
Operazione 1,16

Un nome host duplicato nello stesso data center causa errori di creazione o upgrade del cluster

L'upgrade di un cluster 1.15 o la creazione di un cluster 1.16 con IP statici non riesce se sono presenti nomi host duplicati nello stesso data center. Questo errore si verifica perché vSphere Cloud Controller Manager non riesce ad aggiungere un IP esterno e un ID provider nell'oggetto nodo. Questo causa il timeout dell'upgrade o della creazione del cluster.

Per identificare il problema, recupera i log dei pod di vSphere Cloud Controller Manager per il cluster. Il comando che utilizzi 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 utente (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: (Controlplane 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

Verifica se il nome host è duplicato nel data center:

Puoi utilizzare il seguente approccio per verificare se il nome host è duplicato e adottare una soluzione alternativa, se necessario. 
          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 di esempio e output: 
          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 da adottare dipende dall'operazione non riuscita.

Soluzione alternativa per gli upgrade:

Esegui la soluzione alternativa per il tipo di cluster applicabile.

  • Cluster utente:
    1. Aggiorna il nome host della macchina interessata in user-ip-block.yaml impostando 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 di amministrazione non ad alta disponibilità e noti che la VM master di amministrazione utilizza un nome host duplicato, devi anche:
      Ottenere il nome della macchina master dell'amministratore 
                kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
      Aggiornare l'oggetto macchina master dell'amministratore
      Nota: NEW_ADMIN_MASTER_HOSTNAME deve essere uguale a quello che hai 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 macchina master 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 disabilitato:
                gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

Soluzione alternativa per le installazioni:

Esegui la soluzione alternativa per il tipo di cluster applicabile.
Operazione 1.16.0, 1.16.1, 1.16.2, 1.16.3

$ e ` non sono supportati nel nome utente o nella password vSphere

Le seguenti operazioni non riescono quando il nome utente o la password vSphere contiene $ o `:

  • Upgrade di un cluster utente da 1.15 con Controlplane V2 abilitato alla versione 1.16
  • Upgrade di un cluster di amministrazione ad alta disponibilità (HA) alla versione 1.15 alla versione 1.16
  • Creazione di un cluster utente 1.16 con Controlplane V2 abilitato
  • Creazione di un cluster di amministrazione ad alta disponibilità 1.16

Utilizza una versione 1.16.4 o successiva di GKE su VMware con la correzione o esegui la soluzione alternativa riportata di seguito. La soluzione alternativa da adottare dipende dall'operazione non riuscita.

Soluzione alternativa per gli upgrade:

  1. Modifica il nome utente o la password di vCenter sul lato vCenter per rimuovere $ e `.
  2. Aggiorna il nome utente o la password vCenter nel file di configurazione delle credenziali.
  3. Attiva un aggiornamento forzato del cluster.
    • Cluster utente: 
              gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
    • Cluster di amministrazione: 
              gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check

Soluzione alternativa per le installazioni:

  1. Modifica il nome utente o la password di vCenter sul lato vCenter per rimuovere $ e `.
  2. Aggiorna il nome utente o la password vCenter nel file di configurazione delle credenziali.
  3. Esegui la soluzione alternativa per il tipo di cluster applicabile.
Storage 1,11+, 1,12+, 1,13+, 1,14+, 1,15+, 1,16

Errore di creazione PVC dopo la creazione di un nodo con lo stesso nome

Dopo che un nodo è stato eliminato e poi ricreato con lo stesso nome, esiste una minima possibilità che la creazione di un PersistentVolumeClaim (PVC) successivo abbia esito negativo e generi un errore come il seguente:

    The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created

Ciò è causato da race condition in cui il controller CSI vSphere non elimina una macchina rimossa dalla cache.


Soluzione alternativa:

Riavvia i pod del controller CSI vSphere:

    kubectl rollout restart vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Operazione 1.16.0

La riparazione di gkectl admin-master restituisce l'errore di annullamento del marshall di kubeconfig

Quando esegui il comando gkectl repair admin-master su un cluster di amministrazione ad alta disponibilità, gkectl restituisce il seguente messaggio di errore: 

  Exit with error: Failed to repair: failed to select the template: failed to get cluster name from kubeconfig, please contact Google support. failed to decode kubeconfig data: yaml: unmarshal errors:
    line 3: cannot unmarshal !!seq into map[string]*api.Cluster
    line 8: cannot unmarshal !!seq into map[string]*api.Context

Soluzione alternativa:

Aggiungi il flag --admin-master-vm-template= al comando e fornisci il modello di VM della macchina da riparare: 

  gkectl repair admin-master --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --config ADMIN_CLUSTER_CONFIG_FILE \
      --admin-master-vm-template=/DATA_CENTER/vm/VM_TEMPLATE_NAME

Per trovare il modello di VM della macchina:

  1. Vai alla pagina Host e cluster nel client vSphere.
  2. Fai clic su Modelli di VM e filtra in base al nome del cluster di amministrazione.

    Dovresti vedere i tre modelli di VM per il cluster di amministrazione.

  3. Copia il nome del modello di VM che corrisponde al nome della macchina da riparare e utilizza il nome del modello nel comando di riparazione.
  gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
Networking 1.10.0 e versioni successive, 1.11.0 e versioni successive, 1.12.0 e versioni successive, 1.13.0 e versioni successive, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0

VM Seesaw non funzionante a causa dello spazio su disco in esaurimento

Se utilizzi Seesaw come tipo di bilanciatore del carico per il tuo cluster e noti che una VM Seesaw non è disponibile o continua a non avviarsi, potresti visualizzare il seguente messaggio di errore nella console vSphere:

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

Questo errore indica che lo spazio su disco nella VM è in esaurimento, perché il bit di fluente in esecuzione sulla VM di Seesaw non è configurato con la rotazione dei log corretta.


Soluzione alternativa:

Individua i file di log che occupano la maggior parte dello spazio su disco utilizzando du -sh -- /var/lib/docker/containers/* | sort -rh. Esegui la pulizia del file di log con le dimensioni più grandi e riavvia la VM.

Nota:se la VM è completamente inaccessibile, collega il disco a una VM funzionante (ad esempio una workstation di amministrazione), rimuovi il file dal disco collegato, quindi ricollega il disco alla VM Seesaw originale.

Per evitare che il problema si ripresenti, connettiti alla VM e modifica il file /etc/systemd/system/docker.fluent-bit.service. Aggiungi --log-opt max-size=10m --log-opt max-file=5 nel comando Docker, quindi esegui systemctl restart docker.fluent-bit.service
Operazione 1,13, 1,14.0-1.14.6, 1,15

Errore della chiave pubblica SSH di amministrazione dopo l'upgrade o l'aggiornamento del cluster di amministrazione

Quando provi a eseguire l'upgrade (gkectl upgrade admin) o ad aggiornare (gkectl update admin) un cluster di amministrazione non ad alta disponibilità con il checkpoint abilitato, l'upgrade o l'aggiornamento potrebbero non riuscire e generare errori come i seguenti: 

Checking admin cluster certificates...FAILURE
    Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
    AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey).

failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey)

error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...


Soluzione alternativa:

Se non riesci a eseguire l'upgrade a una versione patch di GKE su VMware con la correzione, contatta l'Assistenza Google per ricevere supporto.
Upgrade 1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2

L'upgrade di un cluster di amministrazione registrato nell'API GKE On-Prem potrebbe non riuscire

Quando un cluster di amministrazione viene registrato nell'API GKE On-Prem, l'upgrade del cluster di amministrazione alle versioni interessate potrebbe non riuscire perché non è stato possibile aggiornare l'appartenenza al parco risorse. In questo caso, quando provi a eseguire l'upgrade del cluster viene visualizzato il seguente errore:

    failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated

Un cluster di amministrazione viene registrato nell'API quando registri esplicitamente il cluster o quando esegui l'upgrade di un cluster utente utilizzando un client API GKE On-Prem.


Soluzione alternativa:

Annulla la registrazione del cluster di amministrazione: 
    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
e riprendi l'upgrade del cluster di amministrazione. Potresti visualizzare temporaneamente l'errore obsoleto "Registrazione del cluster non riuscita". Dopo un po' di tempo, dovrebbe essere aggiornata automaticamente.
Upgrade e aggiornamenti 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

Quando un cluster di amministrazione viene registrato nell'API GKE On-Prem, la relativa annotazione del link alle risorse viene applicata alla risorsa personalizzata OnPremAdminCluster, che non viene conservata durante i successivi aggiornamenti del cluster di amministrazione a causa dell'utilizzo della chiave di annotazione errata. Di conseguenza, il cluster di amministrazione può essere registrato di nuovo nell'API GKE On-Prem per errore.

Un cluster di amministrazione viene registrato nell'API quando registri esplicitamente il cluster o quando esegui l'upgrade di un cluster utente utilizzando un client API GKE On-Prem.


Soluzione alternativa:

Annulla la registrazione del cluster di amministrazione: 
    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
e registra nuovamente di nuovo il cluster di amministrazione.
Networking 1.15.0-1.15.2

CoreDNS orderPolicy non riconosciuto

OrderPolicy non viene riconosciuto come parametro e non viene utilizzato. GKE su VMware utilizza sempre Random.

Questo problema si verifica perché il modello CoreDNS non è stato aggiornato e, di conseguenza, viene ignorato orderPolicy.


Soluzione alternativa:

Aggiorna il modello CoreDNS e applica la correzione. Questa correzione persiste fino a un upgrade.

  1. Modifica il modello esistente: 
    kubectl edit cm -n kube-system coredns-template
    Sostituisci i contenuti del modello con quanto segue: 
    coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}
Upgrade e aggiornamenti 1,10, 1,11, 1,12, 1.13.0-1.13.7, 1.14.0-1.14.3

Stato OnPremAdminCluster incoerente tra il checkpoint e la RP effettiva

Alcune condizioni di gara potrebbero causare un'incoerenza dello stato OnPremAdminCluster tra il checkpoint e la RP effettiva. In questo caso, potresti riscontrare il seguente errore quando aggiorni il cluster di amministrazione dopo averlo eseguito:

Exit with error:
E0321 10:20:53.515562  961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Per risolvere il problema, dovrai modificare il checkpoint o disattivarlo per l'upgrade/l'aggiornamento. Contatta il nostro team di assistenza per procedere con la soluzione alternativa.
Operazione 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Modifiche al processo di riconciliazione dei certificati amministrativi sui cluster di amministrazione

GKE su VMware modifica i certificati di amministrazione sui piani di controllo dei cluster di amministrazione a ogni processo di riconciliazione, ad esempio durante un upgrade del cluster. Questo comportamento aumenta la possibilità di ricevere certificati non validi per il cluster di amministrazione, in particolare per i cluster della versione 1.15.

Se riscontri questo problema, potresti riscontrare problemi come i seguenti:

  • I certificati non validi possono causare il timeout dei seguenti comandi e la restituzione di errori:
    • gkectl create admin
    • gkectl upgrade amdin
    • gkectl update admin

    Questi comandi possono restituire errori di autorizzazione come i seguenti:

    Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
  • I log kube-apiserver per il cluster di amministrazione potrebbero contenere errori come i seguenti: 
    Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

Soluzione alternativa:

Esegui l'upgrade a una versione di GKE su VMware con la correzione: 1.13.10 e versioni successive, 1.14.6 e versioni successive, 1.15.2 e versioni successive. Se l'upgrade non è possibile per te, contatta l'assistenza clienti Google Cloud per risolvere il problema.
Networking, operazione 1,10; 1,11; 1,12; 1,13; 1,14

Componenti del gateway di rete Anthos rimossi o in attesa a causa di una classe di priorità mancante

I pod del gateway di rete in kube-system potrebbero mostrare uno stato Pending o Evicted, come mostrato nel seguente output di esempio ridotto:

$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Questi errori indicano eventi di rimozione o l'impossibilità di pianificare i pod a causa delle risorse dei nodi. Poiché i pod del gateway di rete Anthos non hanno PriorityClass, hanno la stessa priorità predefinita degli altri carichi di lavoro. Quando i nodi sono vincolati dalle risorse, i pod del gateway di rete potrebbero essere rimossi. Questo comportamento è particolarmente negativo per il DaemonSet ang-node, poiché questi pod devono essere pianificati su un nodo specifico e non possono essere sottoposti a migrazione.


Soluzione alternativa:

Esegui l'upgrade alla versione 1.15 o successive.

Come soluzione a breve termine, puoi assegnare manualmente un elemento PriorityClass ai componenti del gateway di rete di Anthos. Il controller GKE su VMware sovrascrive queste modifiche manuali durante un processo di riconciliazione, ad esempio durante un upgrade del cluster.

  • Assegna il valore PriorityClass system-cluster-critical ai deployment dei controller di cluster ang-controller-manager e autoscaler.
  • Assegna il PriorityClass system-node-critical al nodo ang-daemon DaemonSet.
Upgrade e aggiornamenti 1,12, 1,13, 1,14, 1,15,0-1,15,2

l'upgrade del cluster di amministrazione non va a buon fine dopo la registrazione del cluster con gcloud

Dopo aver utilizzato gcloud per registrare un cluster di amministrazione con una sezione gkeConnect non vuota, potresti visualizzare il seguente errore quando cerchi di eseguire l'upgrade del cluster:

failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

Elimina lo spazio dei nomi gke-connect: 

kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
Ottieni il nome del cluster di amministrazione: 
kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Elimina l'appartenenza al parco risorse: 
gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
e riprendi l'upgrade del cluster di amministrazione.
Operazione 1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

gkectl diagnose snapshot --log-since non riesce a limitare la finestra temporale per i comandi journalctl in esecuzione sui nodi del cluster

Questo non influisce sulla funzionalità di creazione di uno snapshot del cluster, poiché lo snapshot include comunque tutti i log raccolti per impostazione predefinita eseguendo journalctl sui nodi del cluster. Pertanto, le informazioni di debug non vengono ignorate.
Installazione, upgrade e aggiornamenti 1.9 e versioni successive, 1.10 e versioni successive, 1.11 e versioni successive, 1.12 e versioni successive

gkectl prepare windows non va a buon fine

gkectl prepare windows non riesce a installare Docker su versioni di GKE su VMware precedenti alla 1.13 perché MicrosoftDockerProvider è deprecato.


Soluzione alternativa:

L'idea generale per risolvere questo problema è eseguire l'upgrade a GKE su VMware 1.13 e utilizzare gkectl 1.13 per creare un modello di VM Windows e quindi creare pool di nodi Windows. Esistono due opzioni per accedere a GKE su VMware 1.13 dalla tua versione attuale, come mostrato di seguito.

Nota: esistono opzioni per aggirare questo problema nella tua versione attuale senza dover eseguire l'upgrade fino alla 1.13, ma saranno necessari più passaggi manuali. Contatta il nostro team di assistenza se vuoi prendere in considerazione questa opzione.


Opzione 1: upgrade blu/verde

Puoi creare un nuovo cluster utilizzando la versione GKE su VMware 1.13 e versioni successive con pool di nodi Windows, eseguire la migrazione dei carichi di lavoro nel nuovo cluster, quindi eliminare il cluster attuale. Ti consigliamo di utilizzare la versione secondaria più recente di GKE su VMware.

Nota: questa operazione richiederà risorse aggiuntive per il provisioning del nuovo cluster, ma meno tempi di inattività e interruzioni per i carichi di lavoro esistenti.


Opzione 2: elimina i pool di nodi Windows e aggiungili di nuovo quando esegui l'upgrade a GKE su VMware 1.13

Nota: per questa opzione, i carichi di lavoro Windows non potranno essere eseguiti finché non verrà eseguito l'upgrade del cluster alla versione 1.13 e i pool di nodi Windows non verranno aggiunti nuovamente.

  1. Elimina i pool di nodi Windows esistenti rimuovendo la configurazione dei pool di nodi Windows dal file user-cluster.yaml, quindi esegui il comando: 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. Esegui l'upgrade dei cluster amministratore+utente solo per Linux alla versione 1.12 seguendo la guida dell'utente per l'upgrade della versione secondaria di destinazione corrispondente.
  3. Assicurati di eseguire questo passaggio prima di eseguire l'upgrade alla versione 1.13. Assicurati che enableWindowsDataplaneV2: true sia configurato nella RP OnPremUserCluster, altrimenti il cluster continuerà a utilizzare Docker per i pool di nodi Windows, il che non sarà compatibile con il modello di VM Windows 1.13 appena creato in cui non è installato Docker. Se non viene configurato o se viene impostato su false, aggiorna il cluster in modo da impostarlo su true in user-cluster.yaml, quindi esegui: 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  4. Esegui l'upgrade dei cluster utente e di amministrazione solo per Linux alla versione 1.13 seguendo la guida dell'utente per l'upgrade.
  5. Prepara il modello di VM Windows utilizzando gkectl 1.13: 
    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. Aggiungi di nuovo la configurazione del pool di nodi Windows a user-cluster.yaml con il campo OSImage impostato sul modello di VM Windows appena creato.
  7. Aggiorna il cluster per aggiungere pool di nodi Windows 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Installazione, upgrade e aggiornamenti 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

La configurazione di RootDistanceMaxSec non viene applicata per ubuntu nodi

Sui nodi verrà utilizzato il valore predefinito di 5 secondi per RootDistanceMaxSec, anziché 20 secondi, che dovrebbe essere la configurazione prevista. Se controlli il log di avvio del nodo tramite SSH nella VM, che si trova in "/var/log/startup.log", puoi vedere il seguente errore:

+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

L'utilizzo di un RootDistanceMaxSec di 5 secondi potrebbe causare la mancata sincronizzazione dell'orologio di sistema con il server NTP quando la deviazione dell'orologio è superiore a 5 secondi.


Soluzione alternativa:

Applica il seguente DaemonSet al tuo cluster per configurare RootDistanceMaxSec:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-root-distance
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-root-distance
  template:
    metadata:
      labels:
        app: change-root-distance
    spec:
      hostIPC: true
      hostPID: true
      tolerations:
      # Make sure pods gets scheduled on all nodes.
      - effect: NoSchedule
        operator: Exists
      - effect: NoExecute
        operator: Exists
      containers:
      - name: change-root-distance
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf"
            if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then
              echo "timesyncd has the expected RootDistanceMaxSec, skip update"
            else
              echo "updating timesyncd config to RootDistanceMaxSec=20"
              mkdir -p /etc/systemd/timesyncd.conf.d
              cat > $conf_file << EOF
          [Time]
          RootDistanceMaxSec=20
          EOF
              systemctl restart systemd-timesyncd
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
Upgrade e aggiornamenti 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

gkectl update admin non riuscito a causa del campo osImageType vuoto

Quando utilizzi la versione 1.13 gkectl per aggiornare un cluster di amministrazione alla versione 1.12, potresti visualizzare il seguente errore:

Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

Quando utilizzi gkectl update admin per i cluster versione 1.13 o 1.14, nella risposta potrebbe essere visualizzato il seguente messaggio:

Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

Se controlli il log gkectl, potresti notare che le modifiche includono l'impostazione osImageType da una stringa vuota a ubuntu_containerd.

Questi errori di aggiornamento sono dovuti a un backfill non corretto del campo osImageType nella configurazione del cluster di amministrazione da quando è stato introdotto nella versione 1.9.


Soluzione alternativa:

Esegui l'upgrade a una versione di GKE su VMware con la correzione. Se l'upgrade non è possibile, contatta l'assistenza clienti Google Cloud per risolvere il problema.
Installazione, sicurezza 1,13; 1,14; 1,15; 1,16

SNI non funziona sui cluster utente con Controlplane V2

La possibilità di fornire un certificato di pubblicazione aggiuntivo per il server API Kubernetes di un cluster utente con authentication.sni non funziona se è abilitato il piano di controllo V2 ( enableControlplaneV2: true).


Soluzione alternativa:

Fino a quando non sarà disponibile una patch per GKE su VMware con la correzione, se devi utilizzare SNI, disabilita Controlplane V2 (enableControlplaneV2: false).
Installazione 1,0-1,11, 1,12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

$ nel nome utente del registro privato causa un errore di avvio della macchina del piano di controllo dell'amministratore

La macchina del piano di controllo dell'amministratore non si avvia quando il nome utente del registro privato contiene $. Durante il controllo di /var/log/startup.log sulla macchina del piano di controllo dell'amministratore, viene visualizzato il seguente errore: 

++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

Soluzione alternativa:

Utilizza un nome utente del registro privato senza $ oppure utilizza una versione di GKE su VMware con la correzione.
Upgrade e aggiornamenti 1.12.0-1.12.4

Avvisi falsi positivi relativi a modifiche non supportate durante l'aggiornamento del cluster di amministrazione

Quando aggiorni i cluster di amministrazione, nel log vedrai i seguenti avvisi di falsi positivi che puoi ignorare. 

    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      - 		CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      + 		CARotation:        nil,
      ...
    }
Upgrade e aggiornamenti 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Aggiornamento del cluster utente non riuscito dopo la rotazione della chiave di firma dell'Arabia Saudita

Dopo aver ruotato le chiavi di firma dell'Arabia Saudita e successivamente l'aggiornamento di un cluster utente, gkectl update potrebbe non riuscire con il seguente messaggio di errore: 

Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"


Soluzione alternativa:

Ripristina la versione 1 della versione della chiave di firma dell'Arabia Saudita, ma conserva i dati della chiave più recenti:
  1. Controlla il secret nel cluster di amministrazione nello spazio dei nomi USER_CLUSTER_NAME e recupera il nome del secret ksa-signing-key: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. Copia il secret della chiave di firma ksa e denomina il secret copiato come service-account-cert: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
  3. Elimina il secret della chiave di firma ksa precedente: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. Aggiorna il campo data.data in ksa-signing-key-rotation-stage configmap in '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}': 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
  5. Disabilita il webhook di convalida per modificare le informazioni sulla versione nella risorsa personalizzata OnPremUserCluster: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremuserclusters
'
  6. Aggiorna il campo spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation in 1 nella risorsa personalizzata OnPremUserCluster: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
  7. Attendi che il cluster utente di destinazione sia pronto. Per controllare lo stato: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. Ripristina il webhook di convalida per il cluster utente: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
  9. Evita un'altra rotazione della chiave di firma KSA finché non viene eseguito l'upgrade del cluster alla versione con la correzione.
Operazione 1.13.1+, 1,14, 1., 1,16

La pulizia dei server virtuali BIG-IP di F5 non viene eseguita quando Terraform elimina i cluster utente

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


Soluzione alternativa:

Per rimuovere le risorse F5, segui i passaggi per pulire una partizione F5 del cluster utente

Installazione, upgrade e aggiornamenti 1.13.8, 1.14.4

tipo cluster estrae le immagini container da docker.io

Se crei un cluster di amministrazione della versione 1.13.8 o della versione 1.14.4 o esegui l'upgrade di un cluster di amministrazione alla versione 1.13.8 o 1.14.4, il cluster del tipo estrae le seguenti immagini container da docker.io:

  • docker.io/kindest/kindnetd
  • docker.io/kindest/local-path-provisioner
  • docker.io/kindest/local-path-helper

    • Se docker.io non è accessibile dalla workstation di amministrazione, la creazione o l'upgrade del cluster di amministrazione non riesce ad attivare il cluster di tipo. L'esecuzione del comando seguente sulla workstation di amministrazione mostra i container corrispondenti in attesa con ErrImagePull:

    docker exec gkectl-control-plane kubectl get pods -A

    La risposta contiene voci come la seguente:

    ...
kube-system         kindnet-xlhmr                             0/1
    ErrImagePull  0    3m12s
...
local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
    Pending       0    3m12s
...

    Queste immagini container devono essere precaricate nell'immagine container del tipo cluster. Tuttavia, il tipo v0.18.0 presenta un problema con le immagini container precaricate, a causa del quale vengono estratte da internet per errore.


    Soluzione alternativa:

    Esegui i comandi seguenti sulla workstation di amministrazione mentre il cluster di amministrazione è in attesa di creazione o upgrade:

    docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
    Operazione 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    Failover non riuscito sul cluster utente e sul cluster di amministrazione del piano di controllo ad alta disponibilità quando la rete filtra le richieste GARP duplicate

    Se le VM del cluster sono connesse con uno switch che filtra le richieste GARP (ARP gratuite) duplicate, l'elezione del leader keepaDuration potrebbe riscontrare una race condition, che fa sì che alcuni nodi abbiano voci della tabella ARP errate.

    I nodi interessati possono ping il VIP del piano di controllo, ma scadrà una connessione TCP al VIP del piano di controllo.


    Soluzione alternativa:

    Esegui questo comando su ciascun nodo del piano di controllo del cluster interessato: 
        iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    Upgrade e aggiornamenti 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    vsphere-csi-controller deve essere riavviato dopo la rotazione del certificato vCenter

    vsphere-csi-controller deve aggiornare il secret vCenter dopo la rotazione del certificato vCenter. Tuttavia, il sistema attuale non riavvia correttamente i pod di vsphere-csi-controller, causando l'arresto anomalo di vsphere-csi-controller dopo la rotazione.

    Soluzione alternativa:

    Per i cluster creati nella versione 1.13 e successive, segui le istruzioni riportate di seguito per riavviare vsphere-csi-controller 

    kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
    Installazione 1,10,3-1,10.7, 1,11, 1,12, 1,13,0-1,13,1

    La creazione del cluster di amministrazione non riesce in caso di errori di registrazione del cluster

    Anche se la registrazione del cluster non va a buon fine durante la creazione del cluster di amministrazione, il comando gkectl create admin non restituisce errori sull'errore e potrebbe avere esito positivo. In altre parole, la creazione del cluster di amministrazione potrebbe "riuscire" senza essere registrata in un parco risorse.

    Per identificare il sintomo, puoi cercare i seguenti messaggi di errore nel log di "gkectl create admin", 
    Failed to register admin cluster

    Puoi anche verificare se riesci a trovare il cluster tra i cluster registrati su Cloud Console.

    Soluzione alternativa:

    Per i cluster creati nella versione 1.12 e successive, segui le istruzioni per ritentare la registrazione del cluster di amministrazione dopo la creazione del cluster. Per i cluster creati con versioni precedenti,

    1. Aggiungi una coppia chiave-valore falsa, ad esempio "foo: bar", al file di chiave SA Connect-registra
    2. Esegui gkectl update admin per registrare nuovamente il cluster di amministrazione.

    Upgrade e aggiornamenti 1,10, 1,11, 1,12, 1,13,0-1,13,1

    La nuova registrazione del cluster di amministrazione potrebbe essere saltata durante l'upgrade del cluster di amministrazione

    Durante l'upgrade del cluster di amministrazione, se si verifica il timeout dei nodi del piano di controllo dell'utente, il cluster di amministrazione non verrà registrato nuovamente con la versione aggiornata dell'agente Connect.


    Soluzione alternativa:

    Controlla se il cluster viene visualizzato tra i cluster registrati. Come passaggio facoltativo, accedi al cluster dopo aver configurato l'autenticazione. Se il cluster è ancora registrato, puoi saltare le seguenti istruzioni per tentare nuovamente la registrazione. Per i cluster di cui è stato eseguito l'upgrade alla versione 1.12 e successive, segui le istruzioni per ritentare la registrazione del cluster di amministrazione dopo la creazione del cluster. Per i cluster di cui è stato eseguito l'upgrade alle versioni precedenti:
    1. Aggiungi una coppia chiave-valore falsa, ad esempio "foo: bar", al file di chiave SA Connect-registra
    2. Esegui gkectl update admin per registrare nuovamente il cluster di amministrazione.

    Configurazione 1.15.0

    Messaggio di errore falso relativo a vCenter.dataDisk

    Per un cluster di amministrazione ad alta disponibilità, gkectl prepare mostra questo falso messaggio di errore:

    vCenter.dataDisk must be present in the AdminCluster spec

    Soluzione alternativa:

    Puoi ignorare questo messaggio di errore.
    VMware 1.15.0

    La creazione del pool di nodi non riesce a causa di regole di affinità VM-host ridondanti

    Durante la creazione di un pool di nodi che utilizza l'affinità host VM, una race condition potrebbe comportare la creazione di più regole di affinità host VM con lo stesso nome. Di conseguenza, la creazione del pool di nodi potrebbe non riuscire.


    Soluzione alternativa:

    Rimuovi le vecchie regole ridondanti in modo che possa continuare la creazione del pool di nodi. Il nome di queste regole è [USER_CLUSTER_NAME]-[HASH].
    Operazione 1.15.0

    gkectl repair admin-master potrebbe non riuscire a causa di failed to delete the admin master node object and reboot the admin master VM

    Il comando gkectl repair admin-master potrebbe non riuscire a causa di una race condition con il seguente errore. 

    Failed to repair: failed to delete the admin master node object and reboot the admin master VM


    Soluzione alternativa:

    Questo comando è idempotente. Può essere eseguito nuovamente in sicurezza fino all'esito positivo del comando.
    Upgrade e aggiornamenti 1.15.0

    I pod rimangono in stato Non riuscito, ovvero ricreazione o aggiornamento di un nodo del piano di controllo

    Dopo aver ricreato o aggiornato un nodo del piano di controllo, alcuni pod potrebbero rimanere nello stato Failed a causa di un errore del predicato NodeAffinity. Questi pod in errore non influiscono sulle normali operazioni o sull'integrità del cluster.


    Soluzione alternativa:

    Puoi ignorare tranquillamente i pod in errore o eliminarli manualmente.
    Sicurezza, configurazione 1.15.0-1.15.1

    OnPremUserCluster non pronto a causa di credenziali del registro private

    Se utilizzi credenziali preparate e un registro privato, ma non hai configurato quelle preparate per il registro privato, OnPremUserCluster potrebbe non essere pronto e potresti visualizzare il seguente messaggio di errore: 

    failed to check secret reference for private registry …


    Soluzione alternativa:

    Prepara le credenziali del registro privato per il cluster utente in base alle istruzioni riportate in Configurare le credenziali preparate.

    Upgrade e aggiornamenti 1.15.0

    gkectl upgrade admin non va a buon fine con StorageClass standard sets the parameter diskformat which is invalid for CSI Migration

    Durante gkectl upgrade admin, il controllo preflight dell'archiviazione per la migrazione CSI verifica che gli oggetti StorageClass non abbiano parametri che vengono ignorati dopo la migrazione CSI. Ad esempio, se esiste un oggetto StorageClass con il parametro diskformat, gkectl upgrade admin segnala l'oggetto StorageClass e segnala un errore nella convalida preflight. I cluster di amministrazione creati in GKE su VMware 1.10 e prima hanno un oggetto StorageClass con diskformat: thin, che non supererà la convalida, ma questo oggetto StorageClass funziona ancora correttamente dopo la migrazione CSI. Questi errori dovrebbero essere interpretati come avvisi.

    Per ulteriori informazioni, consulta la sezione relativa al parametro StorageClass in Migrazione di volumi vSphere In-Tree al plug-in vSphere Container Storage.


    Soluzione alternativa:

    Dopo aver confermato che nel cluster è presente un valore StorageClass con parametri ignorati dopo l'esecuzione della migrazione CSI gkectl upgrade admin con il flag --skip-validation-cluster-health.
    Storage 1,15, 1,16

    I volumi vSphere in-tree migrati utilizzando il file system di Windows non possono essere utilizzati con il driver CSI vSphere

    In determinate condizioni, i dischi possono essere collegati in sola lettura ai nodi Windows. Di conseguenza, il volume corrispondente viene letto in sola lettura all'interno di un pod. Questo problema è più probabile che si verifichi quando un nuovo insieme di nodi sostituisce un vecchio insieme di nodi (ad esempio, upgrade del cluster o aggiornamento del pool di nodi). I carichi di lavoro stateful che in precedenza funzionavano correttamente potrebbero non essere in grado di scrivere nei volumi sul nuovo set di nodi.


    Soluzione alternativa:

    1. Recupera l'UID del pod che non è in grado di scrivere nel suo volume: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Utilizza l'oggetto PersistentVolumeClaim per ottenere il nome del PersistentVolume: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Determina il nome del nodo su cui è in esecuzione il pod: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Ottieni l'accesso da PowerShell al nodo tramite SSH o l'interfaccia web vSphere.
    5. Imposta le variabili di ambiente: 
      PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. Identifica il numero del disco per il disco associato all'oggetto PersistentVolume: 
      PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
    7. Verifica che il disco sia readonly: 
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      Il risultato dovrebbe essere True.
    8. Imposta readonly su false. 
      PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Elimina il pod in modo che venga riavviato: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. Il pod deve essere pianificato sullo stesso nodo. Tuttavia, nel caso in cui il pod venga pianificato su un nuovo nodo, potrebbe essere necessario ripetere i passaggi precedenti sul nuovo nodo.

    Upgrade e aggiornamenti 1,12, 1.13.0-1.13.7, 1.14.0-1.14.4

    vsphere-csi-secret non viene aggiornato dopo il giorno gkectl update credentials vsphere --admin-cluster

    Se aggiorni le credenziali vSphere per un cluster di amministrazione dopo aver aggiornato le credenziali del cluster, potresti trovare vsphere-csi-secret nello spazio dei nomi kube-system nel cluster di amministrazione che continua a utilizzare la credenziale precedente.


    Soluzione alternativa:

    1. Recupera il nome del secret vsphere-csi-secret: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Aggiorna i dati del secret vsphere-csi-secret che hai ottenuto dal passaggio precedente: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
  "{\"data\":{\"config\":\"$( \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
      | base64 -d \
      | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
      | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
      | base64 -w 0 \
    )\"}}"
    3. Riavvia vsphere-csi-controller: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. Puoi monitorare lo stato dell'implementazione con: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
      Al termine dell'implementazione del deployment, il controller dovrebbe utilizzare la versione aggiornata (vsphere-csi-secret).
    Upgrade e aggiornamenti 1,10, 1,11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    audit-proxy arresto anomalo durante l'abilitazione di Cloud Audit Logs con gkectl update cluster

    audit-proxy potrebbe avere un arresto anomalo in loop a causa dello spazio --cluster-name vuoto. Questo comportamento è causato da un bug nella logica di aggiornamento, in cui il nome del cluster non viene propagato al manifest di pod / container audit-proxy.


    Soluzione alternativa:

    Per un cluster utente v2 del piano di controllo con enableControlplaneV2: true, connettiti alla macchina del piano di controllo dell'utente utilizzando SSH e aggiorna /etc/kubernetes/manifests/audit-proxy.yaml con --cluster_name=USER_CLUSTER_NAME.

    Per un cluster utente v1 del piano di controllo, modifica il container audit-proxy nello statefulset kube-apiserver per aggiungere --cluster_name=USER_CLUSTER_NAME:

    kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
    Upgrade e aggiornamenti 1,11, 1,12, 1,13,0-1,13,5, 1,14,0-1,14,1

    Un ulteriore deployment del piano di controllo subito dopo gkectl upgrade cluster

    Subito dopo il giorno gkectl upgrade cluster, è possibile che venga eseguito nuovamente il deployment dei pod del piano di controllo. Lo stato del cluster da gkectl list clusters cambia da RUNNING a RECONCILING. Le richieste al cluster utente potrebbero scadere.

    Questo comportamento è dovuto alla rotazione del certificato del piano di controllo che avviene automaticamente dopo il giorno gkectl upgrade cluster.

    Questo problema si verifica solo nei cluster utente che NON utilizzano il piano di controllo v2.


    Soluzione alternativa:

    Attendi che lo stato del cluster torni di nuovo a RUNNING in gkectl list clusters oppure esegui l'upgrade alle versioni con la correzione: 1.13.6 e versioni successive, 1.14.2 e versioni successive o 1.15 e versioni successive.
    Upgrade e aggiornamenti 1.12.7

    La release non valida 1.12.7-gke.19 è stata rimossa

    GKE su VMware 1.12.7-gke.19 è una release non valida e non dovresti utilizzarla. Gli artefatti sono stati rimossi dal bucket Cloud Storage.

    Soluzione alternativa:

    Utilizza invece la release 1.12.7-gke.20.
    Upgrade e aggiornamenti 1.12.0 e versioni successive, 1.13.0-1.13.7, 1.14.0-1.14.3

    gke-connect-agent continua a utilizzare l'immagine precedente dopo l'aggiornamento delle credenziali del registro

    Se aggiorni la credenziale di registro utilizzando uno dei seguenti metodi:

    • gkectl update credentials componentaccess se non utilizzi il registro privato
    • gkectl update credentials privateregistry se utilizzi il registro privato

    potresti notare che gke-connect-agent continua a utilizzare l'immagine precedente oppure i pod gke-connect-agent non possono essere estratti a causa di ImagePullBackOff.

    Questo problema verrà risolto nelle release 1.13.8, 1.14.4 e successive di GKE su VMware.


    Soluzione alternativa:

    Opzione 1. Esegui di nuovo il deployment di gke-connect-agent manualmente:

    1. Elimina lo spazio dei nomi gke-connect: 
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. Esegui di nuovo il deployment di gke-connect-agent con la chiave dell'account di servizio del registro originale (non è necessario aggiornare la chiave):

      Per il cluster di amministrazione: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
      Per il cluster utente: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

    Opzione 2: puoi modificare manualmente i dati del secret di pull dell'immagine regcred utilizzato dal deployment di gke-connect-agent:

    kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

    Opzione 3: puoi aggiungere il secret di pull dell'immagine predefinito per il tuo cluster nel deployment gke-connect-agent in questo modo:

    1. Copia il secret predefinito nello spazio dei nomi gke-connect: 
      kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
    2. Ottieni il nome del deployment gke-connect-agent: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Aggiungi il secret predefinito al deployment gke-connect-agent: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
    Installazione 1,13, 1,14

    Errore durante il controllo manuale della configurazione del bilanciamento del carico

    Quando convalidi la configurazione prima di creare un cluster con il bilanciatore del carico manuale eseguendo gkectl check-config, il comando avrà esito negativo e restituirà i seguenti messaggi di errore.

     - Validation Category: Manual LB    Running validation check for "Network 
configuration"...panic: runtime error: invalid memory address or nil pointer 
dereference

    Soluzione alternativa:

    Opzione 1: è possibile utilizzare le versioni patch 1.13.7 e 1.14.4 che includeranno la correzione.

    Opzione 2: puoi anche eseguire lo stesso comando per convalidare la configurazione, ma ignorare la convalida del bilanciatore del carico.

    gkectl check-config --skip-validation-load-balancer
    Operazione 1,0, 1,1, 1,2, 1,3, 1,4, 1,5, 1,6, 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13 e 1,14

    CANNOT TRANSLATE

    I cluster che eseguono etcd versione 3.4.13 o precedenti potrebbero riscontrare problemi di chiusura dell'attività e di monitoraggio delle risorse non operative, che possono causare i seguenti problemi:

    • La pianificazione dei pod è interrotta
    • Impossibile registrare i nodi
    • kubelet non osserva le modifiche ai pod

    Questi problemi possono rendere il cluster non funzionante.

    Questo problema è stato risolto nelle release 1.12.7, 1.13.6, 1.14.3 e successive di GKE su VMware. Queste release più recenti utilizzano etcd la versione 3.4.21. Tutte le versioni precedenti di GKE su VMware sono interessate da questo problema.

    Soluzione

    Se non puoi eseguire l'upgrade immediatamente, puoi ridurre il rischio di errore del cluster riducendo il numero di nodi nel cluster. Rimuovi i nodi fino a quando la metrica etcd_network_client_grpc_sent_bytes_total non è inferiore a 300 MBps.

    Per visualizzare questa metrica in Metrics Explorer:

    1. Vai a Metrics Explorer nella console Google Cloud:

      Vai a Metrics Explorer

    2. Seleziona la scheda Configurazione.
    3. Espandi Seleziona una metrica, inserisci Kubernetes Container nella barra dei filtri, poi utilizza i sottomenu per selezionare la metrica:
      1. Nel menu Risorse attive, seleziona Container Kubernetes.
      2. Nel menu Categorie di metriche attive, seleziona Anthos.
      3. Nel menu Metriche attive, seleziona etcd_network_client_grpc_sent_bytes_total.
      4. Fai clic su Applica.
    Upgrade e aggiornamenti 1,10, 1,11, 1,12, 1,13 e 1,14

    GKE Identity Service può causare latenze del piano di controllo

    Durante i riavvii o gli upgrade dei cluster, GKE Identity Service può sovraccaricarsi di traffico composto da token JWT scaduti inoltrati da kube-apiserver a GKE Identity Service tramite il webhook di autenticazione. Anche se GKE Identity Service non esegue un arresto anomalo in loop, non risponde e smette di gestire ulteriori richieste. Questo problema in ultima analisi porta a latenze più elevate del piano di controllo.

    Questo problema è stato risolto nelle seguenti release di GKE su VMware:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    Per capire se questo problema ti riguarda, segui questi passaggi:

    1. Verifica se l'endpoint di GKE Identity Service può essere raggiunto esternamente: 
      curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

      Sostituisci CLUSTER_ENDPOINT con il VIP del piano di controllo e la porta del bilanciatore del carico del piano di controllo per il cluster (ad esempio, 172.16.20.50:443).

      Se questo problema riguarda questo problema, il comando restituisce un codice di stato 400. Se la richiesta scade, riavvia il pod ais ed esegui nuovamente il comando curl per vedere se il problema si risolve. Se ricevi un codice di stato di 000, il problema è stato risolto e il gioco è fatto. Se visualizzi ancora un codice di stato 400, il server HTTP di GKE Identity Service non viene avviato. In questo caso, continua.

    2. Controlla i log di GKE Identity Service e kube-apiserver:
      1. Controlla il log di GKE Identity Service: 
        kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

        Se il log contiene una voce simile alla seguente, significa che il problema ti riguarda:

        I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
      2. Controlla i log kube-apiserver per i tuoi cluster:

        Nei comandi seguenti, KUBE_APISERVER_POD è il nome del pod kube-apiserver nel cluster specificato.

        Cluster di amministrazione:

        kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n kube-system KUBE_APISERVER_POD kube-apiserver

        Cluster utente:

        kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

        Se i log kube-apiserver contengono voci come la seguente, questo problema ti riguarda:

        E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"

    Soluzione

    Se non puoi eseguire subito l'upgrade dei cluster per ottenere la correzione, puoi identificare e riavviare i pod in questione come soluzione alternativa:

    1. Aumenta il livello di dettaglio del servizio di identità di GKE a 9: 
      kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG
    2. Controlla il log di GKE Identity Service per verificare se il contesto del token non è valido: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Per ottenere il payload del token associato a ogni contesto del token non valido, analizza ogni secret dell'account di servizio correlato con il seguente comando: 
      kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. Per decodificare il token e visualizzare il nome del pod di origine e lo spazio dei nomi, copia il token nel debugger all'indirizzo jwt.io.
    5. Riavvia i pod identificati dai token.
    Operazione 1,8, 1,9, 1,10

    Il problema relativo all'aumento dell'utilizzo della memoria dei pod di manutenzione etcd

    Sono interessati i pod di manutenzione etcd che utilizzano l'immagine etcddefrag:gke_master_etcddefrag_20210211.00_p0. Il container "etcddefrag" apre una nuova connessione al server etcd durante ogni ciclo di defrag e le connessioni precedenti non vengono pulite.


    Soluzione alternativa:

    Opzione 1: esegui l'upgrade alla versione più recente della patch da 1.8 a 1.11 che contiene la correzione.

    Opzione 2: se utilizzi una versione della patch precedente alla 1.9.6 e alla 1.10.3, devi fare lo scale down del pod etcd-maintenance per il cluster di amministrazione e utente:

    kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Operazione 1,9; 1,10; 1,11; 1,12; 1,13

    Non ha eseguito i controlli di integrità dei pod del piano di controllo del cluster utente

    Sia il controller di integrità del cluster sia il comando gkectl diagnose cluster eseguono una serie di controlli di integrità, inclusi quelli dei pod negli spazi dei nomi. Tuttavia, iniziano a saltare per errore i pod del piano di controllo dell'utente. Se utilizzi la modalità del piano di controllo v2, questa operazione non influirà sul cluster.


    Soluzione alternativa:

    Questa operazione non influirà sulla gestione dei carichi di lavoro o dei cluster. Se vuoi verificare l'integrità dei pod del piano di controllo, puoi eseguire i comandi seguenti:

    kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Upgrade e aggiornamenti 1.6 e versioni successive, 1.7 e

    Gli upgrade dei cluster di amministrazione 1.6 e 1.7 potrebbero essere interessati dal reindirizzamento k8s.gcr.io -> registry.k8s.io

    Kubernetes reindirizza il traffico da k8s.gcr.io a registry.k8s.io il 20/03/2023. In GKE su VMware 1.6.x e 1.7.x, gli upgrade del cluster di amministrazione utilizzano l'immagine container k8s.gcr.io/pause:3.2. Se utilizzi un proxy per la workstation di amministrazione e il proxy non consente registry.k8s.io e l'immagine container k8s.gcr.io/pause:3.2 non viene memorizzata nella cache localmente, gli upgrade del cluster di amministrazione non riusciranno durante il pull dell'immagine container.


    Soluzione alternativa:

    Aggiungi registry.k8s.io alla lista consentita del proxy per la tua workstation di amministrazione.
    Networking 1,10, 1,11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Errore di convalida Seesaw durante la creazione del bilanciatore del carico

    gkectl create loadbalancer non va a buon fine e viene visualizzato il seguente messaggio di errore:

    - Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host

    Ciò è dovuto al file del gruppo di altalena già esistente. Inoltre, il controllo preflight cerca di convalidare un bilanciatore del carico di altalena inesistente.

    Soluzione alternativa:

    Rimuovi il file del gruppo di alta visibilità esistente per questo cluster. Il nome del file è seesaw-for-gke-admin.yaml per il cluster di amministrazione e seesaw-for-{CLUSTER_NAME}.yaml per un cluster utente.
    Networking 1,14

    Timeout dell'applicazione causati da errori di inserimento della tabella Conntrack

    GKE su VMware versione 1.14 è soggetto a errori di inserimento della tabella di monitoraggio delle connessioni di Netfilter (conntrack) quando si utilizzano immagini del sistema operativo Ubuntu o COS. Gli errori di inserimento causano 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 nelle versioni successive che limitano gli inserimento delle tabelle in base alla lunghezza della catena.

    Per verificare se questo problema ti riguarda, puoi controllare le statistiche di sistema per il monitoraggio delle connessioni nel kernel su ciascun nodo utilizzando il comando seguente:

    sudo conntrack -S

    La risposta sarà 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, sei interessato da questo problema.

    Soluzione

    La mitigazione a breve termine prevede l'aumento delle dimensioni della tabella di hash netfiler (nf_conntrack_buckets) e della tabella di monitoraggio delle connessioni netfilter (nf_conntrack_max). Utilizza i seguenti comandi su ciascun nodo 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 la nuova dimensione in byte. Il valore predefinito per le dimensioni della tabella è 262144. Ti suggeriamo di impostare un valore pari a 65.536 volte il numero di core sul nodo. Ad esempio, se il nodo ha otto core, imposta la dimensione della tabella su 524288.
    Networking 1.13.0-1.13.2

    calico-typha o anetd-operator crash loop sui nodi Windows con Controlplane v2

    Con Controlplane v2 o un nuovo modello di installazione, è possibile che calico-typha o anetd-operator vengano pianificati per i nodi Windows e generare un loop di arresto anomalo.

    Il motivo è che i due deployment tollerano tutte le incompatibilità, inclusa quella dei nodi Windows.


    Soluzione alternativa:

    Esegui l'upgrade alla versione 1.13.3+ o esegui questi comandi per modificare il deployment "calico-typha" o "anetd-operator":

        # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG

    Rimuovi il seguente spec.template.spec.tolerations:

        - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists

    E aggiungi la seguente tolleranza:

        - key: node-role.kubernetes.io/master
      operator: Exists
    Configurazione 1.14.0-1.14.2

    Impossibile caricare il file delle credenziali del registro privato del cluster utente

    Potresti non riuscire a creare un cluster utente se specifichi la sezione privateRegistry con la credenziale fileRef. Il preflight potrebbe non riuscire con il seguente messaggio: 

    [FAILURE] Docker registry access: Failed to login.


    Soluzione alternativa:

    • Se non intendevi specificare il campo o vuoi utilizzare la stessa credenziale del registro privato del cluster di amministrazione, puoi semplicemente rimuovere o commentare la sezione privateRegistry nel file di configurazione del cluster utente.
    • Se vuoi utilizzare una credenziale del registro privato specifica per il cluster utente, puoi specificare temporaneamente la sezione privateRegistry in questo modo: 
      privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
      (NOTA: questa è una soluzione solo temporaneamente e questi campi sono già deprecati, ti consigliamo di utilizzare il file delle credenziali quando esegui l'upgrade alla versione 1.14.3 e successive).

    Suite operativa Più di 1,10

    Anthos Service Mesh e altri mesh di servizi non compatibili con Dataplane v2

    Dataplane V2 si occupa del bilanciamento del carico e crea un socket del kernel invece di un DNAT basato su pacchetti. Ciò significa che Anthos Service Mesh non può eseguire l'ispezione dei pacchetti poiché il pod viene ignorato e non utilizza mai IPTables.

    Questo si manifesta in modalità kube-proxy free per perdita di connettività o routing del traffico non corretto per i servizi con Anthos Service Mesh, in quanto il file collaterale non può eseguire l'ispezione dei pacchetti.

    Questo problema è presente in tutte le versioni di GKE su Bare Metal 1.10, tuttavia alcune versioni più recenti di 1.10 (1.10.2+) hanno una soluzione alternativa.


    Soluzione alternativa:

    Esegui l'upgrade alla versione 1.11 per una compatibilità completa oppure, se esegui la versione 1.10.2 o successiva, esegui:

        kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

    Aggiungi bpf-lb-sock-hostns-only: true al file configmap, quindi riavvia il daemonset anetd:

          kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

    Storage 1,12+, 1,13.3

    kube-controller-manager potrebbe scollegare forzatamente i volumi permanenti dopo 6 minuti

    kube-controller-manager potrebbe timeout quando scolleghi PV/PVC dopo 6 minuti e, con forza, lo scolleghi. I log dettagliati di kube-controller-manager mostrano eventi simili ai seguenti:

    $ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

    Per verificare il problema, accedi al nodo ed esegui questi comandi:

    # See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    Nel log kubelet vengono visualizzati errori come i seguenti:

    Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

    Soluzione alternativa:

    Connettiti al nodo interessato utilizzando SSH e riavvialo.
    Upgrade e aggiornamenti 1,12+, 1,13+, 1,14+

    L'upgrade del cluster si blocca se viene utilizzato un driver CSI di terze parti

    Potresti non riuscire a eseguire l'upgrade di un cluster se utilizzi un driver CSI di terze parti. Il comando gkectl cluster diagnose potrebbe restituire il seguente errore: 

    "virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"


    Soluzione alternativa:

    Esegui l'upgrade utilizzando l'opzione --skip-validation-all.
    Operazione 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

    gkectl repair admin-master crea la VM master dell'amministratore senza eseguire l'upgrade della versione hardware della VM

    Il nodo master di amministrazione creato tramite gkectl repair admin-master potrebbe utilizzare una versione hardware della VM inferiore al previsto. Quando si verifica il problema, visualizzerai l'errore nel report gkectl diagnose cluster. 

    CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.


    Soluzione alternativa:

    Arresta il nodo master di amministrazione, segui https://kb.vmware.com/s/article/1003746 per eseguire l'upgrade del nodo alla versione prevista descritta nel messaggio di errore, quindi avvia il nodo.
    Sistema operativo 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+

    La VM rilascia il lease DHCP all'arresto/riavvio in modo imprevisto, il che potrebbe comportare modifiche all'IP

    In systemd v244, systemd-networkd presenta una modifica del comportamento predefinito sulla configurazione di KeepConfiguration. Prima di questa modifica, le VM non inviavano un messaggio di rilascio del lease DHCP al server DHCP all'arresto o al riavvio. Dopo la modifica, le VM inviano un messaggio di questo tipo e restituiscono gli IP al server DHCP. Di conseguenza, l'IP rilasciato potrebbe essere riallocato a una VM diversa e/o alla VM potrebbe essere assegnato un IP diverso, causando conflitti IP (a livello di Kubernetes, non a livello di vSphere) e/o una modifica dell'IP sulle VM, che può interrompere i cluster in vari modi.

    Ad esempio, potresti notare i seguenti sintomi.

    • La UI di vCenter mostra che nessuna VM utilizza lo stesso IP, ma kubectl get nodes -o wide restituisce nodi con IP duplicati. 
      NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
    • I nuovi nodi non si avviano a causa dell'errore calico-node 
      2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start


    Soluzione alternativa:

    Esegui il deployment del seguente DaemonSet sul cluster per ripristinare la modifica del comportamento predefinito di systemd-networkd. Le VM che eseguono questo DaemonSet non rilasceranno gli IP al server DHCP all'arresto/riavvio. Gli IP verranno liberati automaticamente dal server DHCP alla scadenza dei lease. 

          apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule

    Funzionamento, upgrade e aggiornamenti 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

    Chiave dell'account di servizio di accesso ai componenti cancellata dopo l'upgrade del cluster di amministrazione dalla versione 1.11.x

    Questo problema interessa solo i cluster di amministrazione di cui è stato eseguito l'upgrade dalla versione 1.11.x e non interessa i cluster di amministrazione appena creati dopo la versione 1.12.

    Dopo aver eseguito l'upgrade di un cluster 1.11.x a 1.12.x, il campo component-access-sa-key nel secret admin-cluster-creds verrà cancellato e sarà vuoto. Per verificarlo, esegui il comando seguente: 

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
    Se l'output è vuoto, significa che la chiave è stata cancellata.

    Dopo l'eliminazione della chiave dell'account di servizio di accesso ai componenti, l'installazione di nuovi cluster utente o l'upgrade dei cluster utente esistenti non riuscirà. Di seguito sono riportati alcuni messaggi di errore che potresti ricevere:

    • Errore preflight di convalida lenta con messaggio di errore: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • Preparazione tramite gkectl prepare non riuscita con messaggio di errore: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Se esegui l'upgrade di un cluster utente 1.13 utilizzando la console Google Cloud o gcloud CLI, quando esegui gkectl update admin --enable-preview-user-cluster-central-upgrade per eseguire il deployment del controller della piattaforma di upgrade, il comando non riesce e viene visualizzato il messaggio "failed to download bundle to disk: dialing: unexpected end of JSON input" (puoi visualizzare questo messaggio nel campo status nell'output di kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).


    Soluzione alternativa :

    Aggiungi manualmente la chiave dell'account di servizio di accesso ai componenti nel secret eseguendo questo comando: 

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
    Operazione 1.13.0 e versioni successive, 1.14.0 e successive

    Il gestore della scalabilità automatica dei cluster non funziona quando è abilitato Controlplane V2

    Per i cluster utente creati con Controlplane V2 o un nuovo modello di installazione, i pool di nodi per cui è abilitata la scalabilità automatica utilizzano sempre il proprio autoscaling.minReplicas in user-cluster.yaml. Il log del pod del gestore della scalabilità automatica del cluster mostra anche che lo stato non è integro. 

      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
    Il pod del gestore della scalabilità automatica dei cluster può essere trovato eseguendo questi comandi. 
      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


    Soluzione alternativa :

    Disabilita la scalabilità automatica in tutti i pool di nodi con "gkectl update cluster" fino all'upgrade a una versione con la correzione
    Installazione 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    Il CIDR non è consentito nel file dei blocchi IP

    Quando gli utenti utilizzano il CIDR nel file dei blocchi IP, la convalida della configurazione non andrà a buon fine con il seguente errore: 

    - Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30


    Soluzione alternativa :

    Includi singoli IP nel file dei blocchi IP fino a quando non esegui l'upgrade a una versione con la correzione: 1.12.5, 1.13.4, 1.14.1+.
    Upgrade e aggiornamenti 1.14.0-1.14.1

    L'aggiornamento del tipo di immagine del sistema operativo in admin-cluster.yaml non attende la nuova creazione delle macchine del piano di controllo degli utenti

    Quando aggiorna il tipo di immagine del sistema operativo del piano di controllo in admin-cluster.yaml e se il cluster utente corrispondente è stato creato tramite Controlplane V2, le macchine del piano di controllo utente potrebbero non completare la ricreazione al termine del comando gkectl.


    Soluzione alternativa :

    Al termine dell'aggiornamento, continua ad attendere che anche le macchine del piano di controllo dell'utente terminino la nuova creazione monitorando i tipi di immagine del sistema operativo dei nodi utilizzando kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Ad esempio, se esegui l'aggiornamento da Ubuntu a COS, dobbiamo attendere che tutte le macchine del piano di controllo passino completamente da Ubuntu a COS anche dopo il completamento del comando di aggiornamento.

    Operazione 1,10; 1,11; 1,12; 1,13; 1,14,0

    Errori di creazione o eliminazione dei pod a causa di un problema con il token di autenticazione dell'account di servizio CNI di Calico

    Un problema con Calico in GKE su VMware 1.14.0 determina la mancata riuscita della creazione e dell'eliminazione dei pod e restituisce il seguente messaggio di errore nell'output di kubectl describe pods:

      error getting ClusterInformation: connection is unauthorized: Unauthorized

    Questo problema si osserva solo 24 ore dopo la creazione o l'upgrade del cluster alla versione 1.14 utilizzando Calico.

    I cluster di amministrazione utilizzano sempre Calico, mentre per il cluster utente è presente un campo di configurazione "enableDataPlaneV2" in user-cluster.yaml. Se questo campo è impostato su "false" o non è specificato, significa che stai utilizzando Calico nel cluster utente.

    Il container install-cni dei nodi crea un kubeconfig con un token valido per 24 ore. Questo token deve essere rinnovato periodicamente dal pod calico-node. Il pod calico-node non è in grado di rinnovare il token perché non ha accesso alla directory che contiene il file kubeconfig sul nodo.


    Soluzione alternativa:

    Questo problema è stato risolto in GKE su VMware versione 1.14.1. Esegui l'upgrade a questa versione o a una versione successiva.

    Se non puoi eseguire subito l'upgrade, applica la seguente patch al DaemonSet calico-node nel cluster di amministrazione e utente:

      kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
    Sostituisci quanto segue:
    • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
    • USER_CLUSTER_CONFIG_FILE: il percorso del file di configurazione del cluster utente.
    Installazione 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    La convalida del blocco IP non va a buon fine quando si utilizza il CIDR

    La creazione del cluster non riesce nonostante l'utente abbia la configurazione corretta. L'utente vede che la creazione non riesce perché il cluster non ha un numero sufficiente di IP.


    Soluzione alternativa :

    Suddividi i CIDR in diversi blocchi CIDR più piccoli, ad esempio 10.0.0.0/30 diventa 10.0.0.0/31, 10.0.0.2/31. Finché esistono CIDR N+1, dove N è il numero di nodi nel cluster, questo dovrebbe essere sufficiente.

    Operazioni, upgrade e aggiornamenti 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

    Il backup del cluster di amministrazione non include la configurazione e le chiavi di crittografia dei secret sempre attivi

    Se la funzionalità di crittografia dei secret sempre attivi è abilitata insieme al backup del cluster, il backup del cluster di amministrazione non include le chiavi di crittografia e la configurazione richieste dalla funzionalità di crittografia dei secret sempre attiva. Di conseguenza, la riparazione del master di amministrazione con questo backup utilizzando gkectl repair admin-master --restore-from-backup causa il seguente errore: 

    Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

    Operazioni, upgrade e aggiornamenti Più di 1,10

    Ricreare la VM master dell'amministratore con un nuovo disco di avvio (ad es. gkectl repair admin-master) non riuscirà se la funzionalità di crittografia dei secret sempre attivi viene abilitata utilizzando il comando "gkectl update".

    Se la funzionalità di crittografia dei secret sempre attivi non viene abilitata al momento della creazione del cluster, ma viene abilitata in un secondo momento utilizzando l'operazione gkectl update, gkectl repair admin-master non sarà in grado di riparare il nodo del piano di controllo del cluster di amministrazione. Ti consigliamo di abilitare la funzionalità di crittografia dei secret sempre attiva al momento della creazione del cluster. Al momento non esistono misure di mitigazione.

    Upgrade e aggiornamenti 1,1

    L'upgrade del primo cluster utente da 1.9 a 1.10 ricrea i nodi in altri cluster utente

    L'upgrade del primo cluster utente dalla versione 1.9 alla versione 1.10 potrebbe ricreare nodi in altri cluster utente nello stesso cluster di amministrazione. La nuova creazione avviene in modo continuativo.

    disk_label è stato rimosso da MachineTemplate.spec.template.spec.providerSpec.machineVariables e questo ha attivato inaspettatamente un aggiornamento di tutti i dispositivi MachineDeployment.


    Soluzione alternativa:
    Upgrade e aggiornamenti 1.10.0

    Docker si riavvia frequentemente dopo l'upgrade del cluster

    L'upgrade del cluster utente alla versione 1.10.0 potrebbe causare il riavvio frequente di docker.

    Puoi rilevare questo problema eseguendo kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG

    Una condizione del nodo mostrerà se il docker si riavvia frequentemente. Ecco un output di esempio:

    Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

    Per comprendere la causa principale, devi accedere tramite SSH al nodo che presenta il sintomo ed eseguire comandi come sudo journalctl --utc -u docker o sudo journalctl -x.


    Soluzione alternativa:
    Upgrade e aggiornamenti 1,11, 1,12

    I componenti di GMP di cui è stato eseguito il deployment autonomo non vengono conservati dopo l'upgrade alla versione 1.12

    Se utilizzi GKE su VMware versione precedente alla 1.12 e hai configurato manualmente i componenti Prometheus gestiti da Google (GMP) nello spazio dei nomi gmp-system per il tuo cluster, i componenti non vengono conservati quando esegui l'upgrade alla versione 1.12.x.

    A partire dalla versione 1.12, i componenti di GMP nello spazio dei nomi gmp-system e nei CRD sono gestiti dall'oggetto stackdriver, con il flag enableGMPForApplications impostato su false per impostazione predefinita. Se esegui manualmente il deployment dei componenti di GMP nello spazio dei nomi prima di eseguire l'upgrade alla versione 1.12, le risorse verranno eliminate da stackdriver.


    Soluzione alternativa:
    Operazione 1,11, 1,12, 1,13,0 - 1,13,1

    Oggetti ClusterAPI mancanti nello snapshot del cluster system scenario

    Nello scenario system, lo snapshot del cluster non include risorse nello spazio dei nomi default.

    Tuttavia, alcune risorse Kubernetes, come gli oggetti API cluster che si trovano in questo spazio dei nomi, contengono informazioni di debug utili. Lo snapshot del cluster deve includerle.


    Soluzione alternativa:

    Puoi eseguire manualmente i comandi riportati di seguito per raccogliere le informazioni di debug.

    export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
    dove:

    USER_CLUSTER_KUBECONFIG è il file kubeconfig del cluster utente.
    Upgrade e aggiornamenti 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    Eliminazione del cluster utente bloccata allo svuotamento dei nodi per la configurazione di vSAN

    Durante l'eliminazione, l'aggiornamento o l'upgrade di un cluster utente, lo svuotamento dei nodi potrebbe bloccarsi nei seguenti scenari:

    • Il cluster di amministrazione utilizza il driver CSI vSphere su vSAN dalla versione 1.12.x e
    • Non sono presenti oggetti PVC/PV creati dai plug-in vSphere in-tree nel cluster di amministrazione e utente.

    Per identificare il sintomo, esegui il comando seguente:

    kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

    Ecco un esempio di messaggio di errore del comando precedente:

    E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

    kubevols è la directory predefinita per il driver in-tree vSphere. Se non vengono creati oggetti PVC/PV, potresti riscontrare un bug per cui lo svuotamento dei nodi rimane bloccato nella ricerca di kubevols, poiché l'implementazione attuale presuppone che kubevols esista sempre.


    Soluzione alternativa:

    Crea la directory kubevols nel datastore in cui viene creato il nodo. Questo valore viene definito nel campo vCenter.datastore nei file user-cluster.yaml o admin-cluster.yaml.
    Configurazione 1,7; 1,8; 1,9; 1,10; 1,11; 1,12; 1,13; 1,14

    Cluster Autoscaler clusterrolebinding e clusterrole vengono eliminati dopo l'eliminazione di un cluster utente.

    Al momento dell'eliminazione del cluster utente, vengono eliminati anche i clusterrole e clusterrolebinding corrispondenti per il gestore della scalabilità automatica del cluster. Questo influisce su tutti gli altri cluster utente nello stesso cluster di amministrazione con il gestore della scalabilità automatica dei cluster abilitato. Questo perché lo stesso clusterrole e clusterrolebinding vengono utilizzati per tutti i pod del gestore della scalabilità automatica dei cluster all'interno dello stesso cluster di amministrazione.

    I sintomi sono i seguenti:

    • cluster-autoscaler log
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
      dove ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del cluster di amministrazione. Ecco un esempio di messaggi di errore che potresti visualizzare: 
      2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    Soluzione alternativa:

    Configurazione 1,7; 1,8; 1,9; 1,10; 1,11; 1,12; 1,13

    Il cluster di amministrazione cluster-health-controller e vsphere-metrics-exporter non funzionano dopo l'eliminazione del cluster utente

    Al momento dell'eliminazione del cluster utente, viene eliminato anche il clusterrole corrispondente, il che comporta il mancato funzionamento della riparazione automatica e dell'esportazione delle metriche vSphere

    I sintomi sono i seguenti:

    • cluster-health-controller log
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
      dove ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del cluster di amministrazione. Ecco un esempio di messaggi di errore che potresti visualizzare: 
      error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
    • vsphere-metrics-exporter log
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
      dove ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del cluster di amministrazione. Ecco un esempio di messaggi di errore che potresti visualizzare: 
      vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

    Soluzione alternativa:

    Configurazione 1.12.1-1.12.3, 1.13.0-1.13.2

    gkectl check-config non riesce a convalidare l'immagine del sistema operativo

    Un problema noto che potrebbe non riuscire a eseguire gkectl check-config senza eseguire gkectl prepare. Non è chiaro perché ti consigliamo di eseguire il comando prima di eseguire gkectl prepare.

    Il sintomo è che il comando gkectl check-config avrà esito negativo con il seguente messaggio di errore:

    Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

    Soluzione alternativa:

    Opzione 1: esegui gkectl prepare per caricare le immagini del sistema operativo mancanti.

    Opzione 2: utilizza gkectl check-config --skip-validation-os-images per saltare la convalida delle immagini del sistema operativo.
    Upgrade e aggiornamenti 1,11, 1,12, 1,13

    gkectl update admin/cluster non riesce ad aggiornare i gruppi anti affinità

    Un problema noto che potrebbe non riuscire a risolvere gkectl update admin/cluster durante l'aggiornamento di anti affinity groups.

    Il sintomo è che il comando gkectl update avrà esito negativo con il seguente messaggio di errore:

    Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

    Soluzione alternativa:
    Installazione, upgrade e aggiornamenti 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

    I nodi non vengono registrati se il nome host configurato contiene un punto

    La registrazione dei nodi non va a buon fine durante la creazione, l'upgrade, l'aggiornamento e la riparazione automatica dei nodi del cluster, quando ipMode.type è static e il nome host configurato nel file di blocco IP contiene uno o più periodi. In questo caso, le richieste di firma del certificato (CSR) per un nodo non vengono approvate automaticamente.

    Per visualizzare i CSR in attesa per un nodo, esegui questo comando:

    kubectl get csr -A -o wide

    Controlla i seguenti log per i messaggi di errore:

    • Visualizza i log nel cluster di amministrazione per il container clusterapi-controller-manager nel pod clusterapi-controllers: 
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    • Per visualizzare gli stessi log nel cluster utente, esegui questo comando: 
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      dove:
      • ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del cluster di amministrazione.
      • USER_CLUSTER_NAME è il nome del cluster utente.
      Ecco un esempio di messaggi di errore che potresti visualizzare: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Visualizza i log kubelet sul nodo problematico: 
      journalctl --u kubelet
      Ecco un esempio di messaggi di errore che potresti visualizzare: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Se specifichi un nome di dominio nel campo del nome host di un file di blocco IP, eventuali caratteri successivi al primo punto verranno ignorati. Ad esempio, se specifichi il nome host come bob-vm-1.bank.plc, il nome host e il nome del nodo della VM verranno impostati su bob-vm-1.

    Quando la verifica dell'ID nodo è abilitata, l'approvatore CSR confronta il nome del nodo con il nome host nelle specifiche della macchina e non riesce a riconciliare il nome. L'approvatore rifiuta la richiesta di firma del certificato e il nodo non riesce a eseguire il bootstrap.


    Soluzione alternativa:

    Cluster utente

    Disabilita la verifica dell'ID nodo completando i seguenti passaggi:

    1. Aggiungi i seguenti campi nel file di configurazione del cluster utente: 
      disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Salva il file e aggiorna il cluster utente eseguendo questo comando: 
      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
      Sostituisci quanto segue:
      • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
      • USER_CLUSTER_CONFIG_FILE: il percorso del file di configurazione del cluster utente.

    Cluster di amministrazione

    1. Apri la risorsa personalizzata OnPremAdminCluster per la modifica: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. Aggiungi la seguente annotazione alla risorsa personalizzata: 
      features.onprem.cluster.gke.io/disable-node-id-verification: enabled
    3. Modifica il manifest kube-controller-manager nel piano di controllo del cluster di amministrazione:
      1. Accedi tramite SSH al nodo del piano di controllo del cluster di amministrazione.
      2. Apri il manifest kube-controller-manager per modificare: 
        sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. Trova l'elenco di controllers: 
        --controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. Aggiorna questa sezione come mostrato di seguito: 
        --controllers=*,bootstrapsigner,tokencleaner
    4. Apri il controller API Deployment Cluster per la modifica: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
    5. Modifica i valori di node-id-verification-enabled e node-id-verification-csr-signing-enabled in false: 
      --node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
    Installazione, upgrade e aggiornamenti 1.11.0-1.11.4

    Errore di avvio della macchina del piano di controllo amministratore causato da un bundle di certificati del registro privato

    La creazione/l'upgrade del cluster di amministrazione è bloccato definitivamente nel log seguente e alla fine si verifica il timeout:

    Waiting for Machine gke-admin-master-xxxx to become ready...

    Il log del controller API del cluster nello snapshot del cluster esterno include il seguente log:

    Invalid value 'XXXX' specified for property startup-data

    Ecco un esempio di percorso file per il log del controller API Cluster:

    kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
    VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.
    
    
    Workaround:
    
    
    Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.
    
    
    Or upgrade to a version with the fix when available.
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayNodes marked unhealthy from concurrent status update conflict

    In networkgatewaygroups.status.nodes, some nodes switch between NotHealthy and Up.

    Logs for the ang-daemon Pod running on that node reveal repeated errors: 

    2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}

    Lo stato NotHealthy impedisce al controller di assegnare IP mobili aggiuntivi al nodo. Ciò può comportare un carico maggiore su altri nodi o una mancanza di ridondanza per l'alta disponibilità.

    L'attività Dataplane non subirà alcuna modifica.

    La contesa sull'oggetto networkgatewaygroup causa la mancata riuscita di alcuni aggiornamenti di stato a causa di un errore nella gestione dei nuovi tentativi. Se troppi aggiornamenti di stato non riescono, ang-controller-manager vede il nodo che supera il limite di tempo dell'heartbeat e contrassegna il nodo NotHealthy.

    L'errore nella gestione dei nuovi tentativi è stato risolto nelle versioni successive.


    Soluzione alternativa:

    Esegui l'upgrade a una versione corretta, se disponibile.
    Upgrade e aggiornamenti 1.12.0-1.12.2, 1.13.0

    La condizione di gara blocca l'eliminazione degli oggetti della macchina durante l'aggiornamento o l'upgrade

    Un problema noto che potrebbe causare il blocco dell'upgrade o dell'aggiornamento del cluster in attesa dell'eliminazione dell'oggetto della macchina precedente. Il motivo è che non è possibile rimuovere il finaler dall'oggetto della macchina. Questo influisce su qualsiasi operazione di aggiornamento in sequenza per i pool di nodi.

    Il sintomo è che il comando gkectl scade con il seguente messaggio di errore:

    E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    Nei log dei pod clusterapi-controller, gli errori sono riportati di seguito:

    $ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

    L'errore si ripete sulla stessa macchina per diversi minuti per esecuzioni riuscite anche senza questo problema, per la maggior parte delle volte può essere risolto rapidamente, ma in alcuni rari casi può rimanere bloccato su questa gara per diverse ore.

    Il problema è che la VM sottostante è già stata eliminata in vCenter, ma non è possibile rimuovere l'oggetto macchina corrispondente, che è bloccato alla rimozione del finalizzatore a causa di aggiornamenti molto frequenti da parte di altri controller. Ciò può causare il timeout del comando gkectl, ma il controller continua a riconciliare il cluster in modo che il processo di upgrade o aggiornamento alla fine venga completato.


    Soluzione alternativa:

    Abbiamo preparato diverse opzioni di mitigazione per questo problema, che dipendono dal tuo ambiente e dai requisiti.

    • Opzione 1: attendi che l'upgrade venga completato in modo autonomo.

      In base all'analisi e alla riproduzione nel tuo ambiente, l'upgrade può terminare da solo senza alcun intervento manuale. L'avvertenza di questa opzione è che non è chiaro quanto tempo sarà necessario per completare la rimozione del finalizzatore per ogni oggetto macchina. Può avvenire immediatamente, se ne hai la fortuna, oppure potrebbe durare diverse ore se la riconciliazione del controller del set di macchine è troppo rapida e il controller della macchina non ha mai la possibilità di rimuovere il finalizzatore tra una riconciliazione e l'altra.

      La buona notizia è che questa opzione non richiede alcuna azione da parte tua e i carichi di lavoro non verranno interrotti. Il completamento dell'upgrade richiede solo più tempo.
    • Opzione 2: applica l'annotazione di riparazione automatica a tutti gli oggetti delle macchine precedenti.

      Il controller del set di macchine filtrerà le macchine con l'annotazione di riparazione automatica e il timestamp di eliminazione diverso da zero e non continuerà a inviare chiamate di eliminazione su quelle macchine. Ciò può contribuire a evitare la race condition.

      Lo svantaggio è che i pod sulle macchine verranno eliminati direttamente anziché rimossi, il che significa che non rispetta la configurazione PDB e questo potrebbe causare tempi di inattività per i carichi di lavoro.

      Il comando per ottenere i nomi di tutte le macchine: 
      kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
      Il comando per applicare l'annotazione di riparazione automatica per ogni macchina: 
      kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

    Se riscontri questo problema e dopo molto tempo l'upgrade o l'aggiornamento non riesce ancora a essere completato, contatta il nostro team di assistenza per scoprire le misure correttive.
    Installazione, upgrade e aggiornamenti 1,10,2, 1,11, 1,12, 1,13

    gkectl prepara l'errore preflight di convalida dell'immagine del sistema operativo

    Comando gkectl prepare non riuscito con:

    - Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

    I controlli preflight di gkectl prepare includevano una convalida errata.


    Soluzione alternativa:

    Esegui lo stesso comando con un flag aggiuntivo --skip-validation-os-images.
    Installazione 1,7; 1,8; 1,9; 1,10; 1,11; 1,12; 1,13

    L'URL vCenter con prefisso https:// o http:// può causare un errore di avvio del cluster

    Creazione del cluster di amministrazione non riuscita con:

    Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

    L'URL viene utilizzato come parte di una chiave secret, che non supporta "/" o ":".


    Soluzione alternativa:

    Rimuovi il prefisso https:// o http:// dal campo vCenter.Address nel file YAML della configurazione del cluster di amministrazione o del cluster utente.
    Installazione, upgrade e aggiornamenti 1,10; 1,11; 1,12; 1,13

    Panico per gkectl prepare il giorno util.CheckFileExists

    gkectl prepare può causare il panico con la seguente analisi dello stack:

    panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

    Il problema è che gkectl prepare ha creato la directory dei certificati del registro privato con un'autorizzazione errata.


    Soluzione alternativa:

    Per risolvere il problema, esegui i comandi seguenti sulla workstation di amministrazione:

    sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
    Upgrade e aggiornamenti 1,10; 1,11; 1,12; 1,13

    gkectl repair admin-master e l'upgrade dell'amministratore ripristinabile non funzionano insieme

    Dopo un tentativo di upgrade del cluster di amministrazione non riuscito, non eseguire gkectl repair admin-master. Ciò potrebbe causare i successivi tentativi di upgrade dell'amministratore con problemi come errore di accensione del master dell'amministratore o inaccessibile della VM.


    Soluzione alternativa:

    Se hai già riscontrato questo scenario di errore, contatta l'assistenza.
    Upgrade e aggiornamenti 1,10, 1,11

    Se ripreso l'upgrade del cluster di amministrazione, potrebbe mancare il modello di VM del piano di controllo di amministrazione

    Se la macchina del piano di controllo di amministrazione non viene ricreata dopo un tentativo di upgrade del cluster di amministrazione ripristinato, il modello di VM del piano di controllo di amministrazione viene eliminato. Il modello di VM del piano di controllo amministrativo è il modello del master dell'amministratore, utilizzato per recuperare la macchina del piano di controllo con gkectl repair admin-master.


    Soluzione alternativa:

    Il modello di VM del piano di controllo di amministrazione verrà rigenerato durante il successivo upgrade del cluster di amministrazione.
    Sistema operativo 1,12, 1,13

    cgroup v2 potrebbe influire sui carichi di lavoro

    Nella versione 1.12.0, cgroup v2 (unificato) è abilitato per impostazione predefinita per i nodi Container Optimized OS (COS). Ciò potrebbe causare instabilità per i carichi di lavoro in un cluster COS.


    Soluzione alternativa:

    Siamo tornati a cgroup v1 (ibrido) nella versione 1.12.1. Se utilizzi nodi COS, ti consigliamo di eseguire l'upgrade alla versione 1.12.1 non appena viene rilasciata.
    Identità 1,10; 1,11; 1,12; 1,13

    Risorsa personalizzata ClientConfig

    gkectl update annulla tutte le modifiche manuali apportate alla risorsa personalizzata ClientConfig.


    Soluzione alternativa:

    Ti consigliamo vivamente di eseguire il backup della risorsa ClientConfig dopo ogni modifica manuale.
    Installazione 1,10; 1,11; 1,12; 1,13

    Convalida di gkectl check-config non riuscita: impossibile trovare le partizioni BIG-IP F5

    La convalida non va a buon fine perché le partizioni BIG-IP F5 non sono state trovate, anche se esistono.

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


    Soluzione alternativa:

    Prova a eseguire di nuovo gkectl check-config.
    Installazione 1,12

    Installazione del cluster utente non riuscita a causa di un problema di elezione leader di cert-manager/ca-injector

    Potresti notare un errore di installazione dovuto a 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 alternativa:
    VMware 1,10; 1,11; 1,12; 1,13

    Riavvio o upgrade di vCenter per versioni precedenti a 7.0U2

    Se vCenter, per versioni precedenti a 7.0U2, viene riavviato, dopo un upgrade o in altro modo, il nome di rete nelle informazioni sulla VM da vCenter non è corretto e la macchina si trova in uno stato Unavailable. Alla fine, i nodi vengono riparati automaticamente per crearne di nuovi.

    Bug govmomi correlato.


    Soluzione alternativa:

    Questa soluzione alternativa è fornita dal supporto VMware:

    1. Il problema è stato risolto nelle versioni 7.0U2 e successive di vCenter.
    2. Per le versioni precedenti, fai clic con il tasto destro del mouse sull'host e seleziona Connessione > Disconnetti. Poi, esegui di nuovo la connessione per forzare un aggiornamento del gruppo di porte della VM.
    Sistema operativo 1,10; 1,11; 1,12; 1,13

    Connessione SSH chiusa dall'host remoto

    Per GKE su VMware versione 1.7.2 e successive, le immagini del sistema operativo Ubuntu sono protette con CIS L1 Server Benchmark.

    Per soddisfare la regola CIS "5.2.16 Assicurati che sia configurato un intervallo di timeout di inattività SSH", /etc/ssh/sshd_config ha le seguenti impostazioni:

    ClientAliveInterval 300
ClientAliveCountMax 0

    Lo scopo di queste impostazioni è terminare una sessione client dopo 5 minuti di inattività. Tuttavia, il valore ClientAliveCountMax 0 causa comportamenti imprevisti. Quando utilizzi la sessione SSH sulla workstation di amministrazione o su un nodo cluster, la connessione SSH potrebbe essere disconnessa anche il client SSH non è inattivo, ad esempio quando si esegue un comando che richiede molto tempo, e il comando potrebbe essere interrotto con il seguente messaggio:

    Connection to [IP] closed by remote host.
Connection to [IP] closed.

    Soluzione alternativa:

    Puoi:

    • Utilizza nohup per evitare che il comando venga terminato al momento della disconnessione SSH, 
      nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
    • Aggiorna sshd_config per utilizzare un valore ClientAliveCountMax diverso da zero. La regola CIS consiglia di utilizzare un valore inferiore a 3: 
      sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

    Assicurati di riconnettere la sessione SSH.
    Installazione 1,10; 1,11; 1,12; 1,13

    Installazione di cert-manager in conflitto

    Nelle release 1.13, monitoring-operator installerà cert-manager nello spazio dei nomi cert-manager. Se per determinati motivi devi installare cert-manager, segui le istruzioni riportate di seguito per evitare conflitti:

    Devi applicare questa soluzione solo una volta per ogni cluster e le modifiche verranno conservate nell'upgrade del cluster.

    Nota: un sintomo comune dell'installazione di cert-manager è che la versione o l'immagine cert-manager (ad esempio v1.7.2) potrebbe tornare alla versione precedente. Questo problema è dovuto al tentativo di monitoring-operator di riconciliare cert-manager e al ripristino della versione durante la procedura.

    Soluzione alternativa:

    <pEvitare conflitti durante l'upgrade

    1. Disinstalla la tua versione di cert-manager. Se hai definito le tue risorse, ti consigliamo di eseguire il backup .
    2. Esegui l'upgrade.
    3. Segui le istruzioni riportate di seguito per ripristinare il tuo cert-manager.

    Ripristinare il proprio certificato nei cluster utente

    • Scala il deployment di monitoring-operator fino a 0: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Scala a 0 i deployment cert-manager gestiti da monitoring-operator: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0
    • Reinstalla la tua versione di cert-manager. Ripristina le risorse personalizzate, se disponibili.
    • Puoi saltare questo passaggio se utilizzi l' installazione predefinita di cert-manager upstream oppure se hai la certezza che cert-manager sia installato nello spazio dei nomi cert-manager. In caso contrario, copia il certificato metrics-ca cert-manager.io/v1 e le risorse dell'emittente metrics-pki.cluster.local da cert-manager allo spazio dei nomi delle risorse del cluster dell'account cert-manager installato. 
      relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

    Ripristinare un gestore dei certificati nei cluster di amministrazione

    In generale, non dovresti reinstallare cert-manager nei cluster di amministrazione perché i cluster di amministrazione eseguono solo i carichi di lavoro del piano di controllo GKE su VMware. Nei rari casi in cui devi installare anche cert-manager nei cluster di amministrazione, segui le istruzioni riportate di seguito per evitare conflitti. Tieni presente che, se sei un cliente Apigee e hai bisogno solo di cert-manager per Apigee, non è necessario eseguire i comandi del cluster di amministrazione.

    • Scala il deployment di monitoring-operator fino a 0. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Scala a 0 i deployment cert-manager gestiti da monitoring-operator. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     -n cert-manager scale deployment cert-manager-cainjector \
     --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0
    • Reinstalla la tua versione di cert-manager. Ripristina le risorse personalizzate, se disponibili.
    • Puoi saltare questo passaggio se utilizzi l' installazione predefinita di cert-manager upstream oppure se hai la certezza che cert-manager sia installato nello spazio dei nomi cert-manager. In caso contrario, copia il certificato metrics-ca cert-manager.io/v1 e le risorse dell'emittente metrics-pki.cluster.local da cert-manager allo spazio dei nomi delle risorse del cluster dell'account cert-manager installato. 
      relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
    </p
    Sistema operativo 1,10; 1,11; 1,12; 1,13

    Falsi positivi nell'analisi delle vulnerabilità Docker, Containerd e Runc

    Docker, containerd e runc nelle immagini del sistema operativo Ubuntu fornite con GKE su VMware sono bloccati su versioni speciali mediante Ubuntu PPA. Questo garantisce che eventuali modifiche al runtime dei container vengano qualificate da GKE su VMware prima di ogni release.

    Tuttavia, le versioni speciali sono sconosciute a Ubuntu CVE Tracker, che viene utilizzato come feed di vulnerabilità da vari strumenti di analisi CVE. Pertanto, visualizzerai falsi positivi nei risultati dell'analisi delle vulnerabilità di Docker, containerd e runc.

    Ad esempio, potresti vedere i seguenti falsi positivi dai risultati della scansione CVE. Queste CVE sono già state corrette nelle versioni patch più recenti di GKE su VMware.

    Fai riferimento alle note di rilascio] per eventuali correzioni di CVE.


    Soluzione alternativa:

    Canonical è a conoscenza di questo problema e la correzione viene monitorata all'indirizzo https://github.com/canonical/sec-cvescan/issue/73.
    Upgrade e aggiornamenti 1,10; 1,11; 1,12; 1,13

    La connessione di rete tra il cluster di amministrazione e il cluster utente potrebbe non essere disponibile per un breve periodo di tempo durante l'upgrade dei cluster non ad alta disponibilità

    Se esegui l'upgrade di cluster non ad alta disponibilità dalla versione 1.9 alla versione 1.10, potresti notare che kubectl exec, kubectl log e il webhook per i cluster utente potrebbero non essere disponibili per un breve periodo di tempo. Il tempo di inattività può essere fino a un minuto. Questo accade perché la richiesta in entrata (kubectl exec, kubectl log e webhook) viene gestita da kube-apiserver per il cluster utente. L'utente kube-apiserver è uno Statefulset. In un cluster non ad alta disponibilità esiste una sola replica per lo Statefulset. Di conseguenza, durante l'upgrade è possibile che il vecchio kube-apiserver non sia disponibile, mentre il nuovo kube-apiserver non è ancora pronto.


    Soluzione alternativa:

    Questo tempo di inattività si verifica solo durante il processo di upgrade. Se vuoi un tempo di inattività più breve durante l'upgrade, ti consigliamo di passare ai cluster ad alta disponibilità.
    Installazione, upgrade e aggiornamenti 1,10; 1,11; 1,12; 1,13

    Controllo dell'idoneità della konnectivity non riuscito nella diagnosi del cluster ad alta disponibilità dopo la creazione o l'upgrade del cluster

    Se stai creando o eseguendo l'upgrade di un cluster ad alta disponibilità e noti che il controllo di idoneità della connettività non è riuscito nella diagnostica del cluster, nella maggior parte dei casi questo non influirà sulla funzionalità di GKE su VMware (kubectl exec, kubectl log e webhook). Questo accade perché a volte una o due delle repliche di connettività potrebbero non essere pronte per un determinato periodo di tempo a causa di networking instabile o altri problemi.


    Soluzione alternativa:

    La connettività si riprenderà da sola. Attendi da 30 minuti a 1 ora ed esegui di nuovo la diagnostica del cluster.
    Sistema operativo 1,7; 1,8; 1,9; 1,10; 1,11

    /etc/cron.daily/aide problema di picco di CPU e memoria

    A partire da GKE su VMware versione 1.7.2, le immagini del sistema operativo Ubuntu sono protette con il benchmark CIS L1 Server.

    Di conseguenza, lo script cron /etc/cron.daily/aide è stato installato in modo da pianificare un controllo aide per garantire che venga seguita la regola del server CIS L1 "1.4.2 Assicurati che l'integrità del file system venga controllata regolarmente".

    Il cron job viene eseguito ogni giorno alle 06:25 UTC. A seconda del numero di file nel file system, potresti riscontrare picchi di utilizzo di CPU e memoria in questo periodo causati da questo processo aide.


    Soluzione alternativa:

    Se i picchi interessano il tuo carico di lavoro, puoi disabilitare il cron job giornaliero:

    sudo chmod -x /etc/cron.daily/aide
    Networking 1,10; 1,11; 1,12; 1,13

    I bilanciatori del carico e le regole firewall distribuiti stateful NSX-T interagiscono in modo imprevedibile

    Durante il deployment di GKE su VMware versione 1.9 o successiva, se il deployment include il bilanciatore del carico in bundle Seesaw in un ambiente che utilizza le regole firewall distribuiti stateful NSX-T, stackdriver-operator potrebbe non creare gke-metrics-agent-conf ConfigMap e causare un loop di arresto anomalo per gke-connect-agent pod.

    Il problema di fondo è che le regole firewall distribuite stateful NSX-T terminano la connessione da un client al server API del cluster utente tramite il bilanciatore del carico Seesaw, perché Seesaw utilizza flussi di connessione asimmetrici. I problemi di integrazione con le regole firewall distribuiti NSX-T interessano tutte le release di GKE su VMware che utilizzano Seesaw. Potresti riscontrare problemi di connessione simili nelle tue applicazioni quando creano oggetti Kubernetes di grandi dimensioni le cui dimensioni superano i 32.000.


    Soluzione alternativa:

    Segui queste istruzioni per disabilitare le regole firewall distribuite NSX-T o per utilizzare le regole firewall distribuite stateless per le VM Seesaw.

    Se i tuoi cluster utilizzano un bilanciatore del carico manuale, segui queste istruzioni per configurare il bilanciatore del carico in modo da reimpostare le connessioni client quando rileva un errore del nodo di backend. Senza questa configurazione, i client del server API Kubernetes potrebbero smettere di rispondere per diversi minuti quando un'istanza del server si arresta.
    Logging e monitoraggio 1,10; 1,11; 1,12; 1,13; 1,14; 1,15

    Fatturazione del monitoraggio imprevista

    Per le versioni da 1.10 a 1.15 di GKE su VMware, alcuni clienti hanno riscontrato una fatturazione inaspettatamente elevata per Metrics volume nella pagina Fatturazione. Questo problema ti riguarda solo quando si applicano tutte le seguenti circostanze:

    • Il logging e il monitoraggio delle applicazioni sono abilitati (enableStackdriverForApplications=true)
    • I pod di applicazione hanno l'annotazione prometheus.io/scrap=true. (L'installazione di Anthos Service Mesh può anche aggiungere questa annotazione).

    Per verificare se questo problema ti riguarda, elenca le metriche definite dall'utente. Se noti la fatturazione per le metriche indesiderate con prefisso nome external.googleapis.com/prometheus e vedi anche enableStackdriverForApplications impostato su true nella risposta di kubectl -n kube-system get stackdriver stackdriver -o yaml, questo problema si applica al tuo caso.


    Soluzione

    Se questo problema ti interessa, ti consigliamo di eseguire l'upgrade dei cluster alla versione 1.12 o successiva, interrompere l'utilizzo del flag enableStackdriverForApplications e passare alla nuova soluzione di monitoraggio delle applicazioni managed-service-for-prometheus che non si basa più sull'annotazione prometheus.io/scrap=true. Con la nuova soluzione, puoi anche controllare la raccolta di log e metriche separatamente per le tue applicazioni, con i flag enableCloudLoggingForApplications e enableGMPForApplications, rispettivamente.

    Per non usare più il flag enableStackdriverForApplications, apri l'oggetto "stackdriver" per la modifica:

    kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver

    Rimuovi la riga enableStackdriverForApplications: true, salva e chiudi l'editor.

    Se non riesci ad abbandonare la raccolta delle metriche basate su annotazioni, segui questi passaggi:

    1. Trova i pod e i servizi di origine che dispongono delle metriche fatturate indesiderate. 
      kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Rimuovi l'annotazione prometheus.io/scrap=true dal pod o dal servizio. Se l'annotazione viene aggiunta da Anthos Service Mesh, valuta la possibilità di configurare Anthos Service Mesh senza l'opzione Prometheus o di disattivare la funzionalità di unione delle metriche Istio.
    Installazione 1,11, 1,12, 1,13

    Il programma di installazione non riesce durante la creazione del disco dati vSphere

    Il programma di installazione di GKE su VMware potrebbe non riuscire se i ruoli personalizzati sono associati al livello di autorizzazione errato.

    Quando l'associazione dei ruoli non è corretta, si blocca la creazione di un disco dati vSphere con govc e il disco viene creato con una dimensione pari a 0. Per risolvere il problema, devi associare il ruolo personalizzato a livello di vSphere vCenter (root).


    Soluzione alternativa:

    Se vuoi associare il ruolo personalizzato a livello di DC (o inferiore a quello principale), devi associare anche il ruolo di sola lettura all'utente a livello di vCenter principale.

    Per maggiori informazioni sulla creazione dei ruoli, consulta la pagina sui privilegi dell'account utente vCenter.
    Logging e monitoraggio 1,9.0-1.9.4, 1.10.0-1.10.1

    Traffico di rete elevato verso monitoring.googleapis.com

    Potresti notare un traffico di rete elevato verso monitoring.googleapis.com, anche in un nuovo cluster che non ha carichi di lavoro utente.

    Questo problema riguarda la versione 1.10.0-1.10.1 e la versione 1.9.0-1.9.4. Questo problema è stato risolto nelle versioni 1.10.2 e 1.9.5.


    Soluzione alternativa:
    Logging e monitoraggio 1,10, 1,11

    gke-metrics-agent presenta errori CrashLoopBackOff frequenti

    Per GKE su VMware versione 1.10 e successive, il DaemonSet "gke-metrics-agent" presenta frequenti errori CrashLoopBackOff quando "enableStackdriverForApplications" è impostato su "true" nell'oggetto "stackdriver".


    Soluzione alternativa:

    Per limitare questo problema, disabilita la raccolta delle metriche dell'applicazione eseguendo i comandi seguenti. Questi comandi non disabiliteranno la raccolta dei log delle applicazioni.

    1. Per impedire il ripristino delle seguenti modifiche, fare lo scale down stackdriver-operator: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.
    2. Apri il ConfigMap di gke-metrics-agent-conf per la modifica: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. In services.pipelines, commenta l'intera sezione metrics/app-metrics: 
      services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Chiudi la sessione di modifica.
    5. Riavvia il DaemonSet gke-metrics-agent: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    Logging e monitoraggio 1,11, 1,12, 1,13

    Sostituisci le metriche deprecate nella dashboard

    Se nelle dashboard OOTB vengono utilizzate metriche deprecate, vedrai alcuni grafici vuoti. Per trovare le metriche deprecate nelle dashboard di Monitoring, esegui questi comandi:

    gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

    È necessario eseguire la migrazione delle seguenti metriche deprecate alle sostituzioni.

    DeprecataSostituzione
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    Soluzione alternativa:

    Per sostituire le metriche deprecate

    1. Elimina "Stato del nodo on-prem di GKE" nella dashboard di Google Cloud Monitoring. Reinstalla "Stato del nodo on-prem di GKE" seguendo queste istruzioni.
    2. Elimina "Utilizzo nodo on-prem di GKE" nella dashboard di Google Cloud Monitoring. Reinstalla "Utilizzo nodo on-prem di GKE" seguendo queste istruzioni.
    3. Elimina "GKE delle VM vSphere on-prem" nella dashboard di Google Cloud Monitoring. Reinstalla "GKE on-prem vSphere vm health" seguendo queste istruzioni.

      4. Questo ritiro è dovuto all'upgrade dell'agente kube-state-metrics dalla v1.9 alla v2.4, obbligatorio per Kubernetes 1.22. Puoi sostituire tutte le metriche kube-state-metrics deprecate, che hanno il prefisso kube_, nelle dashboard o nei criteri di avviso personalizzati.
    Logging e monitoraggio 1,10; 1,11; 1,12; 1,13

    Dati delle metriche sconosciuti in Cloud Monitoring

    Per GKE su VMware versione 1.10 e successive, i dati per i cluster in Cloud Monitoring potrebbero contenere voci di riepilogo irrilevanti come le seguenti:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Altri tipi di metriche che potrebbero avere metriche di riepilogo non pertinenti includono

    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Sebbene queste metriche di tipo di riepilogo siano nell'elenco delle metriche, al momento non sono supportate da gke-metrics-agent.
    Logging e monitoraggio 1,10; 1,11; 1,12; 1,13

    Metriche mancanti su alcuni nodi

    Potresti notare che le seguenti metriche non sono presenti su alcuni nodi, ma non in tutti:

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Soluzione alternativa:

    Per risolvere il problema, prova a svolgere la seguente procedura come soluzione alternativa. Per [version 1.9.5+, 1.10.2+, 1.11.0]: aumenta la CPU per gke-metrics-agent seguendo i passaggi da 1 a 4

    1. Apri la risorsa stackdriver per la modifica: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Per aumentare la richiesta di CPU per gke-metrics-agent da 10m a 50m, il limite di CPU da 100m a 200m aggiungi la seguente sezione resourceAttrOverride al manifest stackdriver: 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
      La risorsa modificata dovrebbe essere simile alla seguente: 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Salva le modifiche e chiudi l'editor di testo.
    4. Per verificare che le modifiche siano state applicate, esegui questo comando: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
      Il comando trova cpu: 50m se le modifiche sono state applicate.
    Logging e monitoraggio 1.11.0-1.11.2, 1.12.0

    Metriche dello scheduler e del controller-gestore mancanti nel cluster di amministrazione

    Se il cluster di amministrazione è interessato da questo problema, le metriche dello scheduler e del controller-gestore mancano. Ad esempio, queste due metriche mancano

    # scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Soluzione alternativa:

    Esegui l'upgrade alla versione v1.11.3+, v1.12.1+ o v1.13+.
    1.11.0-1.11.2, 1.12.0

    Metriche dello scheduler e del controller-gestore mancanti nel cluster utente

    Se il cluster utente è interessato da questo problema, le metriche dello scheduler e del controller-gestore mancano. Ad esempio, queste due metriche sono mancanti:

    # scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Soluzione alternativa:

    Questo problema è stato risolto in GKE su VMware versione 1.13.0 e successive. Esegui l'upgrade del cluster a una versione con la correzione.
    Installazione, upgrade e aggiornamenti 1,10; 1,11; 1,12; 1,13

    Mancata registrazione del cluster di amministrazione durante la creazione

    Se crei un cluster di amministrazione per la versione 1.9.x o 1.10.0 e se durante la creazione il cluster di amministrazione non riesce a registrarsi con la specifica gkeConnect fornita, verrà visualizzato il seguente errore.

    Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

    Potrai comunque utilizzare questo cluster di amministrazione, ma se in un secondo momento provi a eseguire l'upgrade del cluster di amministrazione alla versione 1.10.y, visualizzerai il seguente errore.

    failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""

    Soluzione alternativa:
    Identità 1,10; 1,11; 1,12; 1,13

    L'utilizzo del servizio GKE Identity può causare il riavvio imprevedibile dell'agente Connect

    Se utilizzi la funzionalità GKE Identity Service per gestire GKE Identity Service ClientConfig, l' agente Connect potrebbe riavviarsi inaspettatamente.


    Soluzione alternativa:

    Se hai riscontrato questo problema con un cluster esistente, puoi eseguire una di queste operazioni:

    • Disabilita GKE Identity Service. Se disabiliti GKE Identity Service, questo non rimuoverà il programma binario GKE Identity Service di cui è stato eseguito il deployment né rimuoverà il ClientConfig di GKE Identity Service. Per disabilitare GKE Identity Service, esegui questo comando: 
      gcloud container fleet identity-service disable \
    --project PROJECT_ID
      Sostituisci PROJECT_ID con l'ID del progetto host del parco risorse del cluster.
    • Aggiorna il cluster alla versione 1.9.3 o successive oppure alla versione 1.10.1 o successive, in modo da eseguire l'upgrade della versione dell'agente Connect.
    Networking 1,10; 1,11; 1,12; 1,13

    Cisco ACI non funziona con Direct Server Return (DSR)

    Seesaw viene eseguito in modalità DSR e per impostazione predefinita non funziona in Cisco ACI a causa dell'apprendimento dell'IP del piano dati.


    Soluzione alternativa:

    Una possibile soluzione alternativa è disabilitare l'apprendimento IP aggiungendo l'indirizzo IP di Seesaw come IP virtuale L4-L7 in Cisco Application Policy Infrastructure Controller (APIC).

    Per configurare l'opzione IP virtuale L4-L7, vai a Tenant > Profili di applicazione > EPG delle applicazioni o uSeg EPG. Se l'apprendimento IP non viene disabilitato, gli endpoint IP verranno flapping tra diverse località nell'infrastruttura dell'API Cisco.
    VMware 1,10; 1,11; 1,12; 1,13

    Problemi con l'aggiornamento 3 di vSphere 7.0

    VMWare ha identificato di recente problemi critici con le seguenti release di vSphere 7.0 Update 3:

    • vSphere ESXi 7.0 Aggiornamento 3 (build 18644231)
    • vSphere ESXi 7.0 Aggiornamento 3a (build 18825058)
    • Aggiornamento di vSphere ESXi 7.0 3b (build 18905247)
    • Aggiornamento di vSphere vCenter 7.0 3b (build 18901211)

    Soluzione alternativa:

    Da allora VMWare ha rimosso queste release. Devi eseguire l'upgrade dei ESXi e dei server vCenter a una versione più recente.
    Sistema operativo 1,10; 1,11; 1,12; 1,13

    Impossibile montare il volume emptyDir come exec nel pod in esecuzione sui nodi COS

    Per i pod in esecuzione su nodi che utilizzano immagini COS (Container-Optimized OS), non puoi montare il volume emptyDir come exec. Si monta come noexec e riceverai il seguente errore: exec user process caused: permission denied. Ad esempio, vedrai questo messaggio di errore se esegui il deployment del seguente pod di test:

    apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

    Inoltre, nel pod di test, se esegui mount | grep test-volume, mostrerà l'opzione noexec:

    /dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

    Soluzione alternativa:
    Upgrade e aggiornamenti 1,10; 1,11; 1,12; 1,13

    L'aggiornamento della replica del pool di nodi cluster non funziona dopo che la scalabilità automatica è stata disabilitata nel pool di nodi

    Le repliche dei pool di nodi non vengono aggiornate dopo che la scalabilità automatica è stata abilitata e disabilitata su un pool di nodi.


    Soluzione alternativa:

    Rimozione delle annotazioni cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size e cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size dal deployment delle macchine del pool di nodi corrispondente.
    Logging e monitoraggio 1,11, 1,12, 1,13

    Le dashboard di monitoraggio di Windows mostrano i dati di cluster Linux

    A partire dalla versione 1.11, nelle dashboard di monitoraggio pronte all'uso, la dashboard dello stato dei pod di Windows e la dashboard dello stato dei nodi di Windows mostrano anche i dati dei cluster Linux. Questo perché le metriche relative a nodi e pod Windows sono esposte anche nei cluster Linux.
    Logging e monitoraggio 1,10, 1,11, 1,12

    stackdriver-log-forwarder in CrashLoopBackOff costante

    Per GKE su VMware versioni 1.10, 1.11 e 1.12, stackdriver-log-forwarder DaemonSet potrebbe presentare errori CrashLoopBackOff in caso di log con buffer non funzionanti sul disco.


    Soluzione alternativa:

    Per mitigare questo problema, dovremo ripulire i log nel buffer sul nodo.

    1. Per evitare comportamenti imprevisti, fare lo scale down stackdriver-log-forwarder: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.
    2. Esegui il deployment del DaemonSet di pulizia per eliminare i blocchi danneggiati: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Per assicurarti che il DaemonSet di pulizia abbia pulito tutti i blocchi, puoi eseguire i comandi seguenti. L'output dei due comandi dovrebbe essere uguale al numero di nodo nel cluster: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. Elimina il DaemonSet di pulizia: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. Riprendi stackdriver-log-forwarder: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Logging e monitoraggio 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16

    stackdriver-log-forwarder non invia log a Cloud Logging

    Se non vedi i log in Cloud Logging dai tuoi cluster e noti il seguente errore nei tuoi log: 

    2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    È probabile che la velocità di input dei log superi il limite dell'agente Logging, per cui stackdriver-log-forwarder non invia log. Questo problema si verifica in tutte le versioni di GKE su VMware.

    Soluzione alternativa:

    Per limitare questo problema, devi aumentare il limite delle risorse per l'agente Logging.

    1. Apri la risorsa stackdriver per la modifica: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Per aumentare la richiesta di CPU per stackdriver-log-forwarder aggiungi la seguente sezione resourceAttrOverride al manifest stackdriver: 
      spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      La risorsa modificata dovrebbe essere simile alla seguente: 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Salva le modifiche e chiudi l'editor di testo.
    4. Per verificare che le modifiche siano state applicate, esegui questo comando: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
      Il comando trova cpu: 1200m se le modifiche sono state applicate.
    Sicurezza 1,13

    Il servizio kubelet sarà temporaneamente non disponibile dopo NodeReady

    c'è un breve periodo in cui il nodo è pronto, ma il certificato del server kubelet non è pronto. kubectl exec e kubectl logs non sono disponibili durante questa decina di secondi. Il motivo è che occorre del tempo prima che il nuovo approvatore dei certificati server veda gli IP validi aggiornati del nodo.

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

    L'upgrade parziale del cluster di amministrazione non blocca l'upgrade del cluster utente successivo

    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 va a buon fine con un problema di disallineamento delle versioni.


    Soluzione alternativa:

    Completa l'upgrade del cluster di amministrazione alla versione 1.11, quindi esegui l'upgrade del cluster utente alla versione 1.12.
    Storage 1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

    Datastore segnala erroneamente spazio libero insufficiente

    Comando gkectl diagnose cluster non riuscito con: 

    Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

    La convalida dello spazio libero del datastore non deve essere utilizzata per i pool di nodi cluster esistenti ed è stata aggiunta in gkectl diagnose cluster per errore.


    Soluzione alternativa:

    Puoi ignorare il messaggio di errore o saltare la convalida utilizzando --skip-validation-infra.
    Operazione, networking 1,11, 1.12.0-1.12.1

    Impossibile aggiungere un nuovo cluster utente quando il cluster di amministrazione utilizza il bilanciatore del carico MetalLB

    Potresti non essere in grado di aggiungere un nuovo cluster utente se il cluster di amministrazione è configurato con una configurazione del bilanciatore del carico MetalLB.

    Il processo di eliminazione del cluster utente potrebbe bloccarsi per qualche motivo, causando un'annullamento della convalida di MatalLB ConfigMap. Non sarà possibile aggiungere un nuovo cluster utente in questo stato.


    Soluzione alternativa:

    Puoi forzare l'eliminazione del cluster utente.
    Installazione, sistema operativo 1,10; 1,11; 1,12; 1,13

    Errore durante l'utilizzo di Container-Optimized OS (COS) per il cluster utente

    Se osImageType utilizza cos per il cluster di amministrazione e quando gkectl check-config viene eseguito dopo la creazione del cluster di amministrazione e prima della creazione del cluster utente, l'operazione non riuscirà su: 

    Failed to create the test VMs: VM failed to get IP addresses on the network.

    La VM di test creata per il cluster utente check-config per impostazione predefinita utilizza lo stesso osImageType del cluster di amministrazione e attualmente la VM di test non è ancora compatibile con COS.


    Soluzione alternativa:

    Per evitare il controllo preflight lento che crea la VM di test, utilizzando gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast.
    Logging e monitoraggio 1.12.0-1.12.1

    Grafana nel cluster di amministrazione non è in grado di raggiungere i cluster utente

    Questo problema riguarda i clienti che utilizzano Grafana nel cluster di amministrazione per monitorare i cluster utente in GKE su VMware versioni 1.12.0 e 1.12.1. deriva da una mancata corrispondenza tra i certificati client pushprox nei cluster utente e la lista consentita nel server pushprox nel cluster di amministrazione. Il sintomo è il client pushprox nei cluster utente che stampano log degli errori come il seguente:

    level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    Soluzione alternativa:
    Altro 1.11.3

    gkectl repair admin-master non fornisce il modello di VM da utilizzare per il ripristino

    Comando gkectl repair admin-master non riuscito con: 

    Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

    gkectl repair admin-master non è in grado di recuperare il modello di VM da utilizzare per la riparazione della VM del piano di controllo amministratore se il nome di questa VM termina con i caratteri t, m, p o l.


    Soluzione alternativa:

    Esegui nuovamente il comando con --skip-validation.
    Logging e monitoraggio 1,11; 1,12; 1,13; 1,14; 1,15; 1,16

    Errore di audit logging di Cloud a causa di autorizzazione negata

    Cloud Audit Logs richiede una configurazione di autorizzazioni speciali, che attualmente viene eseguita automaticamente solo per i cluster utente tramite GKE Hub. È consigliabile avere almeno un cluster utente che utilizza lo stesso ID progetto e lo stesso account di servizio con il cluster di amministrazione per Cloud Audit Logs, in modo che il cluster di amministrazione abbia l'autorizzazione richiesta.

    Tuttavia, nei casi in cui il cluster di amministrazione utilizza un ID progetto o un account di servizio diverso rispetto a qualsiasi cluster utente, gli audit log del cluster di amministrazione non verranno inseriti in Google Cloud. Il sintomo è una serie di errori Permission Denied nel pod audit-proxy nel cluster di amministrazione.

    Soluzione alternativa:
    Funzionamento, sicurezza 1,11

    Controllo dei certificati non riuscito da gkectl diagnose

    Se la tua stazione di lavoro non ha accesso ai nodi worker del cluster utente, si verificheranno i seguenti errori durante l'esecuzione di gkectl diagnose:

    Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Se la tua stazione di lavoro non ha accesso ai nodi worker del cluster di amministrazione o ai nodi worker del cluster di amministrazione, si verificheranno i seguenti errori durante l'esecuzione di gkectl diagnose:

    Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Soluzione alternativa:

    Se puoi ignorare questi messaggi,
    Sistema operativo 1,8; 1,9; 1,10; 1,11; 1,12; 1,13

    /var/log/audit/ sta occupando spazio su disco nelle VM

    /var/log/audit/ contiene log di controllo. Puoi controllare l'utilizzo del disco eseguendo sudo du -h -d 1 /var/log/audit.

    Alcuni comandi gkectl sulla workstation di amministrazione, ad esempio gkectl diagnose snapshot, contribuiscono all'utilizzo dello spazio su disco.

    A partire da GKE su VMware v1.8, l'immagine Ubuntu è protetta con il benchmark CIS Level 2. E una delle regole di conformità, "4.1.2.2 Assicurati che gli audit log non vengano eliminati automaticamente", garantisce che l'impostazione sottoposta ad audit max_log_file_action = keep_logs. In questo modo tutte le regole di controllo vengono conservate sul disco.


    Soluzione alternativa:
    Networking 1,10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayGroup IP mobile in conflitto con l'indirizzo del nodo

    Gli utenti non sono in grado di creare o aggiornare NetworkGatewayGroup oggetti a causa del seguente errore di convalida del webhook:

    [1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

    Nelle versioni interessate, il kubelet può associarsi erroneamente a un indirizzo IP mobile assegnato al nodo e segnalarlo come indirizzo del nodo in node.status.addresses. Il webhook di convalida controlla gli indirizzi IP mobili di NetworkGatewayGroup rispetto a tutti gli node.status.addresses nel cluster e lo considera come un conflitto.


    Soluzione alternativa:

    Nello stesso cluster in cui la creazione o l'aggiornamento degli oggetti NetworkGatewayGroup non riesce, disabilita temporaneamente il webhook di convalida ANG e invia la modifica:

    1. Salva la configurazione del webhook in modo che possa essere ripristinata alla fine: 
      kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. Modifica la configurazione del webhook: 
      kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Rimuovi l'elemento vnetworkgatewaygroup.kb.io dall'elenco delle configurazioni dei webhook e chiudilo per applicare le modifiche.
    4. Crea o modifica l'oggetto NetworkGatewayGroup.
    5. Applica di nuovo la configurazione del webhook originale: 
      kubectl -n kube-system apply -f webhook-config.yaml
    Installazione, upgrade e aggiornamenti 1.10.0-1.10.2

    Creazione o upgrade del timeout del cluster di amministrazione

    Durante un tentativo di upgrade del cluster di amministrazione, la VM del piano di controllo di amministrazione potrebbe bloccarsi durante la creazione. La VM del piano di controllo dell'amministratore entra in un ciclo di attesa infinito durante l'avvio e vedrai il seguente errore di loop infinito nel file /var/log/cloud-init-output.log:

    + echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    Il motivo è che quando GKE su VMware cerca di ottenere l'indirizzo IP del nodo nello script di avvio, utilizza grep -v ADMIN_CONTROL_PLANE_VIP per ignorare il VIP del piano di controllo del cluster di amministrazione, che può essere assegnato anche al NIC. Tuttavia, il comando ignora anche qualsiasi indirizzo IP che abbia un prefisso del VIP del piano di controllo, causando il blocco dello script di avvio.

    Ad esempio, supponiamo che il VIP del piano di controllo del cluster di amministrazione sia 192.168.1.25. Se l'indirizzo IP della VM del piano di controllo del cluster di amministrazione ha lo stesso prefisso, ad esempio 192.168.1.254, la VM del piano di controllo si blocca durante la creazione. Questo problema può essere attivato anche se l'indirizzo di broadcast ha lo stesso prefisso del VIP del piano di controllo, ad esempio 192.168.1.255.


    Soluzione alternativa:

    • Se il motivo del timeout della creazione del cluster di amministrazione è dovuto all'indirizzo IP della trasmissione, esegui questo comando sulla VM del piano di controllo del cluster di amministrazione:
      ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      Verrà creata una riga senza indirizzo di trasmissione e sbloccherà il processo di avvio. Dopo aver sbloccato lo script di avvio, rimuovi questa riga aggiunta eseguendo questo comando: 
      ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Tuttavia, se il motivo del timeout della creazione del cluster di amministrazione è dovuto all'indirizzo IP della VM del piano di controllo, non puoi sbloccare lo script di avvio. Passa a un indirizzo IP diverso e ricrea o esegui l'upgrade alla versione 1.10.3 o successive.
    Sistema operativo, upgrade e aggiornamenti 1.10.0-1.10.2

    Lo stato del cluster di amministrazione che utilizza l'immagine COS andrà perso in seguito all'upgrade del cluster di amministrazione o alla riparazione del master di amministrazione

    Quando si utilizza l'immagine COS, DataDisk non può essere montato correttamente nel nodo master del cluster di amministrazione. Inoltre, lo stato del cluster di amministrazione che utilizza l'immagine COS andrà perso in seguito all'upgrade del cluster di amministrazione o alla riparazione del master di amministrazione. (il cluster di amministrazione che utilizza l'immagine COS è una funzionalità di anteprima)


    Soluzione alternativa:

    Ricrea il cluster di amministrazione con osImageType impostato su ubuntu_containerd

    Dopo aver creato il cluster di amministrazione con osImageType impostato su cos, recupera la chiave SSH del cluster di amministrazione e SSH nel nodo master di amministrazione. df -h risultato contiene /dev/sdb1 98G 209M 93G 1% /opt/data. E lsblk risultato contiene -sdb1 8:17 0 100G 0 part /opt/data
    Sistema operativo 1,1

    ricerca DNS non riuscita sistemad-risolta in .local domini

    In GKE su VMware versione 1.10.0, per impostazione predefinita le risoluzioni dei nomi su Ubuntu vengono instradate all'ascolto locale con risoluzione di sistema su 127.0.0.53. Il motivo è che sull'immagine Ubuntu 20.04 utilizzata nella versione 1.10.0, /etc/resolv.conf è collegato tramite simboli a /run/systemd/resolve/stub-resolv.conf, che punta allo stub DNS localhost 127.0.0.53.

    Di conseguenza, la risoluzione dei nomi DNS localhost si rifiuta di controllare i server DNS upstream (specificati in /run/systemd/resolve/resolv.conf) per i nomi con un suffisso .local, a meno che non vengano specificati come domini di ricerca.

    Di conseguenza, le ricerche dei nomi .local non andranno a buon fine. Ad esempio, durante l'avvio del nodo, kubelet non riesce a eseguire il pull delle immagini da un registro privato con un suffisso .local. La specifica di un indirizzo vCenter con un suffisso .local non funzionerà su una workstation di amministrazione.


    Soluzione alternativa:

    Puoi evitare questo problema per i nodi cluster se specifichi il campo searchDomainsForDNS nel file di configurazione del cluster di amministrazione e nel file di configurazione del cluster utente per includere i domini.

    Al momento gkectl update non supporta ancora l'aggiornamento del campo searchDomainsForDNS.

    Di conseguenza, se non hai configurato questo campo prima della creazione del cluster, devi accedere tramite SSH ai nodi e ignorare lo stub locale risolto tramite sistema modificando il link simbolico di /etc/resolv.conf da /run/systemd/resolve/stub-resolv.conf (che contiene lo stub locale 127.0.0.53) a /run/systemd/resolve/resolv.conf (che rimanda all'effettivo DNS upstream):

    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    Per quanto riguarda la workstation di amministrazione, gkeadm non supporta la specifica dei domini di ricerca, quindi devi risolvere il problema con questo passaggio manuale.

    Questa soluzione non viene mantenuta durante le ricreazioni di VM. Devi applicare nuovamente questa soluzione alternativa ogni volta che vengono ricreate le VM.
    Installazione, sistema operativo 1,1

    L'IP del bridge Docker utilizza 172.17.0.1/16 anziché 169.254.123.1/24

    GKE su VMware specifica una subnet dedicata per l'indirizzo IP del bridge Docker che utilizza --bip=169.254.123.1/24, in modo da non prenotare la subnet 172.17.0.1/16 predefinita. Tuttavia, nella versione 1.10.0, c'è un bug nell'immagine del sistema operativo di Ubuntu che ha causato il tentativo di ignorare la configurazione Docker personalizzata.

    Di conseguenza, Docker sceglie 172.17.0.1/16 predefinito come subnet di indirizzo IP bridge. Questo potrebbe causare un conflitto di indirizzi IP se il tuo carico di lavoro è già in esecuzione all'interno di questo intervallo di indirizzi IP.


    Soluzione alternativa:

    Per risolvere questo problema, devi rinominare il seguente file di configurazione systemd per dockerd, quindi riavviare il servizio:

    sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

    Verifica che Docker scelga l'indirizzo IP del bridge corretto:

    ip a | grep docker0

    Questa soluzione non viene mantenuta durante le ricreazioni di VM. Devi applicare nuovamente questa soluzione alternativa ogni volta che vengono ricreate le VM.
    Upgrade e aggiornamenti 1,11

    Upgrade a 1.11 bloccato dall'idoneità allo stackdriver

    In GKE su VMware versione 1.11.0, sono state apportate modifiche alla definizione delle risorse personalizzate relative al logging e al monitoraggio:

    • Nome del gruppo della risorsa personalizzata stackdriver modificato da addons.sigs.k8s.io a addons.gke.io;
    • Nome del gruppo delle risorse personalizzate monitoring e metricsserver modificato da addons.k8s.io a addons.gke.io;
    • Le specifiche delle risorse sopra citate iniziano a essere valutate in base al relativo schema. In particolare, le specifiche resourceAttrOverride e storageSizeOverride nella risorsa personalizzata stackdriver devono avere il tipo di stringa nei valori dei limiti e delle richieste di CPU, memoria e dimensioni dello spazio di archiviazione.

    Le modifiche al nome del gruppo vengono apportate in modo da rispettare gli aggiornamenti CustomResourceDefinition in Kubernetes 1.22.

    Non è richiesta alcuna azione se non disponi di una logica aggiuntiva che applica o modifica le risorse personalizzate interessate. Il processo di upgrade di GKE su VMware si occuperà della migrazione delle risorse interessate e manterrà le specifiche esistenti dopo la modifica del nome del gruppo.

    Tuttavia, se esegui una logica che applica o modifica le risorse interessate, è necessaria un'attenzione particolare. Innanzitutto, devi farvi riferimento con il nuovo nome del gruppo nel file manifest. Ad esempio:

    apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    In secondo luogo, assicurati che i valori delle specifiche resourceAttrOverride e storageSizeOverride siano di tipo stringa. Ad esempio:

    spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work 
        memory: 3000Mi

    In caso contrario, l'applicazione e le modifiche non avranno effetto e potrebbero generare uno stato imprevisto nei componenti di logging e monitoraggio. I potenziali sintomi possono includere:

    • Log degli errori di riconciliazione in onprem-user-cluster-controller, ad esempio: 
      potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Errore in kubectl edit stackdriver stackdriver, ad esempio: 
      Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Se si verificano gli errori riportati sopra, significa che prima dell'upgrade era già presente un tipo non supportato nella specifica della RP di Stackdriver. Come soluzione alternativa, puoi modificare manualmente la RP di stackdriver con il nome di gruppo precedente kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver ed eseguire queste operazioni:

    1. Modificare le richieste e i limiti della risorsa in tipo stringa;
    2. Rimuovi qualsiasi annotazione addons.gke.io/migrated-and-deprecated: true, se presente.
    Quindi, riprendi o riavvia il processo di upgrade.

    Sistema operativo 1,7; 1,8; 1,9; 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16

    Le VM COS non mostrano IP quando le VM vengono spostate tramite un arresto non controllato dell'host

    Ogni volta che si verifica un errore in un server ESXi e la funzione vCenter HA è stata abilitata per il server, tutte le VM nel server ESXi difettoso attivano il meccanismo vMotion e vengono spostate su un altro server ESXi normale. Le VM COS migrate perderebbero i propri IP.

    Soluzione alternativa:

    Riavvia la VM
    Networking tutte le versioni precedenti a 1.14.7, 1.15.0-1.15.3, 1.16.0

    La risposta GARP inviata da Seesaw non imposta l'IP di destinazione

    Il GARP (Gratuitous ARP) periodico inviato da Seesaw ogni 20 secondi non imposta l'IP di destinazione nell'intestazione ARP. Alcune reti potrebbero non accettare questi pacchetti (come Cisco ACI). Può causare un tempo di inattività del servizio più lungo dopo il recupero di uno spaccamento cerebrale (a causa della perdita di pacchetti VRRP).

    Soluzione alternativa:

    Per attivare un failover di Seeaw, esegui sudo seesaw -c failover su una delle VM di Seesaw. Questo dovrebbe ripristinare il traffico.
    Sistema operativo 1,16, 1,28,0-1,28,200

    kubelet è pieno di log che indicano che "/etc/kubernetes/manifests" non esiste sui nodi worker

    "staticPodPath" è stato impostato per errore per i nodi worker

    Soluzione alternativa:

    Crea manualmente la cartella "/etc/kubernetes/manifests"
    Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.