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

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

Se fai parte del programma per sviluppatori Google, salva questa pagina per ricevere notifiche quando viene pubblicata una nota di rilascio correlata a questa pagina. Per scoprire di più, vedi Pagine salvate.

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

Seleziona la tua versione di Google Distributed Cloud:

Seleziona la categoria del problema:

In alternativa, cerca il tuo problema:

Categoria Versioni identificate Problema e soluzione alternativa
Aggiornamenti 1.32.0-1.32.600, 1.33.0-1.33.100

L'utilizzo di gkectl update per aggiornare un cluster utente non ad alta disponibilità (non HA) a un cluster avanzato con un control plane HA non riesce e viene visualizzato il seguente messaggio di errore:

Failed to generate diff summary: failed to get desired onprem user cluster and node pools from seed config with dry-run webhooks:
failed to apply validating webhook to OnPremUserCluster:
masterNode.replcias: Forbidden: the field must not be mutated, diff (-before, +after): int64(- 1,+ 3)

Soluzione temporanea:

Utilizza il comando gkectl upgrade per eseguire l'upgrade del cluster utente non HA a un cluster avanzato HA.
Aggiornamenti 1.30, 1.31

I pod Windows rimangono in stato Pending dopo la migrazione di ControlPlaneV2 a causa di un certificato TLS non valido

Durante un'operazione di aggiornamento di Google Distributed Cloud che include una migrazione di ControlPlaneV2 dalla versione 1.30.x alla 1.31.x, i pod Windows potrebbero non essere pianificati e rimanere nello stato Pending. Questo problema si manifesta come un errore di convalida del certificato TLS per il webhook di ammissione di modifica windows-webhook. Il problema si verifica perché il nome alternativo del soggetto (SAN) del certificato conserva erroneamente un valore valido per la vecchia architettura Kubeception anziché essere rigenerato per il nuovo endpoint kube-system.svc.

Potresti visualizzare il seguente messaggio di errore: failed calling webhook "windows.webhooks.gke.io": failed to call webhook: Post "https://windows-webhook.kube-system.svc:443/pod?timeout=10s": tls: failed to verify certificate: x509. Questa situazione può verificarsi a causa del processo di migrazione di ControlPlaneV2 che copia i contenuti di etcd, il che comporta il trasferimento del vecchio certificato senza una rigenerazione corretta. È importante notare che i pool di nodi Windows sono una funzionalità ritirata e non saranno disponibili in Google Distributed Cloud versione 1.33 e successive.

Soluzione temporanea:

  1. Esegui il backup del secret user-component-options nello spazio dei nomi del cluster utente:

        kubectl get secret user-component-options -n USER_CLUSTER_NAME -oyaml > backup.yaml

  2. Elimina il secret user-component-options:

        kubectl delete secret user-component-options -n USER_CLUSTER_NAME

  3. Modifica la risorsa onpremusercluster per attivare la riconciliazione aggiungendo l'annotazione onprem.cluster.gke.io/reconcile: "true":

        kubectl edit onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_MGMT_NAMESPACE

Sostituisci USER_CLUSTER_NAME con il nome del tuo cluster utente.
Upgrade, aggiornamenti 1.32.0-1.32.500, 1.33.0

L'upgrade/l'aggiornamento a un cluster avanzato non riesce se stackdriver non è configurato

Quando esegui l'upgrade/l'aggiornamento di un cluster non avanzato a un cluster avanzato, il processo potrebbe smettere di rispondere se stackdriver non è abilitato.

Soluzione temporanea:

  • Se l'upgrade del cluster non è ancora stato eseguito, devi seguire i passaggi per attivare stackdriver:
    1. Aggiungi la sezione stackdriver al file di configurazione del cluster.
    2. Esegui gkectl update per attivare stackdriver.
  • Se è già in corso un upgrade, segui questi passaggi:
    1. Modifica il secret user-cluster-creds nello spazio dei nomi USER_CLUSTER_NAME-gke-onprem-mgmt con il seguente comando: 
      kubectl --kubeconfig ADMIN_KUBECONFIG \
  patch secret user-cluster-creds \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  --type merge -p "{\"data\":{\"stackdriver-service-account-key\":\"$(cat STACKDRIVER_SERVICE_ACCOUNT_KEY_FILE | base64 | tr -d '\n')\"}}"
    2. Aggiorna la risorsa personalizzata OnPremUserCluster con il campo stackdriver. Devi utilizzare lo stesso progetto con la stessa posizione del progetto e la stessa chiave del account di servizio di cloudauditlogging se hai attivato la funzionalità. 
      kubectl --kubeconfig ADMIN_KUBECONFIG \
    patch onpremusercluster USER_CLUSTER_NAME \
    -n USER_CLUSTER_NAME-gke-onprem-mgmt --type merge -p '
    spec:
      stackdriver:
        clusterLocation: PROJECT_LOCATION
        providerID: PROJECT_ID
        serviceAccountKey:
          kubernetesSecret:
            keyName: stackdriver-service-account-key
            name: user-cluster-creds
'
    3. Aggiungi la sezione stackdriver al file di configurazione del cluster per coerenza.
Upgrade 1.29, 1.30, 1.31, 1.32+

I pod non riescono a connettersi al server API Kubernetes con Dataplane V2 e criteri di rete restrittivi

Nei cluster che utilizzano l'architettura Control Plane V2 (CPv2) (impostazione predefinita nella versione 1.29 e successive) e Dataplane V2, i pod potrebbero non riuscire a connettersi al server API Kubernetes (kubernetes.default.svc.cluster.local). Questo problema è spesso causato dalla presenza di criteri di rete, in particolare quelli con regole di uscita di negazione predefinite. I sintomi includono:

  • I tentativi di connessione TCP all'indirizzo IP del cluster o agli indirizzi IP dei nodi del server API restituiscono un messaggio Connection reset by peer.
  • Errori di handshake TLS durante la connessione al server API.
  • L'esecuzione del comando cilium monitor -t drop sul nodo interessato può mostrare i pacchetti destinati agli indirizzi IP dei nodi del control plane e alla porta del server API (in genere 6443) che vengono eliminati.

Causa

Questo problema deriva da un'interazione tra Dataplane V2 (basato su Cilium) e le norme di rete Kubernetes nell'architettura CPv2, in cui i componenti del control plane vengono eseguiti sui nodi all'interno del cluster utente. La configurazione Cilium predefinita non interpreta correttamente le regole ipBlock nei criteri di rete che hanno lo scopo di consentire il traffico agli IP dei nodi dei membri del piano di controllo. Questo problema è correlato a un problema Cilium upstream (cilium#20550).

Soluzione temporanea:

Per le versioni 1.29, 1.30 e 1.31, evita di utilizzare criteri di rete in uscita restrittivi che potrebbero bloccare il traffico verso i nodi del control plane. Se hai bisogno di una policy di negazione predefinita, potresti dover aggiungere una regola di autorizzazione generale per tutto il traffico in uscita, ad esempio non specificando alcuna regola nella sezione in uscita, consentendo di fatto tutto il traffico in uscita. Questa soluzione è meno sicura e potrebbe non essere adatta a tutti gli ambienti.

Per tutte le altre versioni, abilita una configurazione Cilium per far corrispondere correttamente gli IP dei nodi nei campi ipBlock della policy di rete. Per trovare una corrispondenza tra gli IP dei nodi nei campi ipBlock del criterio di rete, segui questi passaggi:

  1. Modifica il ConfigMap cilium-config: 
    kubectl edit configmap -n kube-system cilium-config
  2. Aggiungi o modifica la sezione dei dati in modo che includa policy-cidr-match-mode: nodes: 
    data:
      policy-cidr-match-mode: nodes
  3. Per applicare la modifica alla configurazione, riavvia il DaemonSet anetd: 
    kubectl rollout restart ds anetd -n kube-system
  4. Assicurati di avere un criterio di rete che consenta esplicitamente il traffico in uscita dai pod agli IP dei nodi del control plane sulla porta del server API. Identifica gli indirizzi IP dei nodi del control plane del cluster utente eseguendo kubectl get svc kubernetes. L'output è simile al seguente: 
        apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-egress-to-kube-apiserver
      namespace: NAMESPACE_NAME
    spec:
      podSelector: {} 
      policyTypes:
      - Egress
      egress:
      - to:
        - ipBlock:
            cidr: CP_NODE_IP_1/32
        - ipBlock:
            cidr: CP_NODE_IP_2/32
        ports:
        - protocol: TCP
          port: 6443 # Kubernetes API Server port on the node
Installazione 1.30.200-gke.101

Il pod dell'agente gke-connect bloccato nello stato Pending durante la creazione del cluster utente

Durante la creazione del cluster utente, il pod dell'agente gke-connect potrebbe bloccarsi nello stato Pending, impedendo la creazione completa del cluster. Questo problema si verifica perché il pod dell'agente gke-connect tenta di pianificare prima che i nodi di lavoro siano disponibili, il che porta a un deadlock.

Questo problema si verifica quando la creazione iniziale del cluster di utenti non va a buon fine a causa di errori di convalida preflight e viene effettuato un tentativo successivo di creare il cluster senza prima eliminare le risorse create parzialmente. Nel successivo tentativo di creazione del cluster, il pod dell'agente gke-connect è bloccato a causa di taint non tollerati sui nodi del control plane, come indicato da un errore simile al seguente:

    0/3 nodes are available: 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }`.

Soluzione temporanea:

Se la creazione del cluster utente non riesce a causa di errori di convalida preflight, elimina le risorse del cluster create parzialmente prima di tentare di creare di nuovo il cluster con le configurazioni corrette. Ciò garantisce che il flusso di lavoro di creazione proceda correttamente, inclusa la creazione di pool di nodi prima del deployment del pod dell'agente gke-connect.
Aggiorna 1.16 e versioni precedenti, 1.28.0-1.28.1100, 1.29.0-1.29.700, 1.30.0-1.30.200

Dopo aver disattivato la crittografia dei secret sempre attiva con gkectl update cluster, i secret vengono comunque archiviati in etcd con la crittografia. Questo problema riguarda solo i cluster utente kubeception. Se il tuo cluster utilizza Controlplane V2, non sei interessato da questo problema.

Per verificare se i secret sono ancora criptati, esegui questo comando, che recupera il secret default/private-registry-creds memorizzato in etcd:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    exec -it -n USER_CLUSTER_NAME kube-etcd-0 -c kube-etcd -- \
    /bin/sh -ec "export ETCDCTL_API=3; etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etcd.local.config/certificates/etcdCA.crt \
    --cert=/etcd.local.config/certificates/etcd.crt \
    --key=/etcd.local.config/certificates/etcd.key \
    get /registry/secrets/default/private-registry-creds" | hexdump -C

Se il secret è archiviato con la crittografia, l'output è simile al seguente:

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 3a 65 6e  63 3a 6b 6d 73 3a 76 31  |..k8s:enc:kms:v1|
00000040  3a 67 65 6e 65 72 61 74  65 64 2d 6b 65 79 2d 6b  |:generated-key-k|
00000050  6d 73 2d 70 6c 75 67 69  6e 2d 31 3a 00 89 65 79  |ms-plugin-1:..ey|
00000060  4a 68 62 47 63 69 4f 69  4a 6b 61 58 49 69 4c 43  |JhbGciOiJkaXIiLC|
...

Se il secret non è archiviato con la crittografia, l'output è simile al seguente:

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 00 0d 0a  0c 0d 0a 02 76 31 12 06  |..k8s.......v1..|
00000040  53 65 63 72 65 74 12 83  47 0d 0a b0 2d 0d 0a 16  |Secret..G...-...|
00000050  70 72 69 76 61 74 65 2d  72 65 67 69 73 74 72 79  |private-registry|
00000060  2d 63 72 65 64 73 12 00  1a 07 64 65 66 61 75 6c  |-creds....defaul|
...

Soluzione temporanea:

  1. Esegui un aggiornamento in sequenza su un DaemonSet specifico nel seguente modo: 
        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      rollout restart statefulsets kube-apiserver \
      -n USER_CLUSTER_NAME
  2. Recupera i manifest di tutti i secret nel cluster utente in formato YAML: 
        kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
      get secrets -A -o yaml > SECRETS_MANIFEST.yaml
  3. Applica nuovamente tutti i secret nel cluster utente in modo che tutti i secret vengano archiviati in etcd come testo normale: 
        kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
      apply -f SECRETS_MANIFEST.yaml

Configurazione 1.29, 1.30, 1.31

Nel file di configurazione del cluster utente, user-cluster.yaml, generato dal comando gkectl get-config, manca il campo hostgroups nella sezione nodePools. Il comando gkectl get-config genera il file user-cluster.yaml in base ai contenuti della risorsa personalizzata OnPremUserCluster. Il campo nodePools[i].vsphere.hostgroups esiste nella risorsa personalizzata OnPremNodePool e non viene copiato nel file user-cluster.yaml quando esegui gkectl get-config.

Soluzione temporanea

Per risolvere il problema, aggiungi manualmente il campo nodePools[i].vsphere.hostgroups al file user-cluster.yaml. Il file modificato dovrebbe essere simile all'esempio seguente:

apiVersion: v1
kind: UserCluster
...
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
  replicas: 3
  vsphere:
    hostgroups:
    - "hostgroup-1"
...

Puoi utilizzare il file di configurazione del cluster utente modificato per aggiornare il cluster utente senza attivare errori e il campo hostgroups viene mantenuto.
Networking 1.29.0-1.29.1000 1.30.0-1.30.500, 1.31.0-1.31.100

I pod Istiod dell'ingresso in bundle non possono essere pronti se le risorse gateway.networking.k8s.io sono installate nel cluster utente. Il seguente messaggio di errore di esempio è disponibile nei log dei pod:

    failed to list *v1beta1.Gateway: gateways.gateway.networking.k8s.io is forbidden: User \"system:serviceaccount:gke-system:istiod-service-account\" cannot list resource \"gateways\" in API group \"gateway.networking.k8s.io\" at the cluster scope"

Soluzione temporanea:

Applica il seguente ClusterRole e ClusterRoleBinding al cluster utente: 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: istiod-gateway
rules:
- apiGroups:
  - 'gateway.networking.k8s.io'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: istiod-gateway-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: istiod-gateway
subjects:
- kind: ServiceAccount
  name: istiod-service-account
  namespace: gke-system
Installazione 1.29.0-1.29.1000 1.30.0-1.30.500, 1.31.0-1.31.100

Se i nomi host nel campo ipblocks contengono lettere maiuscole, i nodi del control plane del cluster di amministrazione potrebbero riavviarsi ripetutamente.

Soluzione temporanea:

Utilizza solo nomi host minuscoli.
Installazione, upgrade 1.30.0-1.30.500, 1.31.0-1.31.100

Runtime: out of memory "error" dopo l'esecuzione di gkeadm create o upgrade

Quando crei o esegui l'upgrade delle workstation di amministrazione con i comandi gkeadm, potresti ricevere un errore di esaurimento della memoria durante la verifica dell'immagine del sistema operativo scaricata.

Ad esempio, 

Downloading OS image
"gs://gke-on-prem-release/admin-appliance/1.30.400-gke.133/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova"...

[==================================================>] 10.7GB/10.7GB

Image saved to
/anthos/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova

Verifying image gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova...
|

runtime: out of memory

Soluzione temporanea:

  • Aumenta la dimensione della memoria del sistema operativo in cui esegui il comando gkeadm.
    		•
    Upgrade 1.30.0-1.30.400

    L'upgrade del cluster di amministrazione non HA è bloccato su Creating or updating cluster control plane workloads

    Quando esegui l'upgrade di un cluster di amministrazione non ad alta disponibilità, l'upgrade potrebbe bloccarsi al Creating or updating cluster control plane workloads.

    Questo problema si verifica se nella VM master amministratore, ip a | grep cali restituisce un risultato non vuoto.

    Ad esempio, 

    ubuntu@abf8a975479b-qual-342-0afd1d9c ~ $ ip a | grep cali
4: cali2251589245f@if3:  mtu 1500 qdisc noqueue state UP group default

    Soluzione temporanea:

    1. Ripara il master di amministrazione: 
      gkectl repair admin-master --kubeconfig=ADMIN_KUBECONFIG \
    --config=ADMIN_CONFIG_FILE \
    --skip-validation
    2. Seleziona il modello di VM 1.30 se visualizzi un prompt come il seguente esempio: 
      Please select the control plane VM template to be used for re-creating the
admin cluster's control plane VM.
    3. Riprendi l'upgrade: 
      gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG \
    --config ADMIN_CONFIG_FILE
    Configurazione 1.31.0

    Campo isControlPlane ridondante nel file di configurazione del cluster in network.controlPlaneIPBlock

    I file di configurazione del cluster generati da gkectl create-config nella versione 1.31.0 contengono un campo isControlPlane ridondante in network.controlPlaneIPBlock:

        controlPlaneIPBlock:
    netmask: ""
    gateway: ""
    ips:
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false

    Questo campo non è necessario e può essere rimosso in sicurezza dal file di configurazione.

    Migrazione 1.29.0-1.29.800, 1.30.0-1.30.400, 1.31.0

    Quando esegui la migrazione di un cluster di amministrazione non HA che utilizza MetalLB ad HA, i nodi del componente aggiuntivo di amministrazione potrebbero bloccarsi con lo stato NotReady, impedendo il completamento della migrazione.

    Questo problema riguarda solo i cluster di amministrazione configurati con MetalLB, in cui la riparazione automatica non è abilitata.

    Questo problema è causato da una race condition durante la migrazione in cui i speaker MetalLB utilizzano ancora il vecchio secret metallb-memberlist. A causa della race condition, il vecchio VIP del control plane diventa inaccessibile, il che causa l'interruzione della migrazione.

    Soluzione temporanea:

    1. Elimina il secret metallb-memberlist esistente: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    delete secret metallb-memberlist
    2. Riavvia il deployment di metallb-controller in modo che possa generare il nuovo metallb-memberlist: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    rollout restart deployment metallb-controller
    3. Assicurati che venga generato il nuovo metallb-memberlist: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    get secret metallb-memberlist
    4. Aggiorna updateStrategy.rollingUpdate.maxUnavailable nel DaemonSet metallb-speaker da 1 a 100%.

      Questo passaggio è obbligatorio perché alcuni pod DaemonSet vengono eseguiti sui nodi NotReady.

      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    edit daemonset metallb-speaker
    5. Riavvia il DaemonSet metallb-speaker in modo che possa recuperare la nuova lista dei membri: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    rollout restart daemonset metallb-speaker

      Dopo alcuni minuti, i nodi del componente aggiuntivo amministratore tornano a essere Ready e la migrazione può continuare.

    6. Se il comando gkectl iniziale è scaduto dopo più di 3 ore, esegui di nuovo gkectl update per riprendere la migrazione non riuscita.
    Configurazione, funzionamento 1.12+, 1.13+, 1.14+, 1.15+, 1.16+, 1.28+, 1.29+, 1.30+

    Il backup del cluster per il cluster di amministrazione non HA non riesce a causa di nomi lunghi di datastore e datadisk

    Quando si tenta di eseguire il backup di un cluster di amministrazione non HA, il backup non riesce perché la lunghezza combinata dei nomi del datastore e del disco dati supera la lunghezza massima dei caratteri.

    La lunghezza massima di un nome datastore è 80 caratteri.
    Il percorso di backup per un cluster di amministrazione non HA ha la sintassi di denominazione "__". Pertanto, se il nome concatenato supera la lunghezza massima, la creazione della cartella di backup non andrà a buon fine

    Soluzione temporanea:

    Rinomina il datastore o il datadisk con un nome più breve.
    Assicurati che la lunghezza combinata dei nomi del datastore e del datadisk non superi la lunghezza massima dei caratteri.
    Upgrade 1,28, 1,29, 1,30

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

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

    Soluzione temporanea:

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

      Salva la modifica.

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

      Verrà creata una nuova macchina con la versione corretta.
    Configurazione 1.30.0

    Quando aggiorni un cluster utente o un nodepool utilizzando Terraform, Terraform potrebbe tentare di impostare i campi vCenter su valori vuoti.

    Questo problema può verificarsi se il cluster non è stato creato originariamente utilizzando Terraform.

    Soluzione temporanea:

    Per evitare l'aggiornamento imprevisto, assicurati che l'aggiornamento sia sicuro prima di eseguire terraform apply, come descritto di seguito:

    1. Esegui terraform plan
    2. Nell'output, controlla se i campi vCenter sono impostati su nil.
    3. Se un campo vCenter è impostato su un valore vuoto, nella configurazione Terraform, aggiungi vcenter all'elenco ignore_changes seguendo la documentazione di Terraform. In questo modo, gli aggiornamenti a questi campi vengono impediti.
    4. Esegui di nuovo terraform plan e controlla l'output per verificare che l'aggiornamento sia quello previsto.
    Aggiornamenti 1.13, 1.14, 1.15, 1.16

    Dopo la creazione, l'aggiornamento o l'upgrade dei nodi del control plane dei cluster utente kubeception, questi verranno riavviati uno alla volta durante la prima operazione del cluster di amministrazione quando il cluster di amministrazione viene creato o aggiornato a una delle versioni interessate. Per i cluster kubeception con tre nodi del control plane, questo non dovrebbe causare tempi di inattività del control plane e l'unico impatto è che l'operazione del cluster di amministrazione richiede più tempo.

    Installazione, upgrade e aggiornamenti 1,31

    Nella versione 1.31 di Google Distributed Cloud, potresti ricevere errori quando provi a creare risorse personalizzate, come cluster (di tutti i tipi) e carichi di lavoro. Il problema è causato da una modifica sostanziale introdotta in Kubernetes 1.31 che impedisce la transizione del campo caBundle in una definizione di risorsa personalizzata da uno stato valido a uno non valido. Per saperne di più sulla modifica, consulta il changelog di Kubernetes 1.31.

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

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

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

    Soluzione temporanea

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

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

    Soluzione temporanea:

    Esegui questo comando per controllare lo stato di cloud-init:

        systemctl show -p Result cloud-final.service

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

        Result=success
    Upgrade 1,28

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

        Workstation Hardware: Workstation hardware requirements are not satisfied

    Nella versione 1.28, il prerequisito relativo alla dimensione del disco della workstation amministrativa è stato aumentato da 50 GB a 100 GB.

    Soluzione temporanea:

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

    Il comando gkectl upgrade restituisce un errore errato relativo alla classe di archiviazione netapp. Il messaggio di errore è simile al seguente: 

        detected unsupported drivers:
      csi.trident.netapp.io

    Soluzione temporanea:

    Esegui gkectl upgrade con il flag `--skip-pre-upgrade-checks`.
    Identità tutte le versioni

    Dopo aver ruotato i certificati dell'autorità di certificazione (CA) su un cluster utente, il campo spec.certificateAuthorityData in ClientConfig contiene un certificato CA non valido, il che impedisce l'autenticazione al cluster.

    Soluzione temporanea:

    Prima della successiva autenticazione gcloud CLI, aggiorna manualmente il campo spec.certificateAuthorityData nel file ClientConfig con il certificato CA corretto.

    1. Copia il certificato CA del cluster dal campo certificate-authority-data nel file kubeconfig del cluster di amministrazione.
    2. Modifica ClientConfig e incolla il certificato CA nel campo spec.certificateAuthorityData. 
          kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
    Aggiornamenti 1.28+

    Quando disattivi l'ingresso in bundle rimuovendo il campo loadBalancer.vips.ingressVIP nel file di configurazione del cluster, un bug nel controllo preliminare di MetalLB causa l'errore "invalid user ingress vip: invalid IP" durante l'aggiornamento del cluster.

    Soluzione temporanea:

    Ignora il messaggio di errore.
    Salta il controllo preliminare utilizzando uno dei seguenti metodi:

    • Aggiungi il flag --skip-validation-load-balancer al comando gkectl update cluster.
    • Annota l'oggetto onpremusercluster con onprem.cluster.gke.io/server-side-preflight-skip: skip-validation-load-balancer
      • .
    VMware, upgrade 1,16

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

    Se descrivi gli oggetti macchina problematici, puoi visualizzare messaggi ricorrenti come "Riconfigurazione dell'attività della regola DRS "task-xxxx" completata".

        kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME

    Soluzione temporanea:

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

        gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
    
        gkectl update cluster --config USER_CLUSTER_CONFIG_FILE --kubeconfig USER_CLUSTER_KUBECONFIG --force
    Migrazione 1.29, 1.30

    Quando esegui la migrazione di un cluster utente a Controlplane V2, se la crittografia dei secret sempre attiva è mai stata attivata, il processo di migrazione non gestisce correttamente la chiave di crittografia dei secret. A causa di questo problema, il nuovo cluster Controlplane V2 non è in grado di decriptare i secret. Se l'output del seguente comando non è vuoto, la crittografia dei secret sempre attiva è stata abilitata a un certo punto e il cluster è interessato da questo problema:

        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      get onpremusercluster USER_CLUSTER_NAME \
      -n USER_CLUSTER_NAME-gke-onprem-mgmt \
      -o jsonpath={.spec.secretsEncryption}

    Se hai già avviato la migrazione e non va a buon fine, contatta Google per ricevere assistenza. In caso contrario, prima della migrazione, disabilita la crittografia dei secret sempre attiva e decripta i secret.

    Migrazione 1.29.0-1.29.600, 1.30.0-1.30.100

    Se il cluster di amministrazione ha abilitato la crittografia dei secret sempre attiva alla versione 1.14 o precedente ed è stato eseguito l'upgrade da versioni precedenti alle versioni 1.29 e 1.30 interessate, durante la migrazione del cluster di amministrazione da non HA ad HA, il processo di migrazione non gestisce correttamente la chiave di crittografia dei secret. A causa di questo problema, il nuovo cluster di amministrazione HA non è in grado di decriptare i secret.

    Per verificare se il cluster potrebbe utilizzare la vecchia chiave formattata:

        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

    Se l'output mostra la chiave vuota come di seguito, è probabile che il cluster sia interessato da questo problema:

        "GeneratedKeys":[{"KeyVersion":"1","Key":""}]

    Se hai già iniziato la migrazione e non va a buon fine, contatta Google per ricevere assistenza.

    In caso contrario, prima di avviare la migrazione, ruota la chiave di crittografia.
    Upgrade 1.16, 1.28, 1.29, 1.30

    Quando esegui l'upgrade della workstation di amministrazione utilizzando il comando gkeadm upgrade admin-workstation, il file credential.yaml viene rigenerato in modo errato. I campi nome utente e password sono vuoti. Inoltre, la chiave privateRegistry contiene un errore di battitura.

    Lo stesso errore ortografico del tasto privateRegistry è presente anche nel file admin-cluster.yaml.
    Poiché il file credential.yaml viene rigenerato durante la procedura di upgrade del cluster di amministrazione, l'errore di battitura è presente anche se è stato corretto in precedenza.

    Soluzione temporanea:

    • Aggiorna il nome della chiave del registro privato in credential.yaml in modo che corrisponda a privateRegistry.credentials.fileRef.entry in admin-cluster.yaml.
    • Aggiorna il nome utente e la password del registro privato in credential.yaml.
    Upgrade 1.16+

    Quando esegui l'upgrade di un cluster utente, l'operazione di riconciliazione pre-upgrade potrebbe richiedere più tempo del timeout definito, causando un errore di upgrade. Il messaggio di errore è simile al seguente:

    Failed to reconcile the user cluster before upgrade: the pre-upgrade reconcile failed, error message:
failed to wait for reconcile to complete: error: timed out waiting for the condition,
message: Cluster reconcile hasn't finished yet, please fix that before
rerun the upgrade.

    Il timeout per l'operazione di riconciliazione pre-upgrade è di 5 minuti più 1 minuto per ogni pool di nodi nel cluster utente.

    Soluzione temporanea:

    Assicurati che il comando gkectl diagnose cluster venga eseguito senza errori.
    Salta l'operazione di riconciliazione pre-upgrade aggiungendo il flag --skip-reconcile-before-preflight al comando gkectl upgrade cluster. Ad esempio:

    gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
    Aggiornamenti 1.16, 1.28.0-1.28.800, 1.29.0-1.29.400, 1.30.0

    Quando aggiorni il cluster utente dataplaneV2.forwardMode campo utilizzando gkectl update cluster, la modifica viene aggiornata solo in ConfigMap, il DaemonSet anetd non rileva la modifica della configurazione fino al riavvio e le modifiche non vengono applicate.

    Soluzione temporanea:

    Al termine del comando gkectl update cluster, viene visualizzato l'output di Done updating the user cluster. Dopo aver visualizzato questo messaggio, esegui il comando seguente per riavviare il DaemonSet anetd per applicare la modifica alla configurazione:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd

    Controlla la disponibilità di DaemonSet dopo il riavvio:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd

    Nell'output del comando precedente, verifica che il numero nella colonna DESIRED corrisponda al numero nella colonna READY.
    Upgrade 1,16

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

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

    Il backup del cluster di amministrazione prevede diversi passaggi, tra cui l'acquisizione di uno snapshot di etcd e la scrittura del file di metadati per il cluster di amministrazione. Il backup di etcd ha ancora esito positivo perché etcdctl può ancora essere attivato dopo l'esecuzione di un comando nel pod etcd. Tuttavia, la scrittura del file di metadati non riesce perché si basa ancora sul binario etcdctl da installare sul nodo. Tuttavia, il backup del file di metadati non è un blocco per l'esecuzione di un backup, quindi il processo di backup ha esito positivo, così come l'upgrade del cluster utente.

    Soluzione temporanea:

    Se vuoi eseguire un backup del file di metadati, segui la procedura descritta in Backup e ripristino di un cluster di amministrazione con gkectl per attivare un backup separato del cluster di amministrazione utilizzando la versione di gkectl che corrisponde alla versione del cluster di amministrazione.
    Installazione 1.16-1.29

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

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

    Soluzione temporanea:

    Per risolvere questo problema, ignora il risultato restituito da gkectl check-config. Per disattivare il traffico in entrata in bundle, vedi Disattivare il traffico in entrata in bundle.
    Aggiornamenti 1.29.0

    Il problema con PodDisruptionBudget (PDB) si verifica quando si utilizzano cluster di amministrazione ad alta disponibilità (HA) e sono presenti 0 o 1 nodi del cluster di amministrazione senza un ruolo dopo la migrazione. Per verificare se sono presenti oggetti nodo senza un ruolo, esegui questo comando:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide

    Se dopo la migrazione sono presenti due o più oggetti nodo senza un ruolo, il PDB non è configurato in modo errato.

    Sintomi:

    L'output di admin cluster diagnose include le seguenti informazioni

    Checking all poddisruptionbudgets...FAILURE
  Reason: 1 pod disruption budget error(s).
  Unhealthy Resources:
  PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1).

    Soluzione temporanea:

    Esegui questo comando per eliminare il PDB:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server
    Installazione, upgrade e aggiornamenti 1.28.0-1.28.600,1.29.0-1.29.100

    In rare condizioni di competizione, una sequenza di installazione errata del webhook di Autorizzazione binaria e del pod gke-connect può causare l'interruzione della creazione del cluster utente a causa dell'impossibilità di un nodo di raggiungere lo stato pronto. Negli scenari interessati, la creazione del cluster utente potrebbe bloccarsi perché un nodo non riesce a raggiungere lo stato pronto. In questo caso, viene visualizzato il seguente messaggio:

         Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready

    Soluzione temporanea:

    1. Rimuovi la configurazione di Autorizzazione binaria dal file di configurazione. Per istruzioni sulla configurazione, consulta la guida all'installazione di Autorizzazione binaria per GKE su VMware.
    2. Per sbloccare un nodo non integro durante il processo di creazione del cluster corrente, rimuovi temporaneamente la configurazione del webhook Autorizzazione binaria nel cluster utente utilizzando il seguente comando. 
              kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
      Una volta completato il processo di bootstrap, puoi aggiungere nuovamente la seguente configurazione del webhook. 
      apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: binauthz-validating-webhook-configuration
webhooks:
- name: "binaryauthorization.googleapis.com"
  namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist
  objectSelector:
    matchExpressions:
    - key: "image-policy.k8s.io/break-glass"
      operator: NotIn
      values: ["true"]
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    - UPDATE
    resources:
    - pods
    - pods/ephemeralcontainers
  admissionReviewVersions:
  - "v1beta1"
  clientConfig:
    service:
      name: binauthz
      namespace: binauthz-system
      path: /binauthz
    # CA Bundle will be updated by the cert rotator.
    caBundle: Cg==
  timeoutSeconds: 10
  # Fail Open
  failurePolicy: "Ignore"
  sideEffects: None
    Upgrade 1.16, 1.28, 1.29

    Durante l'upgrade di un cluster utente, l'operazione di upgrade potrebbe bloccarsi se l'oggetto macchina sottoposto a mirroring nel cluster utente contiene un deletionTimestamp. Se l'upgrade è bloccato, viene visualizzato il seguente messaggio di errore:

        machine is still in the process of being drained and subsequently removed

    Questo problema può verificarsi se in precedenza hai tentato di riparare il nodo del piano di controllo utente eseguendo gkectl delete machine sulla macchina sottoposta a mirroring nel cluster utente.

    Soluzione temporanea:

    1. Recupera l'oggetto macchina sottoposto a mirroring e salvalo in un file locale a scopo di backup.
    2. Esegui questo comando per eliminare il finalizzatore dalla macchina mirror e attendi che venga eliminato dal cluster utente. 
          kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
    3. Segui i passaggi descritti in Nodo del control plane del cluster utente Controlplane V2 per attivare la riparazione dei nodi sui nodi del control plane, in modo che la specifica della macchina di origine corretta venga risincronizzata nel cluster utente.
    4. Esegui di nuovo gkectl upgrade cluster per riprendere l'upgrade
    Configurazione, installazione 1.15, 1.16, 1.28, 1.29

    Per il cluster di amministrazione HA o il cluster utente ControlPlane V2, il VIP del control plane deve trovarsi nella stessa subnet degli altri nodi del cluster. In caso contrario, la creazione del cluster non va a buon fine perché kubelet non può comunicare con il server API utilizzando il VIP del control plane.

    Soluzione temporanea:

    Prima della creazione del cluster, assicurati che il VIP del control plane sia configurato nella stessa subnet degli altri nodi del cluster.
    Installazione, upgrade, aggiornamenti 1.29.0 - 1.29.100

    La creazione/l'upgrade del cluster non riesce e viene visualizzato un errore nei pod CSI di vSphere che indica che il nome utente vCenter non è valido. Questo accade perché il nome utente utilizzato non è un nome di dominio completo. Messaggio di errore nel pod vsphere-csi-controller come di seguito:

        GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username

    Questo problema si verifica solo nella versione 1.29 e successive, in quanto è stata aggiunta una convalida al driver CSI vSphere per imporre l'utilizzo di nomi utente di dominio completi.

    Soluzione temporanea:

    Utilizza un nome di dominio completo per il nome utente vCenter nel file di configurazione delle credenziali. Ad esempio, anziché utilizzare "username1", utilizza "username1@example.com".
    Upgrade, aggiornamenti 1.28.0 - 1.28.500

    Quando esegui l'upgrade di un cluster di amministrazione dalla versione 1.16 alla 1.28, il bootstrap della nuova macchina master di amministrazione potrebbe non riuscire a generare il certificato del piano di controllo. Il problema è causato da modifiche al modo in cui vengono generati i certificati per il server API Kubernetes nella versione 1.28 e successive. Il problema si riproduce per i cluster creati nelle versioni 1.10 e precedenti che sono stati aggiornati fino alla versione 1.16 e il certificato foglia non è stato ruotato prima dell'upgrade.

    Per determinare se l'errore di upgrade del cluster di amministrazione è causato da questo problema, segui questi passaggi:

    1. Connettiti alla macchina master amministratore non riuscita utilizzando SSH.
    2. Apri /var/log/startup.log e cerca un errore simile al seguente:
    Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>

    Soluzione temporanea:

    1. Connettiti alla macchina master amministratore utilizzando SSH. Per maggiori dettagli, vedi Utilizzo di SSH per connettersi a un nodo del cluster di amministrazione.
    2. Crea una copia di /etc/startup/pki-yaml.sh e chiamala /etc/startup/pki-yaml-copy.sh
    3. Modifica /etc/startup/pki-yaml-copy.sh. Trova authorityKeyIdentifier=keyidset e modificalo in authorityKeyIdentifier=keyid,issuer nelle sezioni per le seguenti estensioni: apiserver_ext, client_ext, etcd_server_ext e kubelet_server_ext. Ad esempio: 
            [ apiserver_ext ]
      keyUsage = critical, digitalSignature, keyEncipherment
      extendedKeyUsage=serverAuth
      basicConstraints = critical,CA:false
      authorityKeyIdentifier = keyid,issuer
      subjectAltName = @apiserver_alt_names
    4. Salva le modifiche apportate a /etc/startup/pki-yaml-copy.sh.
    5. Utilizzando un editor di testo, apri /opt/bin/master.sh, trova e sostituisci tutte le occorrenze di /etc/startup/pki-yaml.sh con /etc/startup/pki-yaml-copy.sh, quindi salva le modifiche.
    6. Esegui /opt/bin/master.sh per generare il certificato e completare l'avvio della macchina.
    7. Esegui di nuovo gkectl upgrade admin per eseguire l'upgrade del cluster di amministrazione.
    8. Al termine dell'upgrade, ruota il certificato foglia per i cluster di amministrazione e utente, come descritto in Avvia la rotazione.
    9. Al termine della rotazione del certificato, apporta le stesse modifiche a /etc/startup/pki-yaml-copy.sh come hai fatto in precedenza ed esegui /opt/bin/master.sh.
    Configurazione 1.29.0

    Quando esegui gkectl per creare, aggiornare o eseguire l'upgrade di un cluster in cui è già abilitato Dataplane V2, viene visualizzato il seguente messaggio di avviso errato:

    WARNING: Your user cluster is currently running our original architecture with
[DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend
to update it to the newer architecture with [DataPlaneV2] once our migration
tool is available.

    Esiste un bug in gkectl che fa sì che questo avviso venga sempre visualizzato finché non viene utilizzato dataplaneV2.forwardMode, anche se hai già impostato enableDataplaneV2: true nel file di configurazione del cluster.

    Soluzione temporanea:

    Puoi ignorare tranquillamente questo avviso.
    Configurazione 1.28.0-1.28.400, 1.29.0

    Quando crei un cluster di amministrazione HA, il controllo preliminare mostra il seguente messaggio di errore errato:

    - Validation Category: Network Configuration
    - [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed
    at least X+1 IP addresses for admin cluster with X nodes

    Il requisito non è corretto per i cluster di amministrazione HA 1.28 e versioni successive perché non hanno più nodi aggiuntivi. Inoltre, poiché gli indirizzi IP dei tre nodi del control plane del cluster di amministrazione sono specificati nella sezione network.controlPlaneIPBlock del file di configurazione del cluster di amministrazione, gli IP nel file del blocco IP sono necessari solo per i nodi del control plane del cluster utente kubeception.

    Soluzione temporanea:

    Per ignorare il controllo preliminare errato in una release non corretta, aggiungi --skip-validation-net-config al comando gkectl.
    Operazione 1.29.0-1.29.100

    Se hai eseguito la migrazione da un cluster di amministrazione non HA a un cluster di amministrazione HA, Connect Agent nel cluster di amministrazione perde la connessione a gkeconnect.googleapis.com con l'errore "Failed to verify JWT signature". Questo perché durante la migrazione la chiave di firma KSA viene modificata, pertanto è necessaria una nuova registrazione per aggiornare i JWK OIDC.

    Soluzione temporanea:

    Per riconnettere il cluster di amministrazione a Google Cloud, segui questi passaggi per attivare una nuova registrazione:

    Innanzitutto, recupera il nome del deployment gke-connect:

    kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect

    Elimina il deployment gke-connect:

    kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect

    Attiva una riconciliazione forzata per onprem-admin-cluster-controller aggiungendo un'annotazione "force-reconcile" al tuo CR onpremadmincluster:

    kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p '
metadata:
  annotations:
    onprem.cluster.gke.io/force-reconcile: "true"
'

    L'idea è che onprem-admin-cluster-controller eseguirà sempre il redeploy del deployment gke-connect e registrerà nuovamente il cluster se non trova alcun deployment gke-connect esistente disponibile.

    Dopo la soluzione alternativa (potrebbero essere necessari alcuni minuti prima che il controller termini la riconciliazione), puoi verificare che l'errore 400 "Failed to verify JWT signature" non sia più presente nei log di gke-connect-agent:

    kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
    Installazione, Sistema operativo 1.28.0-1.28.500, 1.29.0

    Google Distributed Cloud specifica una subnet dedicata, --bip=169.254.123.1/24, per l'IP bridge Docker nella configurazione Docker per evitare di riservare la 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 Google Distributed Cloud 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 come subnet dell'indirizzo IP bridge. Ciò potrebbe causare un conflitto di indirizzi IP se hai già un carico di lavoro in esecuzione all'interno di questo intervallo di indirizzi IP.

    Soluzione temporanea:

    Per risolvere questo problema, devi riavviare il servizio Docker:

    sudo systemctl restart docker

    Verifica che Docker scelga l'indirizzo IP bridge corretto:

    ip a | grep docker0

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

    I file binari CNI standard bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap non sono inclusi nelle immagini del sistema operativo nelle versioni interessate. Questi binari CNI non vengono utilizzati da Dataplane V2, ma possono essere utilizzati per interfacce di rete aggiuntive nella funzionalità di più interfacce di rete.

    Più interfacce di rete con questi plug-in CNI non funzionano.

    Soluzione temporanea:

    Esegui l'upgrade alla versione con la correzione se utilizzi questa funzionalità.
    update 1.15, 1.16, 1.28

    L'installazione di multipathd sui nodi del cluster interferisce con il driver CSI vSphere, impedendo l'avvio dei workload utente.

    Soluzione temporanea:

    • Disabilita multipathd
    Aggiornamenti 1.15, 1.16

    Se alcune configurazioni richieste sono vuote nel cluster di amministrazione perché le convalide sono state ignorate, la loro aggiunta potrebbe essere bloccata dall'webhook del cluster di amministrazione. Ad esempio, se il campo gkeConnect non è stato impostato in un cluster di amministrazione esistente, l'aggiunta con il comando gkectl update admin potrebbe generare 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
    Occasionalmente, potrebbe verificarsi un problema di comunicazione tra il server API Kubernetes e il webhook. In questo caso, potresti visualizzare il seguente messaggio di errore: 
    failed to apply OnPremAdminCluster 'kube-system/gke-admin-btncc': Internal error occurred: failed calling webhook "monpremadmincluster.onprem.cluster.gke.io": failed to call webhook: Post "https://onprem-admin-cluster-controller.kube-system.svc:443/mutate-onprem-cluster-gke-io-v1alpha1-onpremadmincluster?timeout=10s": dial tcp 10.96.55.208:443: connect: connection refused

    Soluzione temporanea:

    Se riscontri uno di questi errori, utilizza una delle seguenti soluzioni alternative, a seconda della tua versione:
    • Per i 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 i 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

    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à (HA) nelle versioni 1.16 e successive. Tuttavia, quando questa sezione è vuota, Google Distributed Cloud assegna valori predefiniti a tutti i NodePort, incluso manualLB.controlPlaneNodePort, il che causa l'esito negativo della creazione del cluster con 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 temporanea:

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

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

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

    Se il log contiene una voce simile alla seguente dopo l'upgrade alla versione 1.28, il 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 temporanea:

    Assicurati che i nodi possano scaricare pacchetti da Canonical.

    Dopodiché, 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: /
    Archiviazione 1.28.0-1.28.100

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

    Soluzione temporanea:

    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. Fai riferimento alle istruzioni.
    Logging e monitoraggio 1.28.0-1.28.100

    L'API kubernetesmetadata.googleapis.com aggiunta di recente non supporta VPC-SC. Di conseguenza, l'agente di raccolta dei metadati non riuscirà a raggiungere questa API in VPC-SC. Successivamente, le etichette dei metadati delle metriche non saranno presenti.

    Soluzione temporanea:

    Imposta nel CR "stackdriver" dello spazio dei nomi "kube-system" il campo "featureGates.disableExperimentalMetadataAgent" su "true" eseguendo il comando

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

    poi 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, aggiornamenti 1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

    Quando un cluster di amministrazione e qualsiasi cluster utente con ControlPlane V2 abilitato utilizzano credenziali vSphere diverse, ad esempio dopo l'aggiornamento delle credenziali vSphere per il cluster di amministrazione, clusterapi-controller potrebbe non riuscire a connettersi a vCenter dopo il riavvio. Visualizza il log di 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, il problema ti riguarda: 
    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 temporanea:

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

    Logging e monitoraggio 1,14

    Prometheus potrebbe segnalare avvisi simili al seguente esempio:

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

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

    1. Controlla la metrica grpc_server_handled_total non elaborata rispetto a grpc_method indicato nel messaggio di avviso. In questo esempio, controlla l'etichetta grpc_code per Watch.

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

    Soluzione temporanea:

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

    1. Silenzia l'avviso dall'interfaccia utente di Alert Manager.
    2. Se la disattivazione dell'avviso non è un'opzione, esamina i seguenti passaggi per eliminare i falsi positivi:
      1. Ridimensiona l'operatore di monitoraggio a 0 repliche in modo che le modifiche possano essere mantenute.
      2. Modifica il configmap 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 il seguente CLUSTER_NAME con il nome del tuo cluster.
      3. Riavvia StatefulSet di Prometheus e Alertmanager per applicare la nuova configurazione.
    3. Se il codice rientra in uno dei casi problematici, controlla il log etcd e il log kube-apiserver per eseguire il debug.
    Networking 1.16.0-1.16.2, 1.28.0

    Le connessioni NAT in uscita potrebbero essere interrotte dopo 5-10 minuti dall'instaurazione di una connessione se non c'è traffico.

    Poiché conntrack è importante solo nella direzione in entrata (connessioni esterne al cluster), questo problema si verifica solo se la connessione non trasmette informazioni per un po' di tempo e poi la parte di destinazione trasmette qualcosa. Se il pod con NAT in uscita crea sempre la messaggistica, questo problema non si verifica.

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


    Soluzione temporanea:

    Non esiste una soluzione semplice e non abbiamo riscontrato problemi nella versione 1.16 derivanti da questo comportamento. Se noti connessioni di lunga durata interrotte a causa di questo problema, le soluzioni alternative consistono nell'utilizzare un carico di lavoro sullo stesso nodo dell'indirizzo IP di uscita o nell'inviare costantemente messaggi sulla connessione TCP.
    Operazione 1.14, 1.15, 1.16

    Se crei una richiesta di firma del certificato (CSR) con expirationSeconds impostato, expirationSeconds viene ignorato.

    Soluzione temporanea:

    Se riscontri questo problema, 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, aggiornamenti 1.16.0-1.16.3

    Se provi a disattivare l'ingresso in bundle per un cluster esistente, il comando gkectl update cluster non va a buon fine e viene visualizzato un errore simile al seguente esempio:

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

    Questo errore si verifica perché gkectl controlla un indirizzo IP in entrata del bilanciamento del carico durante i controlli preliminari. Sebbene questo controllo non sia obbligatorio quando si disattiva l'ingresso in bundle, il controllo preflight gkectl non riesce quando disableBundledIngress è impostato su true.


    Soluzione temporanea:

    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 ulteriori informazioni, scopri come disattivare l'ingresso in bundle per un cluster esistente.
    Upgrade, aggiornamenti 1.13, 1.14, 1.15.0-1.15.6

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

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

    Soluzione temporanea:

    Se riscontri questo problema, 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 checkpoint come origine di riferimento durante l'aggiornamento del cluster. Il file del checkpoint viene comunque aggiornato per un uso futuro.
    Archiviazione 1.15.0-1.15.6, 1.16.0-1.16.2

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

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

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

    Se il pod del workload CSI non viene avviato, viene visualizzato un errore di timeout simile al seguente durante le convalide preliminari:

    - [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 del workload 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 del carico di lavoro CSI non viene avviato a causa dell'inserimento del sidecar Istio, puoi disattivare temporaneamente l'inserimento automatico del sidecar Istio nello spazio dei nomi default. Controlla le etichette dello spazio dei nomi e utilizza il seguente comando per eliminare l'etichetta che inizia con istio.io/rev:

    kubectl label namespace default istio.io/rev-

    Se il pod è configurato in modo errato, verifica manualmente che il provisioning dinamico del volume con il driver CSI vSphere funzioni:

    1. Crea un PVC che utilizzi la classe di archiviazione standard-rwo.
    2. Crea un pod che utilizza il PVC.
    3. Verifica che il pod possa leggere/scrivere dati nel volume.
    4. Rimuovi il pod e il 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 ignorare il controllo del workload CSI.

    Operazione 1.16.0-1.16.2

    Quando accedi a una workstation di amministrazione gestita dall'utente, il comando gkectl update cluster potrebbe scadere e non riuscire ad aggiornare il cluster utente. Ciò si verifica se la versione del cluster di amministrazione è 1.15 ed esegui gkectl update admin prima di eseguire gkectl update cluster. Quando si verifica questo errore, viene visualizzato il seguente messaggio quando provi ad aggiornare il cluster: 

          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, il 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 temporanea:

    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

    Quando accedi a una workstation amministrativa gestita dall'utente, il comando gkectl create cluster potrebbe scadere e non riuscire a creare il cluster utente. Ciò accade se la versione del cluster di amministrazione è 1.15. Quando si verifica questo errore, viene visualizzato il seguente messaggio quando provi a creare il cluster: 

          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 si utilizza il cluster di amministrazione 1.15, manca validation-controller, responsabile dell'attivazione dei controlli preflight. Pertanto, quando si tenta di creare il cluster utente, i controlli preflight rimangono in attesa fino al raggiungimento del timeout.

    Soluzione temporanea:

    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, aggiornamenti 1.16.0-1.16.2

    Quando esegui l'upgrade di un cluster di amministrazione dalla versione 1.15.x alla 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 a onprem-admin-cluster-controller di riconciliare il cluster di amministrazione in un cluster kind. Quando lo stato del cluster di amministrazione viene ripristinato nel cluster kind, il webhook del cluster di amministrazione non può distinguere se l'oggetto OnPremAdminCluster è per la creazione di un cluster di amministrazione o per riprendere le operazioni per un aggiornamento o un upgrade. Alcune convalide di sola creazione vengono richiamate durante l'aggiornamento e l'upgrade in modo imprevisto.


    Soluzione temporanea:

    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 HA con un file 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 HA o il file checkpoint è disattivato: aggiorna o esegui l'upgrade del cluster di amministrazione normalmente. Non sono necessari parametri aggiuntivi nei comandi di aggiornamento.
    Operazione 1.16.0-1.16.2

    Quando accedi a una workstation amministrativa gestita dall'utente, il comando gkectl delete cluster potrebbe scadere e non riuscire a eliminare il cluster utente. Ciò accade se hai eseguito prima gkectl sulla workstation gestita dall'utente per creare, aggiornare o eseguire l'upgrade del cluster utente. Quando si verifica questo errore, viene visualizzato il seguente messaggio quando provi a 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 relativi oggetti. L'eliminazione degli oggetti di convalida (creati durante la creazione, l'aggiornamento o l'upgrade) è bloccata nella fase di eliminazione. Ciò accade perché un finalizer blocca l'eliminazione dell'oggetto, il che causa l'esito negativo dell'eliminazione del cluster.

    Soluzione temporanea:

    1. Ottieni i nomi di tutti gli oggetti Validation: 
               kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
    2. Per ogni oggetto Validation, esegui questo comando per rimuovere il finalizer 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 aver rimosso il finalizer da tutti gli oggetti di convalida, gli oggetti vengono rimossi e l'operazione di eliminazione del cluster utente viene completata automaticamente. Non devi intraprendere ulteriori azioni.

    Networking 1.15, 1.16

    Se il pod di origine e il pod del gateway NAT in uscita si trovano su due nodi worker diversi, il traffico 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 viene stabilita.

    Questo problema è causato da vSphere che elimina i pacchetti VXLAN quando l'aggregazione dei tunnel è abilitata. Esiste un problema noto con NSX e VMware che invia solo traffico aggregato sulle porte VXLAN note (4789).


    Soluzione temporanea:

    Modifica 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 ConfigMap cilium-config: 
      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 del cluster di amministrazione dalla versione 1.14.x alla 1.15.x con crittografia dei secret sempre attiva abilitata non riesce a causa di una mancata corrispondenza tra la chiave di crittografia generata dal controller e la chiave che persiste sul disco di dati master di amministrazione. 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 e viene visualizzato il 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 risolvere il problema dell'upgrade non riuscito:

    1. Disattiva secretsEncryption nel file di configurazione del cluster di amministrazione e aggiorna il cluster utilizzando il seguente comando: 
      gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
    2. Quando viene creata la nuova VM master amministratore, esegui SSH nella VM master amministratore, sostituisci la nuova chiave sul disco di dati con quella precedente dal backup. La chiave si trova in /opt/data/gke-k8s-kms-plugin/generatedkeys sull'amministratore principale.
    3. Aggiorna il file manifest del pod statico 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 e poi riportandolo indietro.
    5. Riprendi l'upgrade dell'amministratore eseguendo di nuovo gkectl upgrade admin.

    Prevenzione dell'errore di 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 i passaggi riportati di seguito prima di eseguire l'upgrade del cluster di amministrazione:

    1. Esegui il backup del cluster di amministrazione.
    2. Disattiva secretsEncryption nel file di configurazione del cluster di amministrazione e aggiorna il cluster utilizzando il seguente comando: 
      gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
    3. Esegui l'upgrade del cluster di amministrazione.
    4. Riabilita la crittografia dei secret sempre attiva.
    Archiviazione 1.11-1.16

    Google Distributed Cloud non supporta il monitoraggio dei 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 Google Distributed Cloud. Per ulteriori informazioni, consulta l'articolo della Knowledge Base di VMware.


    Soluzione temporanea:

    Non eseguire il backup delle VM Google Distributed Cloud, in quanto il software di backup di terze parti potrebbe causare l'attivazione di CBT sui dischi. Non è necessario eseguire il backup di queste VM.

    Non attivare CBT sul nodo, perché questa modifica non verrà mantenuta durante gli aggiornamenti.

    Se disponi già di dischi con CBT abilitato, segui i passaggi della soluzione nell' articolo della Knowledge Base di VMware per disattivare CBT sul disco First Class.
    Archiviazione 1.14, 1.15, 1.16

    Se utilizzi array di archiviazione Nutanix per fornire condivisioni NFSv3 agli host, potresti riscontrare un danneggiamento dei dati o l'impossibilità di eseguire i pod 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.


    Soluzione temporanea:

    L'articolo della Knowledge Base di VMware non è aggiornato e indica che non esiste una soluzione attuale. Per risolvere il problema, esegui l'aggiornamento all'ultima versione di ESXi sugli host e all'ultima versione di Nutanix sugli array di archiviazione.
    Sistema operativo 1.13.10, 1.14.6, 1.15.3

    Per alcune release di Google Distributed Cloud, il kubelet in esecuzione sui nodi utilizza una versione diversa da quella del piano di controllo Kubernetes. Si verifica una mancata corrispondenza perché il binario kubelet precaricato sull'immagine del sistema operativo utilizza una versione diversa.

    La tabella seguente elenca le mancate corrispondenze delle versioni identificate:

    Versione di Google Distributed Cloud Versione kubelet Versione di Kubernetes
    1.13.10 v1.24.11-gke.1200 v1.24.14-gke.2100
    1.14.6 v1.25.8-gke.1500 v1.25.10-gke.1200
    1.15.3 v1.26.2-gke.1001 v1.26.5-gke.2100

    Soluzione temporanea:

    Non è richiesto alcun intervento. L'incoerenza riguarda solo le versioni patch di Kubernetes e non sono stati causati problemi da questa discrepanza di versione.

    Upgrade, aggiornamenti 1.15.0-1.15.4

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

        CAVersion must start from 1

    Soluzione temporanea:

    • Ridimensiona il deployment auto-resize-controller nel cluster di amministrazione per disattivare il ridimensionamento automatico dei nodi. Ciò è necessario perché un nuovo campo introdotto nella risorsa personalizzata del cluster di amministrazione nella versione 1.15 può causare un errore di puntatore nullo 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

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

    Soluzione temporanea:

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

    In caso contrario, segui questi passaggi:

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

    Archiviazione 1.15.0+, 1.16.0+

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


    Soluzione temporanea:

    Modifica ConfigMap della funzionalità vSphere CSI e imposta list-volumes su false:

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

    Riavvia i pod controller CSI vSphere:

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

    Quando un cluster contiene volumi permanenti vSphere in-tree, i comandi gkectl diagnose e gkectl upgrade potrebbero generare avvisi errati relativi alle richieste di volume permanente (PVC) durante la 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 temporanea:

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

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

    Se il campo annotations nell'output contiene quanto segue, puoi ignorare 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, aggiornamenti 1.15.0+, 1.16.0+

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

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

    Soluzione temporanea:

    Innanzitutto, ruota la chiave del account di servizio di accesso ai componenti. Sebbene venga 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

    Durante l'upgrade di un cluster utente, dopo l'upgrade del controller del cluster utente alla versione 1.16, se hai altri cluster utente 1.15 gestiti dallo stesso cluster di amministrazione, la macchina master utente potrebbe essere ricreata in modo imprevisto.

    Esiste un bug nel controller del cluster utente 1.16 che può attivare la ricreazione della macchina master utente 1.15.

    La soluzione alternativa che adotti dipende da come si verifica il problema.

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

    Opzione 1: utilizza una versione 1.16.6+ di GKE on VMware con la correzione.

    Opzione 2: segui questi passaggi:

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

      L'annotazione relativa alla replica è:

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

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

    Opzione 1: utilizza una versione 1.16.6+ di GKE on VMware con la correzione.

    Opzione 2: segui questi passaggi:

    1. Aggiungi il file di informazioni sulla build /etc/cloud/build.info con i seguenti contenuti. In questo modo, i controlli preliminari vengono eseguiti localmente sulla workstation amministrativa anziché sul server. 
      gke_on_prem_version: GKE_ON_PREM_VERSION
       Ad esempio: 
      gke_on_prem_version: 1.16.0-gke.669
    2. Esegui di nuovo 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

    Durante la creazione del cluster, se non specifichi un nome host per ogni indirizzo IP nel file del blocco IP, il controllo preliminare non riesce 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.`

    Esiste un bug nel controllo preliminare che considera il nome host vuoto come duplicato.

    Soluzione temporanea:

    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 ogni indirizzo IP nel file del blocco IP.
    Upgrade, aggiornamenti 1,16

    Per un cluster di amministrazione non ad alta disponibilità e un cluster utente con control plane v1, quando esegui l'upgrade o l'aggiornamento del cluster di amministrazione, la ricreazione della macchina master del cluster di amministrazione potrebbe avvenire contemporaneamente al riavvio della macchina master del cluster utente, il che può causare una race condition. In questo modo, i pod del control plane del cluster utente non possono comunicare con il control plane del cluster di amministrazione, il che causa problemi di collegamento del volume per kube-etcd e kube-apiserver sul control plane del cluster utente.

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

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
     e vedrai gli 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 temporanea:

    1. Accedi tramite SSH al nodo del control plane utente, poiché si tratta di un cluster utente con control plane v1, il nodo del control plane utente si trova nel cluster di amministrazione.
    2. Riavvia kubelet utilizzando il seguente comando: 
          sudo systemctl restart kubelet
      Dopo il riavvio, kubelet può ricostruire correttamente il montaggio globale dello stage.
    Upgrade, aggiornamenti 1.16.0

    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. In questo modo, clusterapi-controller rimane bloccato in attesa della creazione del nodo e alla fine l'upgrade/l'aggiornamento scade. In questo caso, l'output del comando di upgrade/aggiornamento gkectl è 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 riportato di seguito per accedere al log in 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 temporanea:

    1. Riavvia la macchina non riuscita per ricreare l'oggetto nodo eliminato.
    2. Accedi tramite SSH a ogni nodo del control plane e riavvia il pod statico di 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 di upgrade/aggiornamento.
    Operazione 1,16

    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 fornitore nell'oggetto nodo. Ciò causa il timeout dell'upgrade/della creazione del cluster.

    Per identificare il problema, recupera i log del pod 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 con enableControlplaneV2 false: 
            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 con enableControlplaneV2 true: 
            kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system

    Ecco un esempio di messaggio di errore:

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

    Controlla se il nome host è duplicato nel data center:

    Puoi utilizzare il seguente approccio per verificare se il nome host è duplicato ed eseguire 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 e output di esempio: 
              export GOVC_DATACENTER=mtv-lifecycle-vc01
          export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
          export GOVC_USERNAME=xxx
          export GOVC_PASSWORD=yyy
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
          ./vm/gke-admin-node-6b7788cd76-wkt8g
          ./vm/gke-admin-node-6b7788cd76-99sg2
          ./vm/gke-admin-master-5m2jb

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

    Soluzione temporanea per gli upgrade:

    Applica la soluzione alternativa per il tipo di cluster applicabile.

    • Cluster utente:
      1. Aggiorna il nome host della macchina interessata in user-ip-block.yaml con un nome univoco e attiva un aggiornamento forzato:
                  gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
      2. Esegui nuovamente 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 HA e la VM master di amministrazione utilizza un nome host duplicato, devi anche:
        Recuperare il nome della macchina master di amministrazione 
                  kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
        Aggiorna l'oggetto macchina master amministratore
        Nota:NEW_ADMIN_MASTER_HOSTNAME deve essere uguale a quello impostato in admin-ip-block.yaml nel passaggio 1.
                  kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
        Verifica che il nome host sia aggiornato nell'oggetto macchina master amministratore:
                  kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
      3. Esegui di nuovo l'upgrade del cluster di amministrazione con il checkpoint disattivato:
                  gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

    Soluzione alternativa per le installazioni:

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

    Le seguenti operazioni non vanno a buon fine quando il nome utente o la password di vSphere contengono $ o `:

    • Eseguire l'upgrade di un cluster utente 1.15 con Controlplane V2 abilitato alla versione 1.16
    • Aggiornamento di un cluster di amministrazione ad alta disponibilità (HA) 1.15 alla versione 1.16
    • Creazione di un cluster utente 1.16 con Controlplane V2 abilitato
    • Creazione di un cluster di amministrazione HA 1.16

    Utilizza una versione 1.16.4 o successive di Google Distributed Cloud con la correzione o esegui la soluzione alternativa riportata di seguito. La soluzione alternativa che esegui dipende dall'operazione non riuscita.

    Soluzione temporanea 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 di 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 di vCenter nel file di configurazione delle credenziali.
    3. Applica la soluzione alternativa per il tipo di cluster applicabile.
    Archiviazione 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

    Dopo l'eliminazione e la ricreazione di un nodo con lo stesso nome, esiste una piccola possibilità che la creazione di una successiva PersistentVolumeClaim (PVC) non vada a buon fine e venga visualizzato un errore simile al seguente:

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

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


    Soluzione temporanea:

    Riavvia i pod controller CSI vSphere:

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

    Quando esegui il comando gkectl repair admin-master su un cluster di amministrazione HA, 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 temporanea:

    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 VM e filtra in base al nome del cluster di amministrazione.

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

    3. Copia il nome del modello di VM che corrisponde al nome della macchina che stai riparando 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+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0

    Se utilizzi Seesaw come tipo di bilanciatore del carico per il tuo cluster e noti che una VM Seesaw non è attiva o non si avvia, 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 della VM è insufficiente perché fluent-bit in esecuzione sulla VM Seesaw non è configurato con la rotazione dei log corretta.


    Soluzione temporanea:

    Individua i file di log che consumano la maggior parte dello spazio su disco utilizzando du -sh -- /var/lib/docker/containers/* | sort -rh. Pulisci il file di log con le dimensioni maggiori e riavvia la VM.

    Nota: se la VM è completamente inaccessibile, collega il disco a una VM funzionante (ad es. workstation amministrativa), 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, poi esegui systemctl restart docker.fluent-bit.service
    Operazione 1.13, 1.14.0-1.14.6, 1.15

    Quando provi a eseguire l'upgrade (gkectl upgrade admin) o l'aggiornamento (gkectl update admin) di un cluster di amministrazione non ad alta disponibilità con il checkpoint abilitato, l'upgrade o l'aggiornamento potrebbe 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 temporanea:

    Se non riesci a eseguire l'upgrade a una versione patch di Google Distributed Cloud con la correzione, contatta l'assistenza Google per ricevere assistenza.
    Upgrade 1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2

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

        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 lo registri esplicitamente o quando esegui l'upgrade di un cluster utente utilizzando un client API GKE On-Prem.


    Soluzione temporanea:

    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 "Impossibile registrare il cluster". Dopo un po' dovrebbe aggiornarsi automaticamente.
    Upgrade, 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 alla risorsa viene applicata alla risorsa personalizzata OnPremAdminCluster, che non viene conservata durante gli aggiornamenti successivi del cluster di amministrazione a causa dell'utilizzo della chiave di annotazione errata. In questo modo, il cluster di amministrazione potrebbe essere registrato di nuovo per errore nell'API GKE On-Prem.

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


    Soluzione temporanea:

    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 il cluster di amministrazione.
    Networking 1.15.0-1.15.2

    OrderPolicy non viene riconosciuto come parametro e non viene utilizzato. Google Distributed Cloud utilizza sempre Random.

    Questo problema si verifica perché il modello CoreDNS non è stato aggiornato, il che fa sì che orderPolicy venga ignorato.


    Soluzione temporanea:

    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, aggiornamenti 1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

    Determinate condizioni di competizione potrebbero causare un'incoerenza dello stato OnPremAdminCluster tra il checkpoint e il CR effettivo. Quando si verifica il problema, potresti riscontrare il seguente errore durante l'aggiornamento del cluster di amministrazione dopo l'upgrade:

    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 questo problema, devi 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

    Google Distributed Cloud modifica i certificati di amministrazione sui control plane del cluster di amministrazione a ogni processo di riconciliazione, ad esempio durante l'upgrade di un cluster. Questo comportamento aumenta la possibilità di ottenere certificati non validi per il cluster di amministrazione, in particolare per i cluster della versione 1.15.

    Se sei interessato da questo problema, potresti riscontrare problemi come i seguenti:

    • I certificati non validi potrebbero causare il timeout dei seguenti comandi e restituire errori:
      • gkectl create admin
      • gkectl upgrade amdin
      • gkectl update admin

      Questi comandi potrebbero 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 temporanea:

    Esegui l'upgrade a una versione di Google Distributed Cloud con la correzione: 1.13.10+, 1.14.6+, 1.15.2+. Se l'upgrade non è fattibile, contatta l'assistenza clienti Google Cloud per risolvere il problema.
    Networking, Operation 1.10, 1.11, 1.12, 1.13, 1.14

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

    $ 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 espulsione o l'impossibilità di pianificare i pod a causa delle risorse del nodo. Poiché i pod Anthos Network Gateway non hanno PriorityClass, hanno la stessa priorità predefinita degli altri workload. Quando i nodi sono vincolati dalle risorse, i pod del gateway di rete potrebbero essere eliminati. Questo comportamento è particolarmente dannoso per il DaemonSet ang-node, poiché questi pod devono essere pianificati su un nodo specifico e non possono essere migrati.


    Soluzione temporanea:

    Esegui l'upgrade alla versione 1.15 o successive.

    Come soluzione a breve termine, puoi assegnare manualmente una PriorityClass ai componenti di Anthos Network Gateway. Il controller Google Distributed Cloud sovrascrive queste modifiche manuali durante una procedura di riconciliazione, ad esempio durante un upgrade del cluster.

    • Assegna PriorityClass system-cluster-critical ai deployment dei controller dei cluster ang-controller-manager e autoscaler.
    • Assegna system-node-critical PriorityClass al DaemonSet del nodo ang-daemon.
    Upgrade, aggiornamenti 1.12, 1.13, 1.14, 1.15.0-1.15.2

    Dopo aver utilizzato gcloud per registrare un cluster di amministrazione con una sezione gkeConnect non vuota, potresti visualizzare il seguente errore quando tenti 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
     Recupera il nome del cluster di amministrazione: 
    kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
     Elimina l'abbonamento 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 eseguiti sui nodi del cluster

    Ciò non influisce sulla funzionalità di creazione di uno snapshot del cluster, in quanto lo snapshot include comunque tutti i log raccolti per impostazione predefinita eseguendo journalctl sui nodi del cluster. Pertanto, non vengono perse informazioni di debug.
    Installazione, upgrade, aggiornamenti 1.9+, 1.10+, 1.11+, 1.12+

    gkectl prepare windows non riesce a installare Docker sulle versioni di Google Distributed Cloud precedenti alla 1.13 perché MicrosoftDockerProvider è deprecato.


    Soluzione temporanea:

    L'idea generale per risolvere questo problema è eseguire l'upgrade a Google Distributed Cloud 1.13 e utilizzare gkectl 1.13 per creare un modello di VM Windows e poi creare node pool Windows. Esistono due opzioni per passare a Google Distributed Cloud 1.13 dalla tua versione attuale, come mostrato di seguito.

    Nota:nella tua versione attuale sono disponibili opzioni per risolvere questo problema senza dover eseguire l'upgrade alla versione 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 Google Distributed Cloud versione 1.13+ con pool di nodi Windows ed eseguire la migrazione dei carichi di lavoro al nuovo cluster, quindi eliminare il cluster attuale. Ti consigliamo di utilizzare l'ultima versione secondaria di Google Distributed Cloud.

    Nota:per eseguire il provisioning del nuovo cluster saranno necessarie risorse aggiuntive, ma i tempi di inattività e le interruzioni per i carichi di lavoro esistenti saranno inferiori.


    Opzione 2: elimina i pool di nodi Windows e aggiungili di nuovo durante l'upgrade a Google Distributed Cloud 1.13

    Nota:per questa opzione, i workload Windows non potranno essere eseguiti finché il cluster non verrà aggiornato alla versione 1.13 e non verranno aggiunti di nuovo i node pool Windows.

    1. Elimina i node pool Windows esistenti rimuovendo la configurazione dei node pool 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 di amministrazione e utente solo Linux alla versione 1.12 seguendo la guida all'upgrade per la 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 in OnPremUserCluster CR, altrimenti il cluster continuerà a utilizzare Docker per i node pool Windows, che non saranno compatibili con il modello di VM Windows 1.13 appena creato in cui non è installato Docker. Se non è configurato o è impostato su false, aggiorna il cluster impostandolo 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 di amministrazione e utente solo Linux alla versione 1.13 seguendo la guida all'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, aggiornamenti 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    Il valore predefinito di 5 secondi per RootDistanceMaxSec verrà utilizzato sui nodi, 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 trovare 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 deriva dell'orologio è superiore a 5 secondi.


    Soluzione temporanea:

    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, aggiornamenti 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Quando utilizzi la versione 1.13 gkectl per aggiornare un cluster di amministrazione 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, potresti visualizzare il seguente messaggio nella risposta:

    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 multiple includono l'impostazione di osImageType da una stringa vuota a ubuntu_containerd.

    Questi errori di aggiornamento sono dovuti al riempimento improprio del campo osImageType nella configurazione del cluster di amministrazione, poiché è stato introdotto nella versione 1.9.


    Soluzione temporanea:

    Esegui l'upgrade a una versione di Google Distributed Cloud con la correzione. Se l'upgrade non è fattibile per te, contatta l'assistenza clienti Google Cloud per risolvere il problema.
    Installazione, sicurezza 1.13, 1.14, 1.15, 1.16

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


    Soluzione temporanea:

    Finché non sarà disponibile una patch di Google Distributed Cloud con la correzione, se devi utilizzare SNI, disattiva 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

    L'avvio della macchina del control plane amministrativo non riesce quando il nome utente del registro privato contiene $. Quando controlli /var/log/startup.log sulla macchina del control plane amministrativo, visualizzi il seguente errore: 

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

    Soluzione temporanea:

    Utilizza un nome utente del registro privato senza $ oppure utilizza una versione di Google Distributed Cloud con la correzione.
    Upgrade, aggiornamenti 1.12.0-1.12.4

    Quando aggiorni i cluster di amministrazione, nel log vengono visualizzati 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, aggiornamenti 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    Dopo aver ruotato le chiavi di firma KSA e successivamente aggiornato 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 temporanea:

    Riporta la versione della chiave di firma KSA alla versione 1, ma mantieni 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 ksa-signing-key e assegna al secret copiato il nome 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 ksa-signing-key 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 a '{"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 a 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 di utenti di destinazione sia pronto. Puoi controllare lo stato in questo modo: 
      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é il cluster non viene aggiornato alla versione con la correzione.
    Operazione 1.13.1+, 1.14, 1., 1,16

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


    Soluzione temporanea:

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

    Installazione, upgrade, aggiornamenti 1.13.8, 1.14.4

    Se crei un cluster di amministrazione versione 1.13.8 o 1.14.4 oppure esegui l'upgrade di un cluster di amministrazione alla versione 1.13.8 o 1.14.4, il cluster kind 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 a visualizzare il cluster kind. L'esecuzione del seguente comando 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 le seguenti:

    ...
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 cluster kind. Tuttavia, la versione 0.18.0 di kind presenta un problema con le immagini container precaricate, che vengono estratte da internet per errore.


    Soluzione temporanea:

    Esegui i seguenti comandi 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

    Se le VM del cluster sono connesse a uno switch che filtra le richieste GARP (gratuitous ARP) duplicate, la selezione del leader di keepalived potrebbe riscontrare unarace conditione, che causa l'inserimento di voci errate nella tabella ARP di alcuni nodi.

    I nodi interessati possono ping il VIP del control plane, ma una connessione TCP al VIP del control plane scadrà.


    Soluzione temporanea:

    Esegui questo comando su ogni nodo del control plane del cluster interessato: 
        iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    Upgrade, aggiornamenti 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    vsphere-csi-controller deve aggiornare il segreto di 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 temporanea:

    Per i cluster creati con la 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

    Anche quando la registrazione del cluster non riesce durante la creazione del cluster di amministrazione, il comando gkectl create admin non genera errori e potrebbe essere eseguito correttamente. 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 nella console Google Cloud.

    Soluzione temporanea:

    Per i cluster creati nelle versioni 1.12 e successive, segui le istruzioni per riprovare la registrazione del cluster di amministrazione dopo la creazione del cluster. Per i cluster creati nelle versioni precedenti,

    1. Aggiungi una coppia chiave-valore fittizia come "foo: bar" al file della chiave SA connect-register
    2. Esegui gkectl update admin per registrare nuovamente il cluster di amministrazione.

    Upgrade, aggiornamenti 1.10, 1.11, 1.12, 1.13.0-1.13.1

    Durante l'upgrade del cluster di amministrazione, se l'upgrade dei nodi del control plane utente scade, il cluster di amministrazione non verrà registrato nuovamente con la versione aggiornata dell'agente Connect.


    Soluzione temporanea:

    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 riprovare la registrazione. Per i cluster di cui è stato eseguito l'upgrade alla versione 1.12 e successive, segui le istruzioni per riprovare la registrazione del cluster di amministrazione dopo la creazione del cluster. Per i cluster di cui è stato eseguito l'upgrade a versioni precedenti,
    1. Aggiungi una coppia chiave-valore fittizia come "foo: bar" al file della chiave SA connect-register
    2. Esegui gkectl update admin per registrare nuovamente il cluster di amministrazione.

    Configurazione 1.15.0

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

    vCenter.dataDisk must be present in the AdminCluster spec

    Soluzione temporanea:

    Puoi ignorare questo messaggio di errore.
    VMware 1.15.0

    Durante la creazione di un pool di nodi che utilizza l'affinità VM-host, una race condition potrebbe comportare la creazione di più regole di affinità VM-host con lo stesso nome. Ciò può causare un errore di creazione pool di nodi.


    Soluzione temporanea:

    Rimuovi le vecchie regole ridondanti in modo che la creazione pool di nodi possa procedere. Queste regole sono denominate [USER_CLUSTER_NAME]-[HASH].
    Operazione 1.15.0

    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 temporanea:

    Questo comando è idempotente. Può essere eseguito di nuovo in sicurezza finché il comando non ha esito positivo.
    Upgrade, aggiornamenti 1.15.0

    Dopo aver ricreato o aggiornato un nodo del control plane, alcuni pod potrebbero rimanere nello stato Failed a causa dell'errore del predicato NodeAffinity. Questi pod in errore non influiscono sul normale funzionamento o sull'integrità del cluster.


    Soluzione temporanea:

    Puoi ignorare tranquillamente i pod non riusciti o eliminarli manualmente.
    Sicurezza, configurazione 1.15.0-1.15.1

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

    failed to check secret reference for private registry …


    Soluzione temporanea:

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

    Upgrade, aggiornamenti 1.15.0

    Durante gkectl upgrade admin, il controllo preliminare dello spazio di archiviazione per la migrazione CSI verifica che le StorageClass non abbiano parametri ignorati dopo la migrazione CSI. Ad esempio, se esiste una StorageClass con il parametro diskformat, allora gkectl upgrade admin contrassegna la StorageClass e segnala un errore nella convalida preliminare. I cluster di amministrazione creati in Google Distributed Cloud 1.10 e versioni precedenti hanno una StorageClass con diskformat: thin che non supererà questa convalida, ma questa StorageClass funziona correttamente dopo la migrazione CSI. Questi errori devono essere interpretati come avvisi.

    Per maggiori informazioni, consulta la sezione relativa al parametro StorageClass in Migrazione dei volumi vSphere in-tree al plug-in vSphere Container Storage.


    Soluzione temporanea:

    Dopo aver verificato che il cluster ha una StorageClass con parametri ignorati dopo la migrazione CSI, esegui gkectl upgrade admin con il flag --skip-validation-cluster-health.
    Archiviazione 1.15, 1.16

    In determinate condizioni, i dischi possono essere collegati in modalità di sola lettura ai nodi Windows. Di conseguenza, il volume corrispondente è di sola lettura all'interno di un pod. Questo problema si verifica più facilmente quando un nuovo insieme di nodi sostituisce un insieme di nodi precedente (ad esempio, upgrade del cluster o aggiornamento del pool di nodi). I workload stateful che prima funzionavano correttamente potrebbero non essere in grado di scrivere nei volumi sul nuovo insieme di nodi.


    Soluzione temporanea:

    1. Ottieni l'UID del pod che non riesce a scrivere nel suo volume: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Utilizza PersistentVolumeClaim per ottenere il nome di PersistentVolume: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Determina il nome del nodo in cui è in esecuzione il pod: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Ottieni l'accesso a 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 associato a 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, se il pod viene pianificato su un nuovo nodo, potresti dover ripetere i passaggi precedenti sul nuovo nodo.

    Upgrade, 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 l'aggiornamento delle credenziali del cluster, potresti notare che vsphere-csi-secret nello spazio dei nomi kube-system del cluster di amministrazione utilizza ancora le vecchie credenziali.


    Soluzione temporanea:

    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 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
       Una volta eseguito correttamente il deployment, il controller deve utilizzare vsphere-csi-secret aggiornato.
    Upgrade, 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 potrebbe andare in crash loop a causa di --cluster-name vuoto. Questo comportamento è causato da un bug nella logica di aggiornamento, in cui il nome del cluster non viene propagato al manifest del pod / container audit-proxy.


    Soluzione temporanea:

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

    Per un cluster utente con control plane v1, modifica il container audit-proxy nel kube-apiserver statefulset per aggiungere --cluster_name=USER_CLUSTER_NAME:

    kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
    Upgrade, aggiornamenti 1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1

    Subito dopo gkectl upgrade cluster, i pod del control plane potrebbero essere nuovamente sottoposti a deployment. Lo stato del cluster da gkectl list clusters è cambiato da RUNNING a RECONCILING. Le richieste al cluster utente potrebbero scadere.

    Questo comportamento è dovuto alla rotazione automatica del certificato del control plane dopo gkectl upgrade cluster.

    Questo problema si verifica solo per i cluster utente che NON utilizzano il control plane v2.


    Soluzione temporanea:

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

    Google Distributed Cloud 1.12.7-gke.19 è una release non valida e non devi utilizzarla. Gli artefatti sono stati rimossi dal bucket Cloud Storage.

    Soluzione temporanea:

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

    Se aggiorni le credenziali del registro utilizzando uno dei seguenti metodi:

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

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

    Questo problema verrà risolto nelle release 1.13.8, 1.14.4 e successive di Google Distributed Cloud.


    Soluzione temporanea:

    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 nuovamente il deployment di gke-connect-agent con la chiave del account di servizio di registrazione 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 segreto 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 pull dell'immagine predefinita per il tuo cluster nel deployment di gke-connect-agent:

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

    Quando con gkectl check-config convalidi la configurazione prima di creare un cluster con il bilanciatore del carico manuale, il comando non riesce e vengono visualizzati 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 temporanea:

    Opzione 1: puoi 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 saltare 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

    I cluster che eseguono etcd versione 3.4.13 o precedente potrebbero riscontrare problemi di carenza di risorse di monitoraggio e di monitoraggio non operativo, il che può portare ai seguenti problemi:

    • La pianificazione dei pod viene interrotta
    • I nodi non possono registrarsi
    • 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 Google Distributed Cloud. Queste versioni più recenti utilizzano etcd versione 3.4.21. Tutte le versioni precedenti di Google Distributed Cloud sono interessate da questo problema.

    Soluzione temporanea

    Se non puoi eseguire l'upgrade immediatamente, puoi mitigare il rischio di errore del cluster riducendo il numero di nodi nel cluster. Rimuovi nodi finché 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 Esplora metriche

    2. Seleziona la scheda Configurazione.
    3. Espandi Seleziona una metrica, inserisci Kubernetes Container nella barra dei filtri e 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, aggiornamenti 1.10, 1.11, 1.12, 1.13 e 1.14

    In caso di riavvii o upgrade del cluster, GKE Identity Service può essere sommerso da traffico costituito da token JWT scaduti inoltrati da kube-apiserver a GKE Identity Service tramite l'webhook di autenticazione. Anche se GKE Identity Service non va in crashloop, non risponde più e smette di gestire ulteriori richieste. Questo problema alla fine porta a latenze più elevate del control plane.

    Questo problema è stato risolto nelle seguenti release di Google Distributed Cloud:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    Per determinare se il problema ti riguarda, segui questi passaggi:

    1. Verifica se l'endpoint di GKE Identity Service è raggiungibile 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 control plane e la porta del bilanciatore del carico del control plane per il tuo cluster (ad esempio, 172.16.20.50:443).

      Se il problema ti riguarda, il comando restituisce un codice di stato 400. Se la richiesta scade, riavvia il pod ais e riesegui il comando curl per verificare se il problema viene risolto. Se ricevi un codice di stato 000, il problema è stato risolto e non devi fare altro. Se continui a ricevere 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 come la seguente, 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 di kube-apiserver per i tuoi cluster:

        Nei seguenti comandi, KUBE_APISERVER_POD è il nome del pod kube-apiserver sul 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 le seguenti, allora il 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 temporanea

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

    1. Aumenta il livello di verbosità di GKE Identity Service 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 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 di 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 e lo spazio dei nomi del pod di origine, copia il token nel debugger all'indirizzo jwt.io.
    5. Riavvia i pod identificati dai token.
    Operazione 1.8, 1.9, 1.10

    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 deframmentazione e le vecchie connessioni non vengono pulite.


    Soluzione temporanea:

    Opzione 1: esegui l'upgrade all'ultima versione della patch dalla 1.8 alla 1.11, che contiene la correzione.

    Opzione 2: se utilizzi una versione patch precedente alla 1.9.6 e alla 1.10.3, devi ridurre lo scale 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

    Sia il controller di integrità del cluster sia il comando gkectl diagnose cluster eseguono una serie di controlli di integrità, inclusi i controlli di integrità dei pod tra gli spazi dei nomi. Tuttavia, iniziano a ignorare per errore i pod del control plane utente. Se utilizzi la modalità control plane v2, questa operazione non influirà sul tuo cluster.


    Soluzione temporanea:

    Ciò non influirà sulla gestione di carichi di lavoro o cluster. Se vuoi controllare l'integrità dei pod del control plane, puoi eseguire i seguenti comandi:

    kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Upgrade, aggiornamenti 1.6+, 1.7+

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

    Kubernetes ha reindirizzato il traffico da k8s.gcr.io a registry.k8s.io il 20/03/2023. In Google Distributed Cloud 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 amministrativa e il proxy non consente registry.k8s.io e l'immagine container k8s.gcr.io/pause:3.2 non è memorizzata nella cache locale, gli upgrade del cluster di amministrazione non riusciranno durante il pull dell'immagine container.


    Soluzione temporanea:

    Aggiungi registry.k8s.io alla lista consentita del proxy per la workstation amministrativa.
    Networking 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    gkectl create loadbalancer non riesce con 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 all'esistenza del file del gruppo altalena. e il controllo preliminare tenta di convalidare un bilanciatore del carico Seesaw inesistente.

    Soluzione temporanea:

    Rimuovi il file del gruppo altalena 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

    Google Distributed Cloud versione 1.14 è soggetto a errori di inserimento della tabella di monitoraggio delle connessioni (conntrack) di netfilter 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 al kernel 5.15 e versioni successive che limitano gli inserimenti di tabelle in base alla lunghezza della catena.

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

    sudo conntrack -S

    La risposta è simile alla seguente:

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

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

    Soluzione temporanea

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

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

    Sostituisci TABLE_SIZE con le nuove dimensioni in byte. Il valore predefinito per la dimensione della tabella è 262144. Ti consigliamo 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

    Con Controlplane V2 abilitato, calico-typha o anetd-operator potrebbero essere pianificati per i nodi Windows ed entrare in un ciclo di arresti anomali.

    Il motivo è che i due deployment tollerano tutti i taint, incluso il taint del nodo Windows.


    Soluzione temporanea:

    Esegui l'upgrade alla versione 1.13.3 o successive oppure esegui i seguenti comandi per modificare il deployment di `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 i seguenti 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

    Potresti non riuscire a creare un cluster di utenti se specifichi la sezione privateRegistry con le credenziali fileRef. Il controllo preliminare potrebbe non riuscire con il seguente messaggio: 

    [FAILURE] Docker registry access: Failed to login.


    Soluzione temporanea:

    • Se non intendevi specificare il campo o vuoi utilizzare le stesse credenziali 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 tuo 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
       (NOTE: questa è solo una correzione temporanea e questi campi sono già deprecati. Ti consigliamo di utilizzare il file delle credenziali quando esegui l'upgrade alla versione 1.14.3 o successive.)

    Operazioni 1.10+

    Dataplane V2 assume il controllo del bilanciamento del carico e crea un socket del kernel anziché un DNAT basato su pacchetti. Ciò significa che Cloud Service Mesh non può eseguire l'ispezione dei pacchetti perché il pod viene ignorato e non utilizza mai IPTables.

    Ciò si manifesta in modalità gratuita di kube-proxy con la perdita di connettività o un routing del traffico errato per i servizi con Cloud Service Mesh, poiché il sidecar non può eseguire l'ispezione dei pacchetti.

    Questo problema è presente in tutte le versioni di Google Distributed Cloud 1.10, ma alcune versioni più recenti di 1.10 (1.10.2+) hanno una soluzione alternativa.


    Soluzione temporanea:

    Esegui l'upgrade alla versione 1.11 per la piena compatibilità oppure, se utilizzi la versione 1.10.2 o successive, esegui:

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

    Aggiungi bpf-lb-sock-hostns-only: true a configmap e poi riavvia il daemonset anetd:

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

    Archiviazione 1.12+, 1.13.3

    kube-controller-manager potrebbe scadere con timeout durante il distacco di PV/PVC dopo 6 minuti e forzare il distacco di PV/PVC. 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 i seguenti comandi:

    # See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    Nel log di kubelet vengono visualizzati errori simili ai 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 temporanea:

    Connettiti al nodo interessato utilizzando SSH e riavvialo.
    Upgrade, aggiornamenti 1.12+, 1.13+, 1.14+

    Potresti non riuscire ad 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 temporanea:

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

    Il nodo master amministratore creato tramite gkectl repair admin-master potrebbe utilizzare una versione hardware della VM inferiore a quella prevista. 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 temporanea:

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

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

    Ad esempio, potresti notare i seguenti sintomi.

    • L'interfaccia utente 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
    • Impossibile avviare i nuovi nodi 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 temporanea:

    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 in caso di 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, aggiornamenti 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

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

    Dopo l'upgrade di un cluster 1.11.x alla versione 1.12.x, il campo component-access-sa-key nel secret admin-cluster-creds verrà cancellato e sarà vuoto. Puoi verificarlo eseguendo questo comando: 

    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 di quelli esistenti non andrà a buon fine. Di seguito sono elencati alcuni messaggi di errore che potresti visualizzare:

    • Errore di 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."
    • Prepare by gkectl prepare non riuscito, 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 va a buon fine 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 temporanea:

    Aggiungi di nuovo manualmente la chiave del account di servizio di accesso ai componenti al 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+, 1.14.0+

    Per i cluster utente creati con Controlplane V2 abilitato, i node pool con la scalabilità automatica abilitata utilizzano sempre il autoscaling.minReplicas in user-cluster.yaml. Il log del pod cluster-autoscaler mostra un errore simile al seguente: 

      > 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 del cluster può essere trovato eseguendo i seguenti comandi. 
      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


    Soluzione temporanea:

    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

    Quando gli utenti utilizzano CIDR nel file di blocco IP, la convalida della configurazione non riesce e viene visualizzato il seguente errore: 

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


    Soluzione temporanea:

    Includi singoli IP nel file di blocco IP fino all'upgrade a una versione con la correzione: 1.12.5, 1.13.4, 1.14.1+.
    Upgrade, aggiornamenti 1.14.0-1.14.1

    Quando Aggiorni il tipo di immagine del sistema operativo del control plane in admin-cluster.yaml e se il cluster utente corrispondente è stato creato con enableControlplaneV2 impostato su true, le macchine del control plane utente potrebbero non completare la ricreazione al termine del comando gkectl.


    Soluzione temporanea:

    Al termine dell'aggiornamento, continua ad attendere il completamento della ricreazione delle macchine del piano di controllo utente monitorando i tipi di immagini del sistema operativo dei nodi utilizzando kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Ad esempio, se esegui l'aggiornamento da Ubuntu a COS, devi attendere che tutte le macchine del control plane 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

    Un problema con Calico in Google Distributed Cloud 1.14.0 causa l'errore di creazione ed eliminazione dei pod con il seguente messaggio di errore nell'output di kubectl describe pods:

      error getting ClusterInformation: connection is unauthorized: Unauthorized

    Questo problema si verifica 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 file 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 temporanea:

    Questo problema è stato risolto nella versione 1.14.1 di Google Distributed Cloud. Esegui l'upgrade a questa o a una versione successiva.

    Se non puoi eseguire l'upgrade immediatamente, applica la seguente patch al DaemonSet calico-node nel cluster di amministrazione e nel cluster 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 creazione del cluster non va a buon fine nonostante l'utente disponga della configurazione corretta. L'utente vede la creazione non riuscita perché il cluster non ha IP sufficienti.


    Soluzione temporanea:

    Dividi 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é sono presenti N+1 CIDR, dove N è il numero di nodi nel cluster, questo dovrebbe essere sufficiente.

    Funzionamento, upgrade, aggiornamenti 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

    Quando la funzionalità di crittografia dei secret sempre attiva è 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 amministratore con questo backup utilizzando gkectl repair admin-master --restore-from-backup genera 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

    Funzionamento, upgrade, aggiornamenti 1.10+

    Se la funzionalità di crittografia dei secret sempre attiva non è abilitata al momento della creazione del cluster, ma viene abilitata in un secondo momento utilizzando l'operazione gkectl update, gkectl repair admin-master non riesce a riparare il nodo del control plane 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 è disponibile alcuna mitigazione.

    Upgrade, aggiornamenti 1,10

    L'upgrade del primo cluster utente dalla versione 1.9 alla 1.10 potrebbe ricreare i nodi in altri cluster utente nello stesso cluster di amministrazione. La ricreazione viene eseguita in modo continuo.

    disk_label è stato rimosso da MachineTemplate.spec.template.spec.providerSpec.machineVariables, il che ha attivato un aggiornamento imprevisto su tutti i MachineDeployment.


    Soluzione temporanea:
    Upgrade, aggiornamenti 1.10.0

    L'upgrade del cluster utente alla versione 1.10.0 potrebbe causare riavvii frequenti di Docker.

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

    Una condizione del nodo mostrerà se il riavvio di Docker è frequente. 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 temporanea:
    Upgrade, aggiornamenti 1.11, 1.12

    Se utilizzi una versione di Google Distributed Cloud precedente alla 1.12 e hai configurato manualmente i componenti Prometheus gestito 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 GMP nello spazio dei nomi gmp-system e le CRD sono gestiti dall'oggetto stackdriver, con il flag enableGMPForApplications impostato su false per impostazione predefinita. Se esegui il deployment manuale dei componenti GMP nello spazio dei nomi prima dell'upgrade alla versione 1.12, le risorse verranno eliminate da stackdriver.


    Soluzione temporanea:
    Operazione 1.11, 1.12, 1.13.0 - 1.13.1

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

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


    Soluzione temporanea:

    Puoi eseguire manualmente i seguenti comandi 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, aggiornamenti 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    Quando elimini, aggiorni o esegui 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 nel cluster utente.

    Per identificare il sintomo, esegui il comando riportato di seguito:

    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 di vSphere. Quando non vengono creati oggetti PVC/PV, potresti riscontrare un bug per cui lo svuotamento del nodo rimane bloccato alla ricerca di kubevols, poiché l'implementazione attuale presuppone che kubevols esista sempre.


    Soluzione temporanea:

    Crea la directory kubevols nel datastore in cui viene creato il nodo. Questo valore è definito nel campo vCenter.datastore dei 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

    Quando viene eliminato un cluster utente, vengono eliminati anche clusterrole e clusterrolebinding corrispondenti per il gestore della scalabilità automatica del cluster. Ciò 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 del 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 temporanea:

    Configurazione 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    Quando viene eliminato un cluster utente, viene eliminato anche il corrispondente clusterrole, il che comporta la mancata funzionalità di riparazione automatica e dell'esportatore di 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 temporanea:

    Configurazione 1.12.1-1.12.3, 1.13.0-1.13.2

    Un problema noto che potrebbe causare l'esito negativo di gkectl check-config senza eseguire gkectl prepare. Questo è fuorviante perché suggeriamo di eseguire il comando prima di eseguire gkectl prepare

    Il sintomo è che il comando gkectl check-config non andrà a buon fine e verrà visualizzato 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 temporanea:

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

    Opzione 2: utilizza gkectl check-config --skip-validation-os-images per ignorare la convalida delle immagini del sistema operativo.
    Upgrade, aggiornamenti 1.11, 1.12, 1.13

    Un problema noto che potrebbe causare errori durante l'aggiornamento di anti affinity groups.gkectl update admin/cluster

    Il sintomo è che il comando gkectl update non andrà a buon fine e verrà visualizzato 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 temporanea:
    Installazione, upgrade, aggiornamenti 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

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

    Per visualizzare le richieste 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 contenitore 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
       where:
      • ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del cluster di amministrazione.
      • USER_CLUSTER_NAME è il nome del cluster di utenti.
      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 di 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, tutti i caratteri successivi al primo punto verranno ignorati. Ad esempio, se specifichi il nome host come bob-vm-1.bank.plc, il nome host della VM e il nome del nodo verranno impostati su bob-vm-1.

    Quando la verifica dell'ID nodo è abilitata, l'approvatore della CSR confronta il nome del nodo con il nome host nella specifica della macchina e non riesce a riconciliare il nome. L'approvatore rifiuta la CSR e il nodo non riesce a eseguire il bootstrap.


    Soluzione temporanea:

    Cluster di utenti

    Disattiva 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 il comando seguente: 
      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 control plane del cluster di amministrazione:
      1. Accedi tramite SSH al nodo del control plane del cluster di amministrazione.
      2. Apri il manifest kube-controller-manager per la modifica: 
        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 del cluster di deployment 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, aggiornamenti 1.11.0-1.11.4

    La creazione/l'upgrade del cluster di amministrazione è bloccata al seguente log per sempre e alla fine si verifica il timeout:

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

    Nella versione 1.11 della documentazione, il log del controller dell'API Cluster nell' istantanea del cluster esterno include il seguente log:

    Invalid value 'XXXX' specified for property startup-data

    Di seguito è riportato 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

    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à del piano dati non è interessata.

    La contesa sull'oggetto networkgatewaygroup causa il mancato aggiornamento di alcuni stati a causa di un errore nella gestione dei nuovi tentativi. Se troppi aggiornamenti di stato non vanno a buon fine, ang-controller-manager considera il nodo come scaduto il limite di tempo del battito cardiaco e lo contrassegna come NotHealthy.

    Il problema nella gestione dei nuovi tentativi è stato risolto nelle versioni successive.


    Soluzione temporanea:

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

    Un problema noto che potrebbe causare il blocco dell'upgrade o dell'aggiornamento del cluster in attesa dell'eliminazione del vecchio oggetto macchina. Questo perché il finalizer non può essere rimosso dall'oggetto macchina. Ciò influisce su qualsiasi operazione di aggiornamento in sequenza per i node pool.

    Il sintomo è che il comando gkectl va in timeout 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 simili a quelli 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 per la stessa macchina per diversi minuti per le esecuzioni riuscite anche senza questo problema. Per la maggior parte del tempo, l'errore può essere risolto rapidamente, ma in alcuni rari casi può rimanere bloccato in questa condizione di competizione per diverse ore.

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


    Soluzione temporanea:

    Abbiamo preparato diverse opzioni di mitigazione per questo problema, a seconda dell'ambiente e dei requisiti.

    • Opzione 1: attendi il completamento dell'upgrade.

      In base all'analisi e alla riproduzione nel tuo ambiente, l'upgrade può essere completato automaticamente senza alcun intervento manuale. L'avvertenza di questa opzione è che non è certo quanto tempo ci vorrà per l'eliminazione del finalizzatore per ogni oggetto macchina. Se hai fortuna, può essere completato immediatamente, altrimenti potrebbe durare diverse ore se la riconciliazione del controller del set di macchine è troppo veloce e il controller della macchina non ha mai la possibilità di rimuovere il finalizer tra le riconciliazioni.

      Il vantaggio è che questa opzione non richiede alcun intervento da parte tua e i carichi di lavoro non verranno interrotti. È necessario più tempo per completare l'upgrade.
    • Opzione 2: applica l'annotazione di riparazione automatica a tutti gli oggetti macchina 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 emettere chiamate di eliminazione su queste macchine, il che può contribuire a evitare la race condition.

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

      Il comando per ottenere tutti i nomi delle 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 l'upgrade o l'aggiornamento non riesce ancora a completarsi dopo molto tempo, contatta il nostro team di assistenza per soluzioni.
    Installazione, upgrade, aggiornamenti 1.10.2, 1.11, 1.12, 1.13

    Il 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 temporanea:

    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

    La creazione del cluster di amministrazione non è riuscita con il seguente errore:

    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 segreta, che non supporta "/" o ":".


    Soluzione temporanea:

    Rimuovi il prefisso https:// o http:// dal campo vCenter.Address nel file YAML di configurazione del cluster di amministrazione o del cluster utente.
    Installazione, upgrade, aggiornamenti 1.10, 1.11, 1.12, 1.13

    gkectl prepare può generare un errore irreversibile con la seguente stacktrace:

    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 temporanea:

    Per risolvere il problema, esegui i seguenti comandi 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, aggiornamenti 1.10, 1.11, 1.12, 1.13

    Dopo un tentativo di upgrade del cluster di amministrazione non riuscito, non eseguire gkectl repair admin-master. In questo modo, i successivi tentativi di upgrade dell'amministratore potrebbero non riuscire a causa di problemi quali l'accensione del master amministratore non riuscita o l'inaccessibilità della VM.


    Soluzione temporanea:

    Se hai già riscontrato questo scenario di errore, contatta l'assistenza.
    Upgrade, aggiornamenti 1.10, 1.11

    Se la macchina del control plane di amministrazione non viene ricreata dopo un tentativo di upgrade del cluster di amministrazione ripreso, il modello di VM del control plane di amministrazione viene eliminato. Il modello di VM del control plane di amministrazione è il modello del master di amministrazione utilizzato per recuperare la macchina del control plane con gkectl repair admin-master.


    Soluzione temporanea:

    Il modello di VM del control plane di amministrazione verrà rigenerato durante il successivo upgrade del cluster di amministrazione.
    Sistema operativo 1.12, 1.13

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


    Soluzione temporanea:

    Nella versione 1.12.1 siamo tornati a cgroup v1 (ibrido). 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

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


    Soluzione temporanea:

    Ti consigliamo vivamente di eseguire il backup della risorsa ClientConfig dopo ogni modifica manuale.
    Installazione 1.10, 1.11, 1.12, 1.13

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

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


    Soluzione temporanea:

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

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

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

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

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

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

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

    Soluzione temporanea:
    VMware 1.10, 1.11, 1.12, 1.13

    Se vCenter, per le versioni precedenti alla 7.0U2, viene riavviato dopo un upgrade o altro, il nome della rete nelle informazioni della VM di vCenter è errato e la macchina si trova in uno stato Unavailable. Ciò alla fine porta alla riparazione automatica dei nodi per crearne di nuovi.

    Related govmomi bug.


    Soluzione temporanea:

    Questa soluzione alternativa è fornita dall'assistenza 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 poi seleziona Connessione > Disconnetti. Quindi, riconnettiti, il che forza un aggiornamento del gruppo di porte della VM.
    Sistema operativo 1.10, 1.11, 1.12, 1.13

    Per Google Distributed Cloud versione 1.7.2 e successive, le immagini del sistema operativo Ubuntu sono protette con il benchmark del server CIS L1.

    Per soddisfare la regola CIS "5.2.16 Ensure SSH Idle Timeout Interval is configured", /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 un comportamento imprevisto. Quando utilizzi la sessione SSH sulla workstation amministrativa o su un nodo del cluster, la connessione SSH potrebbe essere interrotta anche se il client SSH non è inattivo, ad esempio quando esegui un comando che richiede molto tempo e il comando potrebbe essere terminato con il seguente messaggio:

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

    Soluzione temporanea:

    Puoi:

    • Utilizza nohup per impedire la terminazione del comando in caso di 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

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

    Devi applicare questa soluzione alternativa una sola volta per ogni cluster e le modifiche verranno mantenute durante l'upgrade del cluster.

    Nota: un sintomo comune dell'installazione di un proprio cert-manager è che la versione o l'immagine di cert-manager (ad esempio v1.7.2) potrebbe tornare alla versione precedente. Questo problema è causato da monitoring-operator che tenta di riconciliare cert-manager e ripristina la versione durante la procedura.

    Soluzione temporanea:

    <pEvitare conflitti durante l'upgrade

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

    Ripristinare il proprio cert-manager nei cluster utente

    • Scala il deployment monitoring-operator a 0: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Scala i deployment di cert-manager gestiti da monitoring-operator a 0: 
      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 le hai.
    • Puoi saltare questo passaggio se utilizzi l'installazione predefinita upstream di cert-manager o se hai la certezza che cert-manager sia installato nello spazio dei nomi cert-manager. In caso contrario, copia le risorse metrics-ca cert-manager.io/v1 Certificate e metrics-pki.cluster.local Issuer da cert-manager allo spazio dei nomi delle risorse del cluster di 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 il proprio cert-manager nei cluster di amministrazione

    In generale, non è necessario reinstallare cert-manager nei cluster di amministrazione perché questi eseguono solo i carichi di lavoro del control plane di Google Distributed Cloud. Nei rari casi in cui devi installare anche il tuo 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 di cert-manager solo per Apigee, non devi eseguire i comandi del cluster di amministrazione.

    • Scala il deployment di monitoring-operator a 0. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Scala i deployment di cert-manager gestiti da monitoring-operator a 0. 
      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 le hai.
    • Puoi saltare questo passaggio se utilizzi l'installazione predefinita upstream di cert-manager o se hai la certezza che cert-manager sia installato nello spazio dei nomi cert-manager. In caso contrario, copia le risorse metrics-ca cert-manager.io/v1 Certificate e metrics-pki.cluster.local Issuer da cert-manager allo spazio dei nomi delle risorse del cluster di 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

    Docker, containerd e runc nelle immagini del sistema operativo Ubuntu fornite con Google Distributed Cloud sono bloccati su versioni speciali utilizzando Ubuntu PPA. In questo modo, prima di ogni release, Google Distributed Cloud verificherà che le modifiche al runtime del container siano qualificate.

    Tuttavia, le versioni speciali non sono note al tracker CVE di Ubuntu, che viene utilizzato come feed di vulnerabilità da vari strumenti di scansione CVE. Pertanto, vedrai falsi positivi nei risultati dell'analisi delle vulnerabilità di Docker, containerd e runc.

    Ad esempio, potresti visualizzare i seguenti falsi positivi dai risultati della scansione delle CVE. Queste CVE sono già state corrette nelle versioni patch più recenti di Google Distributed Cloud.

    Consulta le note di rilascio per eventuali correzioni di CVE.


    Soluzione temporanea:

    Canonical è a conoscenza del problema e la correzione è monitorata all'indirizzo https://github.com/canonical/sec-cvescan/issues/73.
    Upgrade, aggiornamenti 1.10, 1.11, 1.12, 1.13

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


    Soluzione temporanea:

    Questo tempo di inattività si verifica solo durante la procedura di upgrade. Se vuoi un tempo di inattività più breve durante l'upgrade, ti consigliamo di passare ai cluster HA.
    Installazione, upgrade, aggiornamenti 1.10, 1.11, 1.12, 1.13

    Se stai creando o eseguendo l'upgrade di un cluster HA e noti che il controllo di preparazione di konnectivity non è riuscito in cluster diagnose, nella maggior parte dei casi ciò non influirà sulla funzionalità di Google Distributed Cloud (kubectl exec, kubectl log e webhook). Ciò accade perché a volte una o due repliche di konnectivity potrebbero non essere pronte per un periodo di tempo a causa di problemi di rete instabili o di altro tipo.


    Soluzione temporanea:

    La connettività verrà ripristinata automaticamente. Attendi da 30 minuti a 1 ora e riesegui la diagnostica del cluster.
    Sistema operativo 1.7, 1.8, 1.9, 1.10, 1.11

    A partire dalla versione 1.7.2 di Google Distributed Cloud, 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 che venga pianificato un controllo aide per garantire il rispetto della regola del server CIS L1 "1.4.2 Ensure filesystem integrity is regularly checked".

    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 quel periodo causati da questo processo aide.


    Soluzione temporanea:

    Se i picchi influiscono sul tuo carico di lavoro, puoi disattivare il job cron giornaliero:

    sudo chmod -x /etc/cron.daily/aide
    Networking 1.10, 1.11, 1.12, 1.13

    Quando esegui il deployment di Google Distributed Cloud versione 1.9 o successive, se il deployment ha il bilanciatore del carico in bundle Seesaw in un ambiente che utilizza regole firewall distribuite stateful NSX-T, stackdriver-operator potrebbe non riuscire a creare gke-metrics-agent-conf ConfigMap e causare un loop di arresto anomalo dei gke-connect-agent pod.

    Il problema di fondo è che le regole del firewall distribuito 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 del firewall distribuito NSX-T riguardano tutte le release di Google Distributed Cloud che utilizzano Seesaw. Potresti riscontrare problemi di connessione simili nelle tue applicazioni quando creano oggetti Kubernetes di grandi dimensioni la cui dimensione è superiore a 32 K.


    Soluzione temporanea:

    Nella versione 1.13 della documentazione, segui queste istruzioni per disattivare le regole firewall distribuite NSX-T o per utilizzare 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 che reimposti 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 non funziona.
    Logging e monitoraggio 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Per Google Distributed Cloud versioni da 1.10 a 1.15, alcuni clienti hanno riscontrato una fatturazione inaspettatamente elevata per Metrics volume nella pagina Fatturazione. Questo problema ti riguarda solo quando si verificano tutte le seguenti circostanze:

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

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


    Soluzione temporanea

    Se il problema ti riguarda, ti consigliamo di eseguire l'upgrade dei cluster alla versione 1.12 o successive, di interrompere l'utilizzo del flag enableStackdriverForApplications e di 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 utilizzare 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 a disattivare la raccolta delle metriche basata sulle annotazioni, segui questi passaggi:

    1. Trova i pod e i servizi di origine che hanno le 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 Cloud Service Mesh, valuta la possibilità di configurare Cloud Service Mesh senza l'opzione Prometheus o disattivare la funzionalità di unione delle metriche Istio.
    Installazione 1.11, 1.12, 1.13

    Il programma di installazione di Google Distributed Cloud può non riuscire se i ruoli personalizzati sono associati al livello di autorizzazione errato.

    Quando l'associazione dei ruoli non è corretta, la creazione di un datadisk vSphere con govc si blocca 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 temporanea:

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

    Per ulteriori informazioni sulla creazione dei ruoli, vedi Privilegi dell'account utente vCenter.
    Logging e monitoraggio 1.9.0-1.9.4, 1.10.0-1.10.1

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

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


    Soluzione temporanea:
    Logging e monitoraggio 1.10, 1.11

    Per Google Distributed Cloud versione 1.10 e successive, il DaemonSet `gke-metrics-agent` presenta frequenti errori CrashLoopBackOff quando `enableStackdriverForApplications` è impostato su `true` nell'oggetto `stackdriver`.


    Soluzione temporanea:

    Per mitigare il problema, disattiva la raccolta delle metriche dell'applicazione eseguendo i seguenti comandi. Questi comandi non disattivano la raccolta dei log delle applicazioni.

    1. Per impedire l'annullamento 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 ConfigMap 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

    Se le metriche ritirate vengono utilizzate nelle dashboard OOTB, vedrai alcuni grafici vuoti. Per trovare le metriche ritirate 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 ritirate alle relative sostituzioni.

    RitiratoSostituzione
    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 temporanea:

    Per sostituire le metriche ritirate

    1. Elimina "Stato dei nodi GKE On-Prem" nella dashboard Google Cloud Monitoring. Reinstalla "Stato dei nodi GKE On-Prem" seguendo queste istruzioni.
    2. Elimina "Utilizzo dei nodi GKE On-Prem" nella dashboard Google Cloud Monitoring. Reinstalla "Utilizzo dei nodi GKE On-Prem" seguendo queste istruzioni.
    3. Elimina "GKE on-prem vSphere vm health" nella dashboard di monitoraggio di Google Cloud. Reinstalla "GKE on-prem vSphere vm health" seguendo queste istruzioni.

      4. Questo ritiro è dovuto all'upgrade dell'agente kube-state-metrics dalla versione 1.9 alla versione 2.4, necessario per Kubernetes 1.22. Puoi sostituire tutte le metriche ritirate kube-state-metrics, che hanno il prefisso kube_, nelle dashboard personalizzate o nelle norme di avviso.
    Logging e monitoraggio 1.10, 1.11, 1.12, 1.13

    Per Google Distributed Cloud versione 1.10 e successive, i dati per i cluster in Cloud Monitoring potrebbero contenere voci di metriche 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 riepilogativo siano presenti nell'elenco delle metriche, al momento non sono supportate da gke-metrics-agent.
    Logging e monitoraggio 1.10, 1.11, 1.12, 1.13

    Potresti notare che le seguenti metriche non sono presenti in 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 temporanea:

    Per risolvere il problema, esegui i seguenti passaggi come soluzione alternativa. Per [versioni 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

    Se il cluster amministratore è interessato da questo problema, mancano le metriche dello scheduler e del controller-manager. Ad esempio, queste due metriche non sono presenti

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

    Soluzione temporanea:

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

    Se il tuo cluster utente è interessato da questo problema, mancano le metriche di scheduler e controller-manager. Ad esempio, mancano queste due metriche:

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

    Soluzione temporanea:

    Questo problema è stato risolto in Google Distributed Cloud versione 1.13.0 e successive. Esegui l'upgrade del cluster a una versione con la correzione.
    Installazione, upgrade, aggiornamenti 1.10, 1.11, 1.12, 1.13

    Se crei un cluster di amministrazione per la versione 1.9.x o 1.10.0 e se il cluster di amministrazione non riesce a registrarsi con la specifica gkeConnect fornita durante la creazione, viene 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 riceverai il seguente errore se in un secondo momento tenti di eseguire l'upgrade del cluster di amministrazione alla versione 1.10.y.

    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 temporanea:
    Identità 1.10, 1.11, 1.12, 1.13

    Se utilizzi la funzionalità GKE Identity Service per gestire GKE Identity Service ClientConfig, Connect Agent potrebbe riavviarsi in modo imprevisto.


    Soluzione temporanea:

    Se hai riscontrato questo problema con un cluster esistente, puoi procedere in uno dei seguenti modi:

    • Disabilita GKE Identity Service. Se disabiliti GKE Identity Service, non verrà rimosso il binario GKE Identity Service di cui è stato eseguito il deployment o 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 del cluster.
    • Aggiorna il cluster alla versione 1.9.3 o successive oppure alla versione 1.10.1 o successive per eseguire l'upgrade della versione di Connect Agent.
    Networking 1.10, 1.11, 1.12, 1.13

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


    Soluzione temporanea:

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

    Puoi configurare l'opzione IP virtuale L4-L7 andando a Tenant > Application Profiles > Application EPGs o uSeg EPGs. Se l'apprendimento IP non viene disattivato, l'endpoint IP oscillerà tra diverse posizioni nel fabric API Cisco.
    VMware 1.10, 1.11, 1.12, 1.13

    VMWare ha recentemente identificato problemi critici con le seguenti versioni di vSphere 7.0 Update 3:

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

    Soluzione temporanea:

    VMWare ha rimosso queste release. Devi eseguire l'upgrade dei ESXi e vCenter a una versione più recente.
    Sistema operativo 1.10, 1.11, 1.12, 1.13

    Per i pod in esecuzione su nodi che utilizzano immagini Container-Optimized OS (COS), non puoi montare il volume emptyDir come exec. Viene montato come noexec e riceverai il seguente errore: exec user process caused: permission denied. Ad esempio, visualizzerai 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

    Nel pod di test, se esegui mount | grep test-volume, viene visualizzata l'opzione noexec:

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

    Soluzione temporanea:
    Upgrade, aggiornamenti 1.10, 1.11, 1.12, 1.13

    Le repliche del node pool non vengono aggiornate una volta che la scalabilità automatica è stata abilitata e disabilitata in unpool di nodil.


    Soluzione temporanea:

    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 della macchina del pool di nodi corrispondente.
    Logging e monitoraggio 1.11, 1.12, 1.13

    A partire dalla versione 1.11, nelle dashboard di monitoraggio pronte all'uso, le dashboard Stato pod Windows e Stato nodo Windows mostrano anche i dati dei cluster Linux. Questo perché le metriche del nodo Windows e del pod vengono esposte anche sui cluster Linux.
    Logging e monitoraggio 1.10, 1.11, 1.12

    Per Google Distributed Cloud versione 1.10, 1.11 e 1.12, stackdriver-log-forwarder DaemonSet potrebbe presentare errori CrashLoopBackOff quando sono presenti log bufferizzati danneggiati sul disco.


    Soluzione temporanea:

    Per risolvere il problema, dobbiamo ripulire i log memorizzati 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 pulire 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 ripulito tutti i blocchi, puoi eseguire i seguenti comandi. L'output dei due comandi deve essere uguale al numero del 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

    Se non visualizzi i log in Cloud Logging dai tuoi cluster e noti il seguente errore nei 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 di logging, il che impedisce a stackdriver-log-forwarder di inviare i log. Questo problema si verifica in tutte le versioni di Google Distributed Cloud.

    Soluzione alternativa:

    Per risolvere il problema, devi aumentare il limite delle risorse nell'agente di 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

    per un breve periodo il nodo è pronto, ma il certificato del server kubelet non è pronto. kubectl exec e kubectl logs non sono disponibili durante questi secondi. Questo perché il nuovo approvatore del certificato del server impiega del tempo per visualizzare gli IP validi aggiornati del nodo.

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

    L'upgrade del cluster utente non è riuscito con il seguente errore:

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

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


    Soluzione temporanea:

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

    Il 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 node pool del cluster esistenti ed è stata aggiunta in gkectl diagnose cluster per errore.


    Soluzione temporanea:

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

    Potresti non riuscire ad aggiungere un nuovo cluster utente se il cluster di amministrazione è configurato con un bilanciamento del carico MetalLB.

    Il processo di eliminazione del cluster utente potrebbe bloccarsi per qualche motivo, il che comporta l'invalidazione di ConfigMap di MetalLB. Non sarà possibile aggiungere un nuovo cluster di utenti in questo stato.


    Soluzione temporanea:

    Puoi forzare l'eliminazione del cluster utente.
    Installazione, Sistema operativo 1.10, 1.11, 1.12, 1.13

    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 riesce 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 utilizza per impostazione predefinita lo stesso osImageType del cluster di amministrazione e attualmente la VM di test non è ancora compatibile con COS.


    Soluzione temporanea:

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

    Questo problema interessa i clienti che utilizzano Grafana nel cluster di amministrazione per monitorare i cluster utente nelle versioni 1.12.0 e 1.12.1 di Google Distributed Cloud. Deriva da una mancata corrispondenza dei certificati pushprox-client nei cluster utente e della lista consentita in pushprox-server nel cluster di amministrazione. Il sintomo è pushprox-client nei cluster utente che stampa log di 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 temporanea:
    Altro 1.11.3

    Il 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 control plane di amministrazione se il nome della VM del control plane di amministrazione termina con i caratteri t, m, p o l.


    Soluzione temporanea:

    Esegui di nuovo il comando con --skip-validation.
    Logging e monitoraggio 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    Cloud Audit Logs richiede una configurazione speciale delle autorizzazioni che attualmente viene eseguita automaticamente solo per i cluster utente tramite GKE Hub. È consigliabile avere almeno un cluster utente che utilizzi lo stesso ID progetto e lo stesso account di servizio del cluster di amministrazione per Cloud Audit Logs, in modo che il cluster di amministrazione disponga dell'autorizzazione richiesta.

    Tuttavia, nei casi in cui il cluster di amministrazione utilizza un ID progetto diverso o un account di servizio diverso da qualsiasi cluster utente, i log di controllo 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 temporanea:
    Operazione, Sicurezza 1,11

    Se la tua workstation 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 workstation 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 temporanea:

    Puoi ignorare questi messaggi.
    Sistema operativo 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    /var/log/audit/ è pieno di audit log. 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 Google Distributed Cloud v1.8, l'immagine Ubuntu è protetta con il benchmark CIS di livello 2. Una delle regole di conformità, "4.1.2.2 Ensure audit logs are not automatically deleted", garantisce l'impostazione auditd max_log_file_action = keep_logs. In questo modo, tutte le regole di controllo vengono conservate sul disco.


    Soluzione temporanea:
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

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

    [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, kubelet può erroneamente eseguire il binding 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 NetworkGatewayGroup rispetto a tutti gli indirizzi IP mobili node.status.addresses nel cluster e lo considera un conflitto.


    Soluzione temporanea:

    Nello stesso cluster in cui la creazione o l'aggiornamento degli oggetti NetworkGatewayGroup non va a buon fine, disattiva 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 di configurazione dei webhook e chiudi per applicare le modifiche.
    4. Crea o modifica l'oggetto NetworkGatewayGroup.
    5. Applica di nuovo la configurazione webhook originale: 
      kubectl -n kube-system apply -f webhook-config.yaml
    Installazione, upgrade, aggiornamenti 1.10.0-1.10.2

    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 control plane amministrativo entra in un ciclo di attesa infinito durante l'avvio e nel file /var/log/cloud-init-output.log viene visualizzato il seguente errore di ciclo infinito:

    + 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

    Questo perché quando Google Distributed Cloud tenta di ottenere l'indirizzo IP del nodo nello script di avvio, utilizza grep -v ADMIN_CONTROL_PLANE_VIP per ignorare il VIP del control plane del cluster di amministrazione, che può essere assegnato anche alla NIC. Tuttavia, il comando ignora anche qualsiasi indirizzo IP con un prefisso del VIP del control plane, il che causa il blocco dello script di avvio.

    Ad esempio, supponiamo che il VIP del control plane del cluster di amministrazione sia 192.168.1.25. Se l'indirizzo IP della VM del control plane del cluster di amministrazione ha lo stesso prefisso, ad esempio 192.168.1.254, la VM del control plane si bloccherà durante la creazione. Questo problema può verificarsi anche se l'indirizzo di trasmissione ha lo stesso prefisso del VIP del control plane, ad esempio 192.168.1.255.


    Soluzione temporanea:

    • Se il motivo del timeout della creazione del cluster di amministrazione è dovuto all'indirizzo IP di broadcast, esegui questo comando sulla VM del control plane del cluster di amministrazione: 
      ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
       In questo modo verrà creata una riga senza un indirizzo di trasmissione e verrà sbloccato 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 control plane, 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, aggiornamenti 1.10.0-1.10.2

    DataDisk non può essere montato correttamente sul nodo master del cluster di amministrazione quando si utilizza l'immagine COS e 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à in anteprima)


    Soluzione temporanea:

    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 connettiti tramite SSH al nodo master di amministrazione. df -h risultato contiene /dev/sdb1 98G 209M 93G 1% /opt/data. Il risultato lsblk contiene -sdb1 8:17 0 100G 0 part /opt/data
    Sistema operativo 1,10

    Nella versione 1.10.0 di Google Distributed Cloud, le risoluzioni dei nomi su Ubuntu vengono indirizzate a systemd-resolved locale in ascolto su 127.0.0.53 per impostazione predefinita. Il motivo è che nell'immagine Ubuntu 20.04 utilizzata nella versione 1.10.0, /etc/resolv.conf è collegato simbolicamente a /run/systemd/resolve/stub-resolv.conf, che rimanda 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 suffisso .local, a meno che i nomi non siano specificati come domini di ricerca.

    In questo modo, tutte le ricerche di nomi .local non vanno 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 postazione di amministrazione.


    Soluzione temporanea:

    Puoi evitare questo problema per i nodi del 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.

    Pertanto, se non hai configurato questo campo prima della creazione del cluster, devi accedere ai nodi tramite SSH e bypassare lo stub locale systemd-resolved 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 punta al DNS upstream effettivo): 

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

    Per quanto riguarda la workstation amministrativa, gkeadm non supporta la specifica dei domini di ricerca, quindi è necessario aggirare questo problema con questo passaggio manuale.

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

    Google Distributed Cloud specifica una subnet dedicata per l'indirizzo IP bridge Docker che utilizza --bip=169.254.123.1/24, in modo da non riservare la subnet 172.17.0.1/16 predefinita. Tuttavia, nella versione 1.10.0, è presente un bug nell'immagine sistema operativo Ubuntu che ha causato l'ignoramento della configurazione Docker personalizzata.

    Di conseguenza, Docker sceglie 172.17.0.1/16 come subnet dell'indirizzo IP bridge. Ciò potrebbe causare un conflitto di indirizzi IP se hai già un carico di lavoro in esecuzione all'interno di questo intervallo di indirizzi IP.


    Soluzione temporanea:

    Per risolvere questo problema, devi rinominare il seguente file di configurazione systemd per dockerd e poi 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 bridge corretto:

    ip a | grep docker0

    Questa soluzione non viene mantenuta nelle ricreazioni di VM. Devi riapplicare questa soluzione alternativa ogni volta che le VM vengono ricreate.
    Upgrade, aggiornamenti 1,11

    Nella versione 1.11.0 di Google Distributed Cloud, sono state apportate modifiche alla definizione delle risorse personalizzate relative a logging e monitoraggio:

    • Il nome del gruppo della risorsa personalizzata stackdriver è cambiato da addons.sigs.k8s.io a addons.gke.io.
    • Il nome del gruppo delle risorse personalizzate monitoring e metricsserver è stato modificato da addons.k8s.io a addons.gke.io.
    • Le specifiche delle risorse precedenti iniziano a essere convalidate in base al relativo schema. In particolare, la specifica resourceAttrOverride e storageSizeOverride nella risorsa personalizzata stackdriver deve avere il tipo di stringa nei valori delle richieste e dei limiti di CPU, memoria e dimensioni di archiviazione.

    Le modifiche al nome del gruppo vengono apportate in conformità agli aggiornamenti di CustomResourceDefinition in Kubernetes 1.22.

    Non è richiesta alcuna azione se non disponi di una logica aggiuntiva che si applica o modifica le risorse personalizzate interessate. La procedura di upgrade di Google Distributed Cloud 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, devono essere referenziati 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, le applicazioni e le modifiche non avranno effetto e potrebbero comportare 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 sopra indicati, significa che prima dell'upgrade era già presente un tipo non supportato nella specifica CR di Stackdriver. Come soluzione alternativa, puoi modificare manualmente il CR di Stackdriver con il vecchio nome del gruppo kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver e procedere nel seguente modo:

    1. Modifica le richieste e i limiti delle risorse in modo che siano di tipo stringa.
    2. Rimuovi eventuali annotazioni addons.gke.io/migrated-and-deprecated: true, se presenti.
    Quindi riprendi o riavvia la procedura di upgrade.

    Sistema operativo 1.7 e versioni successive

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

    Soluzione temporanea:

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

    Il pacchetto 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 (ad esempio Cisco ACI). Può causare tempi di inattività del servizio più lunghi dopo il ripristino di uno split brain (a causa dell'eliminazione dei pacchetti VRRP).

    Soluzione temporanea:

    Attiva un failover di Seesaw eseguendo sudo seesaw -c failover su una delle VM di Seesaw. In questo modo il traffico dovrebbe essere ripristinato.
    Sistema operativo 1.16, 1.28.0-1.28.200

    "staticPodPath" è stato impostato erroneamente per i nodi worker

    Soluzione temporanea:

    Crea manualmente la cartella "/etc/kubernetes/manifests".

    Passaggi successivi

    Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

    Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui: