Problemi noti di GKE su Bare Metal

Questa pagina elenca tutti i problemi noti relativi a Google Distributed Cloud Virtual for Bare Metal. Per filtrare i problemi noti per una versione o una categoria di prodotto, seleziona i filtri dai seguenti menu a discesa.

Seleziona la versione di GDCV per Bare Metal:

Seleziona la categoria del problema:

In alternativa, cerca il problema:

Categoria Versioni identificate Problema e soluzione alternativa
Ripristino/eliminazione 1.29.0

La reimpostazione del cluster utente non riesce a eliminare lo spazio dei nomi

Durante l'esecuzione di bmctl reset cluster -c ${USER_CLUSTER}, dopo il completamento di tutti i job correlati, il comando non riesce a eliminare lo spazio dei nomi del cluster utente. Lo spazio dei nomi del cluster utente è bloccato nello stato Terminating. Al termine, il timeout della reimpostazione del cluster viene restituito e restituisce un errore.

Soluzione alternativa:

Per rimuovere lo spazio dei nomi e completare la reimpostazione del cluster utente, segui questi passaggi:

  1. Elimina il pod metrics-server dal cluster di amministrazione:
    kubectl delete pods -l k8s-app=metrics-server \
        -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH
    
    In questa situazione, il pod metrics-server impedisce la rimozione dello spazio dei nomi del cluster.
  2. Nel cluster di amministrazione, forza la rimozione del finalizzatore nello spazio dei nomi del cluster utente:
    kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \
        jq '.spec.finalizers = []' | \
        kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f -
    
    Una volta rimosso il finalizzatore, lo spazio dei nomi del cluster viene rimosso e la reimpostazione del cluster è completa.
Configurazione, installazione, sicurezza Da 1.16.0 a 1.16.7 e da 1.28.0 a 1.28.400

Nel deployment di Autorizzazione binaria manca un nodeSelector

Se hai abilitato Autorizzazione binaria per GKE su Bare Metal e utilizzi una versione da 1.16.0 a 1.16.7 o da 1.28.0 a 1.28.400, potresti riscontrare un problema con la pianificazione dei pod per la funzionalità. In queste versioni, al deployment di Autorizzazione binaria manca un nodeSelector, quindi i pod per la funzionalità possono essere pianificati sui nodi worker anziché sui nodi del piano di controllo. Questo comportamento non causa alcun errore, ma non è previsto.

Soluzione alternativa:

Per tutti i cluster interessati, completa i seguenti passaggi:

  1. Apri il file di deployment di Autorizzazione binaria:
    kubectl edit -n binauthz-system deployment binauthz-module-deployment
  2. Aggiungi il seguente nodeSelector nel blocco spec.template.spec:
  3.       nodeSelector:
            node-role.kubernetes.io/control-plane: ""
    
  4. Salva le modifiche.

Una volta salvata la modifica, viene eseguito nuovamente il deployment dei pod solo nei nodi del piano di controllo. Questa correzione deve essere applicata dopo ogni upgrade.

Upgrade e aggiornamenti 1.28.0, 1.28.100, 1.28.200, 1.28.300

Errore durante l'upgrade di un cluster a 1.28.0-1.28.300

L'upgrade dei cluster creati prima della versione 1.11.0 alle versioni 1.28.0-1.28.300 potrebbe far sì che il pod del deployment del controller del ciclo di vita entri in uno stato di errore durante l'upgrade. In questo caso, i log del pod del deployment del controller del ciclo di vita visualizzano un messaggio di errore simile al seguente:

"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions

Soluzione alternativa:

Questo problema è stato risolto nella versione 1.28.400. Esegui l'upgrade alla versione 1.28.400 o successive per risolvere il problema.

Se non riesci a eseguire l'upgrade, esegui i comandi seguenti per risolvere il problema:

kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Logging e monitoraggio 1,13,7; 1,14; 1,15; 1,16; 1,28

ID progetto errato visualizzato in Esplora log

A volte i log del cluster o del container sono contrassegnati con un ID progetto diverso in resource.labels.project_id in Esplora log.

Questo può accadere quando il cluster è configurato per utilizzare l'osservabilità PROJECT_ONE, impostata nel campo clusterOperations.projectID nella configurazione del cluster. Tuttavia, cloudOperationsServiceAccountKeyPath nella configurazione ha una chiave dell'account di servizio del progetto PROJECT_TWO.

In questi casi, tutti i log vengono instradati a PROJECT_ONE, ma resource.labels.project_id è etichettato come PROJECT_TWO.

Soluzione alternativa:

Utilizza una delle seguenti opzioni per risolvere il problema:

  • Utilizza un account di servizio dello stesso progetto di destinazione.
  • Modifica il project_id nel file JSON della chiave dell'account di servizio nel progetto corrente.
  • Modifica project_id direttamente nel filtro dei log da Esplora log.
Networking 1.29.0

Degrado delle prestazioni per i cluster che utilizzano il bilanciamento del carico in bundle con BGP

Per i cluster della versione 1.29.0 che utilizzano il bilanciamento del carico in bundle con BGP, le prestazioni del bilanciamento del carico possono diminuire quando il numero totale di servizi di tipo LoadBalancer si avvicina a 2000. Man mano che le prestazioni si riducono, i servizi appena creati richiedono molto tempo per connettersi o non possono essere connessi da un client. I servizi esistenti continuano a funzionare, ma non gestiscono modalità di errore, come la perdita di un nodo del bilanciatore del carico, in modo efficace. Questi problemi relativi ai servizi si verificano quando il deployment di ang-controller-manager viene arrestato a causa dell'esaurimento della memoria.

Se il cluster è interessato da questo problema, i servizi nel cluster non sono raggiungibili e non sono integri e il deployment ang-controller-manager si trova in un CrashLoopBackOff. La risposta quando vengono elencati i deployment ang-controller-manager è simile alla seguente:

ang-controller-manager-79cdd97b88-9b2rd   0/1    CrashLoopBackOff   639 (59s ago)   2d10h   10.250.210.152   vm-bgplb-centos4-n1-02   <none>   <none>

ang-controller-manager-79cdd97b88-r6tcl   0/1   CrashLoopBackOff   620 (4m6s ago)   2d10h   10.250.202.2     vm-bgplb-centos4-n1-11   <none>   <none>

Soluzione

Come soluzione alternativa, puoi aumentare di 100 MiB il limite di risorse di memoria del deployment ang-controller-manager e rimuovere il limite di CPU:

kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG

Dopo aver apportato correttamente le modifiche e chiuso l'editor, dovresti vedere il seguente output:

deployment.apps/ang-controller-manager edited

Per verificare che le modifiche siano state applicate, esamina il manifest di ang-controller-manager nel cluster:

kubectl get deployment ang-controller-manager \
   -n kube-system \
   -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \
   --kubeconfig ADMIN_KUBECONFIG

La risposta dovrebbe essere simile alla seguente:

NAME                     CPU_LIMITS   MEMORY_LIMITS
ang-controller-manager   <none>       400Mi
Installazione, upgrade, backup e ripristino 1.28.0, 1.28.100

I problemi di connettività dell'endpoint gcr.io di Container Registry possono bloccare le operazioni del cluster

Più operazioni del cluster per i cluster di amministrazione creano un cluster di bootstrap. Prima di creare un cluster di bootstrap, bmctl esegue un controllo della connettività Google Cloud dalla workstation di amministrazione. Questo controllo potrebbe non riuscire a causa di problemi di connettività con l'endpoint di Container Registry, gcr.io, e potresti visualizzare un messaggio di errore simile al seguente:

        system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
        

Soluzione

Per risolvere il problema, riprova l'operazione con il flag --ignore-validation-errors.

Networking 1,15, 1,16

GKE Dataplane V2 non compatibile con alcuni driver di archiviazione

I cluster GKE su Bare Metal utilizzano GKE Dataplane V2, che non è compatibile con alcuni provider di archiviazione. Potresti riscontrare problemi con volumi o pod NFS bloccati. Ciò è particolarmente probabile se hai carichi di lavoro che utilizzano volumi ReadWriteMany supportati da driver di archiviazione soggetti a questo problema:

  • Robin.io
  • Portworx (sharedv4 volume di servizio)
  • csi-nfs

Questo elenco non è completo.

Soluzione

Una correzione per questo problema è disponibile per le seguenti versioni di Ubuntu:

  • 20.04 LTS: utilizza un'immagine del kernel 5.4.0 successiva a linux-image-5.4.0-166-generic
  • 22.04 LTS: utilizza un'immagine del kernel 5.15.0 successiva a linux-image-5.15.0-88-generic o il kernel HWE 6.5.

Se non utilizzi una di queste versioni, contatta l'Assistenza Google.

Logging e monitoraggio 1,15; 1,16; 1,28

kube-state-metrics OOM in cluster di grandi dimensioni

Potresti notare che kube-state-metrics o il pod gke-metrics-agent esistente sullo stesso nodo di kube-state-metrics ha esaurito la memoria (OOM).

Questo può accadere in cluster con più di 50 nodi o con molti oggetti Kubernetes.

Soluzione

Per risolvere il problema, aggiorna la definizione della risorsa personalizzata stackdriver in modo da utilizzare la porta delle funzionalità ksmNodePodMetricsOnly. Questa limitazione delle funzionalità garantisce che venga esposto solo un numero limitato di metriche critiche.

Per utilizzare questa soluzione alternativa, procedi nel seguente modo:

  1. Controlla la definizione della risorsa personalizzata stackdriver per conoscere le porte di funzionalità disponibili:
    kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly
            
  2. Aggiorna la definizione della risorsa personalizzata stackdriver per abilitare ksmNodePodMetricsOnly:
    kind:stackdriver
    spec:
      featureGates:
         ksmNodePodMetricsOnly: true
            
Installazione 1.28.0-1.28.200

Il controllo preflight non va a buon fine su RHEL 9.2 a causa di iptables mancanti

Durante l'installazione di un cluster sul sistema operativo Red Hat Enterprise Linux (RHEL) 9.2, potresti riscontrare un errore a causa della mancanza del pacchetto iptables. L'errore si verifica durante i controlli preflight e attiva un messaggio di errore simile al seguente:

'check_package_availability_pass': "The following packages are not available: ['iptables']"
        

RHEL 9.2 è in Anteprima per GKE su Bare Metal versione 1.28.

Soluzione

Ignora l'errore del controllo preflight impostando spec.bypassPreflightCheck su true nella risorsa cluster.

Operazione 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16

Failover MetalLB lento su larga scala

Quando MetalLB gestisce un numero elevato di servizi (oltre 10.000), il failover può richiedere più di un'ora. Questo accade perché MetalLB utilizza una coda con limitazioni di frequenza che, se in condizioni di scalabilità elevata, può richiedere del tempo per raggiungere il servizio per il quale è necessario eseguire il failover.

Soluzione

Esegui l'upgrade del cluster alla versione 1.28 o successive. Se non riesci a eseguire l'upgrade, la modifica manuale del servizio (ad esempio l'aggiunta di un'annotazione) causa un failover più rapido del servizio.

Operazione 1.16.0-1.16.6, 1.28.0-1.28.200

Se il proxy è abilitato, è necessario impostare le variabili di ambiente sulla workstation di amministrazione

Se non hai definito le variabili di ambiente HTTPS_PROXY e NO_PROXY sulla workstation di amministrazione, bmctl check cluster potrebbe non riuscire a causa di errori del proxy. Il comando bmctl segnala un messaggio di errore relativo alla mancata chiamata di alcuni servizi Google, come nell'esempio seguente:

[2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred:
        * GKERegister check failed: 2 errors occurred:
        * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout
        * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout

Soluzione

Imposta manualmente HTTPS_PROXY e NO_PROXY sulla workstation di amministrazione.

Upgrade e aggiornamenti 1.28.0-gke.435

Gli upgrade alla versione 1.28.0-gke.435 potrebbero non riuscire se audit.log ha una proprietà errata

In alcuni casi, per il file /var/log/apiserver/audit.log sui nodi del piano di controllo la proprietà del gruppo e degli utenti è impostata su root. Questa impostazione relativa alla proprietà dei file causa errori di upgrade per i nodi del piano di controllo quando esegui l'upgrade di un cluster dalla versione 1.16.x alla versione 1.28.0-gke.435. Questo problema si applica solo ai cluster creati prima della versione 1.11 e per cui Cloud Audit Logs è disabilitato. Cloud Audit Logs è abilitato per impostazione predefinita per i cluster versione 1.9 e successive.

Soluzione

Se non riesci a eseguire l'upgrade del cluster alla versione 1.28.100-gke.146, segui questi passaggi come soluzione alternativa per completare l'upgrade del cluster alla versione 1.28.0-gke.435:

  • Se Cloud Audit Logs è abilitato, rimuovi il file /var/log/apiserver/audit.log.
  • Se Cloud Audit Logs è disabilitato, cambia la proprietà di /var/log/apiserver/audit.log in modo che corrisponda alla directory padre, /var/log/apiserver.
Networking, upgrade e aggiornamenti 1.28.0-gke.435

MetalLB non assegna indirizzi IP ai servizi VIP

GKE su Bare Metal utilizza MetalLB per il bilanciamento del carico in bundle. Nella release 1.28.0-gke.435 di GKE su Bare Metal, viene eseguito l'upgrade del bundle MetalLB in bundle alla versione 0.13, che introduce il supporto CRD per IPAddressPools. Tuttavia, poiché ConfigMaps consente qualsiasi nome per un IPAddressPool, i nomi dei pool dovevano essere convertiti in un nome conforme a Kubernetes aggiungendo un hash alla fine del nome dell'elemento IPAddressPool. Ad esempio, un IPAddressPool con nome default viene convertito in un nome come default-qpvpd quando esegui l'upgrade del cluster alla versione 1.28.0-gke.435.

Poiché MetalLB richiede un nome specifico di IPPool per la selezione, la conversione del nome impedisce a MetalLB di selezionare un pool e assegnare indirizzi IP. Di conseguenza, i servizi che utilizzano metallb.universe.tf/address-pool come annotazione per selezionare il pool di indirizzi per un indirizzo IP non ricevono più un indirizzo IP dal controller MetalLB.

Questo problema è stato risolto in GKE su Bare Metal versione 1.28.100-gke.146.

Soluzione

Se non riesci a eseguire l'upgrade del cluster alla versione 1.28.100-gke.146, segui questi passaggi come soluzione alternativa:

  1. Ottieni il nome convertito di IPAddressPool:
    kubectl get IPAddressPools -n kube-system
    
  2. Aggiorna il servizio interessato per impostare l'annotazione metallb.universe.tf/address-pool sul nome convertito con l'hash.

    Ad esempio, se il nome IPAddressPool è stato convertito da default a un nome come default-qpvpd, modifica l'annotazione metallb.universe.tf/address-pool: default nel servizio in metallb.universe.tf/address-pool: default-qpvpd.

L'hash utilizzato nella conversione del nome è deterministico, quindi la soluzione alternativa è permanente.

Upgrade e aggiornamenti 1,14; 1,15; 1,16; 1,28; 1,29

Pod orfani dopo l'upgrade alla versione 1.14.x

Quando esegui l'upgrade di GKE su cluster Bare Metal alla versione 1.14.x, alcune risorse della versione precedente non vengono eliminate. In particolare, potresti vedere un insieme di pod orfani come il seguente:

capi-webhook-system/capi-controller-manager-xxx
capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx

Questi oggetti orfani non influiscono direttamente sul funzionamento del cluster, ma come best practice, ti consigliamo di rimuoverli.

  • Esegui questi comandi per rimuovere gli oggetti orfani:
    kubectl delete ns capi-webhook-system
    kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration
    kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration
    

Questo problema è stato risolto in GKE su Bare Metal versione 1.15.0 e successive.

Installazione 1,14

Creazione del cluster bloccata sul job machine-init

Se provi a installare Google Distributed Cloud Virtual for Bare Metal versione 1.14.x, potresti riscontrare un errore a causa dei job machine-init, simile al seguente output di esempio:

"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members

"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference

Soluzione alternativa:

Rimuovi il membro etcd obsoleto che causa l'errore del job machine-init. Completa i seguenti passaggi su un nodo del piano di controllo funzionante:

  1. Elenca i membri etcd esistenti:
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
      --cacert=/etc/kubernetes/pki/etcd/ca.crt \
      --cert=/etc/kubernetes/pki/etcd/peer.crt \
      member list
    
    Cerca i membri con stato unstarted, come mostrato nel seguente output di esempio:
    5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false
    99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false
    bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false
    
  2. Rimuovi il membro etcd che non ha superato il controllo:
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
      --cacert=/etc/kubernetes/pki/etcd/ca.crt \
      --cert=/etc/kubernetes/pki/etcd/peer.crt \
      member remove MEMBER_ID
    
    Sostituisci MEMBER_ID con l'ID del membro etcd che non ha superato il controllo. Nell'output di esempio precedente, questo ID è bd1949bcb70e2cb5.

    Il seguente output di esempio mostra che il membro è stato rimosso:
    Member bd1949bcb70e2cb5 removed from cluster  9d70e2a69debf2f
    
Networking 1.28.0

Cilium-operator non dispone delle autorizzazioni list e watch per i nodi

In Cilium 1.13, le autorizzazioni ClusterRole cilium-operator non sono corrette. Mancano le autorizzazioni Nodo list e watch. cilium-operator non riesce ad avviare i garbage collector, causando i seguenti problemi:

  • Perdita di risorse Cilium.
  • Le identità inattive non vengono rimosse dalle mappe di criteri IAB.
  • Le mappe di criteri potrebbero raggiungere il limite di 16.000.
    • Impossibile aggiungere nuove voci.
    • Applicazione non corretta di NetworkPolicy.
  • Le identità potrebbero raggiungere il limite di 64.000.
    • Non è possibile creare nuovi pod.

Un operatore a cui mancano le autorizzazioni per i nodi segnala il seguente messaggio di log di esempio:

2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s

L'agente Cilium segnala un messaggio di errore quando non riesce a inserire una voce in una mappa dei criteri, come nell'esempio seguente:

level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint

Soluzione alternativa:

Rimuovi le identità Cilium, quindi aggiungi le autorizzazioni ClusterRole mancanti all'operatore:

  1. Rimuovi gli oggetti CiliumIdentity esistenti:
    kubectl delete ciliumid –-all
    
  2. Modifica l'oggetto ClusterRole cilium-operator:
    kubectl edit clusterrole cilium-operator
    
  3. Aggiungi una sezione per nodes che includa le autorizzazioni mancanti, come mostrato nell'esempio seguente:
    - apiGroups:
      - ""
      resources:
      - nodes
      verbs:
      - get
      - list
      - watch
    
  4. Salva e chiudi l'editor. L'operatore rileva in modo dinamico la modifica dell'autorizzazione. Non è necessario riavviare manualmente l'operatore.
Upgrade e aggiornamenti 1,15,0-1,15,7, 1,16,0-1,16,3

Si è verificato un problema temporaneo durante il controllo preflight

Una delle attività di controllo di integrità di kubeadm che viene eseguita durante il controllo preflight dell'upgrade potrebbe non riuscire con il seguente messaggio di errore:

[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found

Questo errore può essere ignorato. Se si verifica questo errore che blocca l'upgrade, esegui nuovamente il comando di upgrade.

Se noti questo errore quando esegui il preflight utilizzando il comando bmctl preflightcheck, non viene bloccato nulla da questo errore. Puoi eseguire di nuovo il controllo preflight per ottenere informazioni preflight accurate.


Soluzione alternativa:

Esegui di nuovo il comando di upgrade oppure, se rilevato durante bmctl preflightcheck, esegui nuovamente il comando preflightcheck.

Operazione 1,14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0

Il controllo di integrità della rete periodico non va a buon fine quando un nodo viene sostituito o rimosso

Questo problema riguarda i cluster che eseguono controlli di integrità della rete periodici dopo che un nodo è stato sostituito o rimosso. Se il cluster viene sottoposto a controlli di integrità periodici, il controllo di integrità periodico della rete determina un errore dopo la sostituzione o la rimozione di un nodo, poiché l'inventario di rete ConfigMap non viene aggiornato dopo la creazione.


Soluzione alternativa:

La soluzione consigliata è eliminare il ConfigMap dell'inventario e il controllo di integrità periodico della rete. L'operatore di cluster li ricrea automaticamente con le informazioni più aggiornate.

Per i cluster 1.14.x, esegui questi comandi:

kubectl delete configmap \
    $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    CLUSTER_NAME-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Per i cluster 1.15.0 e versioni successive, esegui questi comandi:

kubectl delete configmap \
    $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    bm-system-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
Networking 1,14, 1,15, 1,16,0-1,16,2

Il gateway di rete per GDC non può applicare la tua configurazione quando il nome del dispositivo contiene un punto

Se hai un dispositivo di rete che include un punto (.) nel nome, ad esempio bond0.2, Gateway di rete per GDC tratta il punto come un percorso nella directory quando viene eseguito sysctl per apportare modifiche. Quando il gateway di rete per GDC controlla se il rilevamento di indirizzi duplicati (DAD) è abilitato, il controllo potrebbe non riuscire e pertanto non verrà riconciliato.

Il comportamento è diverso tra le versioni dei cluster:

  • 1.14 e 1.15: questo errore esiste solo quando utilizzi indirizzi IP mobili IPv6. Se non utilizzi indirizzi IP mobili IPv6, non noterai questo problema se i nomi dei dispositivi contengono un punto.
  • 1.16.0 - 1.16.2: questo errore esiste sempre quando i nomi dei dispositivi contengono un punto.

Soluzione alternativa:

Esegui l'upgrade del cluster alla versione 1.16.3 o successive.

Come soluzione alternativa fino a quando non potrai eseguire l'upgrade dei cluster, rimuovi il punto (.) dal nome del dispositivo.

Upgrade e aggiornamenti, networking, sicurezza 1.16.0

Gli upgrade a 1.16.0 non riescono se seccomp è disabilitato

Se seccomp è disabilitato per il tuo cluster (spec.clusterSecurity.enableSeccomp impostato su false), gli upgrade alla versione 1.16.0 non andranno a buon fine.

GKE su Bare Metal versione 1.16 utilizza Kubernetes versione 1.27. In Kubernetes 1.27.0 e versioni successive, la funzionalità per impostare i profili seccomp è in disponibilità generale e non utilizza più una gate delle funzionalità. Questa modifica a Kubernetes causa errori degli upgrade alla versione 1.16.0 quando seccomp è disabilitato nella configurazione del cluster. Questo problema è stato risolto nella versione 1.16.1 e nei cluster successivi. Se il campo cluster.spec.clusterSecurity.enableSeccomp è impostato su false, puoi eseguire l'upgrade alla versione 1.16.1 o successive.

I cluster con spec.clusterSecurity.enableSeccomp non impostato o impostato su true non sono interessati.

Installazione, funzionamento 1,11, 1,12, 1,13, 1,14, 1,15,0-1,15,5, 1,16,0-1,16,1

i metadati containerd potrebbero danneggiarsi dopo il riavvio quando viene montato /var/lib/containerd

Se hai montato facoltativamente /var/lib/containerd, i metadati containerd potrebbero danneggiarsi dopo un riavvio. I metadati danneggiati potrebbero causare errori dei pod, inclusi i pod critici del sistema.

Per verificare se questo problema ti riguarda, controlla se in /etc/fstab è stato definito un montaggio facoltativo per /var/lib/containerd/ e se è presente nofail nelle opzioni di montaggio.


Soluzione alternativa:

Rimuovi l'opzione di montaggio nofail in /etc/fstab oppure esegui l'upgrade del cluster alla versione 1.15.6 o successive.

Operazione 1,13; 1,14; 1,15; 1,16; 1,28

Pulisci i pod inattivi nel cluster

Potresti vedere pod gestiti da un Deployment (ReplicaSet) in stato Failed e con lo stato TaintToleration. Questi pod non utilizzano risorse del cluster, ma devono essere eliminati.

Puoi usare il seguente comando kubectl per elencare i pod di cui puoi eseguire la pulizia:

kubectl get pods –A | grep TaintToleration

Il seguente output di esempio mostra un pod con lo stato TaintToleration:

kube-system    stackdriver-metadata-agent-[...]    0/1    TaintToleration    0

Soluzione alternativa:

Per ogni pod con i sintomi descritti, controlla il ReplicaSet a cui appartiene il pod. Se il ReplicaSet è soddisfatto, puoi eliminare i pod:

  1. Ottieni il ReplicaSet che gestisce il pod e trova il valore ownerRef.Kind:
    kubectl get pod POD_NAME -n NAMESPACE -o yaml
    
  2. Scarica il ReplicaSet e verifica che status.replicas sia uguale a spec.replicas:
    kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml
    
  3. Se i nomi corrispondono, elimina il pod:
    kubectl delete pod POD_NAME -n NAMESPACE.
    
Upgrade 1.16.0

etcd-events possono bloccarsi quando si esegue l'upgrade alla versione 1.16.0

Quando esegui l'upgrade di un cluster esistente alla versione 1.16.0, gli errori dei pod relativi ad etcd-events possono bloccare l'operazione. In particolare, il job di upgrade del nodo non va a buon fine per il passaggio TASK [etcd_events_install : Run etcdevents].

Se questo problema ti riguarda, vedrai errori dei pod come il seguente:

  • Il pod kube-apiserver non si avvia con il seguente errore:
    connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused"
    
  • Il pod etcd-events non si avvia con il seguente errore:
    Error: error syncing endpoints with etcd: context deadline exceeded
    

Soluzione alternativa:

Se non riesci a eseguire l'upgrade del cluster a una versione che presenta la correzione, utilizza la seguente soluzione alternativa temporanea per risolvere gli errori:

  1. Utilizza SSH per accedere al nodo del piano di controllo con gli errori segnalati.
  2. Modifica il file manifest etcd-events, /etc/kubernetes/manifests/etcd-events.yaml e rimuovi il flag initial-cluster-state=existing.
  3. Applica il manifest.
  4. L'upgrade dovrebbe continuare.
Networking 1.15.0-1.15.2

CoreDNS orderPolicy non riconosciuto

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

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


Soluzione alternativa:

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

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

Gateway di rete per componenti GDC rimossi o in attesa a causa di una classe di priorità mancante

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

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

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


Soluzione alternativa:

Esegui l'upgrade alla versione 1.15 o successive.

Come soluzione a breve termine, puoi assegnare manualmente un elemento PriorityClass ai componenti Gateway di rete per i componenti GDC. Il controller GKE su Bare Metal sovrascrive queste modifiche manuali durante un processo di riconciliazione, ad esempio durante l'upgrade di un cluster.

  • Assegna il valore PriorityClass system-cluster-critical ai deployment dei controller di cluster ang-controller-manager e autoscaler.
  • Assegna il PriorityClass system-node-critical al nodo ang-daemon DaemonSet.
Installazione, upgrade e aggiornamenti 1,15.0, 1.15.1, 1.15.2

Creazione e upgrade del cluster non riusciti a causa della lunghezza del nome del cluster

La creazione di cluster della versione 1.15.0, 1.15.1 o 1.15.2 o l'upgrade dei cluster alla versione 1.15.0, 1.15.1 o 1.15.2 non riesce quando il nome del cluster ha più di 48 caratteri (versione 1.15.0) o 45 caratteri (versione 1.15.1 o 1.15.2). Durante le operazioni di creazione e upgrade del cluster, GKE su Bare Metal crea una risorsa di controllo di integrità con un nome che incorpora il nome e la versione del cluster:

  • Per i cluster della versione 1.15.0, il nome della risorsa per il controllo di integrità è CLUSTER_NAME-add-ons-CLUSTER_VER.
  • Per i cluster versione 1.15.1 o 1.15.2, il nome della risorsa di controllo di integrità è CLUSTER_NAME-kubernetes-CLUSTER_VER.

Per i nomi dei cluster lunghi, il nome della risorsa di controllo di integrità supera la limitazione di 63 caratteri di Kubernetes per i nomi delle etichette, il che impedisce la creazione della risorsa di controllo di integrità. Senza un controllo di integrità riuscito, l'operazione del cluster ha esito negativo.

Per verificare se questo problema ti riguarda, usa kubectl describe per controllare la risorsa con errori:

kubectl describe healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Se questo problema ti riguarda, la risposta contiene un avviso per ReconcileError come il seguente:

...
Events:
  Type     Reason          Age                   From                    Message
  ----     ------          ----                  ----                    -------
  Warning  ReconcileError  77s (x15 over 2m39s)  healthcheck-controller  Reconcile error, retrying: 1 error occurred:
           * failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]

Soluzione

Per sbloccare l'upgrade o la creazione del cluster, puoi ignorare il controllo di integrità. Utilizza il comando seguente per applicare una patch alla risorsa personalizzata del controllo di integrità in modo che venga superato lo stato: (status: {pass: true})

kubectl patch healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG --type=merge \
    --subresource status --patch 'status: {pass: true}'
Upgrade e aggiornamenti 1,14, 1,15

I cluster della versione 1.14.0 e 1.14.1 con funzionalità di anteprima non possono eseguire l'upgrade alla versione 1.15.x

Se nei cluster delle versioni 1.14.0 e 1.14.1 è abilitata una funzionalità di anteprima, non sarà possibile eseguire correttamente l'upgrade alla versione 1.15.x. Questo si applica a funzionalità in anteprima come la possibilità di creare un cluster senza kube-proxy, che è abilitato con la seguente annotazione nel file di configurazione del cluster:

preview.baremetal.cluster.gke.io/kube-proxy-free: "enable"

Se questo problema ti riguarda, durante l'upgrade del cluster viene visualizzato un errore come il seguente:

[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:

Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version

Questo problema è stato risolto nella versione 1.14.2 e nei cluster successivi.


Soluzione alternativa:

Se non riesci a eseguire l'upgrade dei cluster alla versione 1.14.2 o successive prima di eseguire l'upgrade alla versione 1.15.x, puoi eseguire direttamente l'upgrade alla versione 1.15.x utilizzando un cluster di bootstrap:

bmctl upgrade cluster --use-bootstrap=true
Operazione 1,15

I cluster della versione 1.15 non accettano indirizzi IP mobili duplicati

Il gateway di rete per GDC non consente di creare nuove risorse personalizzate NetworkGatewayGroup contenenti indirizzi IP in spec.floatingIPs già utilizzati nelle risorse personalizzate NetworkGatewayGroup esistenti. Questa regola viene applicata da un webhook in GKE su cluster Bare Metal versione 1.15.0 e successive. Gli indirizzi IP mobili duplicati preesistenti non causano errori. Il webhook impedisce solo la creazione di nuove risorse personalizzate NetworkGatewayGroups che contengono indirizzi IP duplicati.

Il messaggio di errore relativo al webhook identifica l'indirizzo IP in conflitto e la risorsa personalizzata esistente che lo utilizza già:

IP address exists in other gateway with name default

La documentazione iniziale per le funzionalità di networking avanzate, ad esempio il gateway NAT in uscita, non mette in guardia contro gli indirizzi IP duplicati. Inizialmente, lo strumento di riconciliazione ha riconosciuto solo la risorsa NetworkGatewayGroup denominata default. Il gateway di rete per GDC ora riconosce tutte le risorse personalizzate NetworkGatewayGroup nello spazio dei nomi del sistema. Le risorse personalizzate NetworkGatewayGroup esistenti verranno rispettate così come sono.


Soluzione alternativa:

Gli errori si verificano solo per la creazione di una nuova risorsa personalizzata NetworkGatewayGroup.

Per correggere l'errore:

  1. Utilizza questo comando per elencare NetworkGatewayGroups risorse personalizzate:
    kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system -o yaml
    
  2. Apri le risorse personalizzate NetworkGatewayGroup esistenti e rimuovi gli indirizzi IP mobili in conflitto (spec.floatingIPs):
    kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system RESOURCE_NAME
    
  3. Per applicare le modifiche, chiudi e salva le risorse personalizzate modificate.
Runtime VM su GDC 1.13.7

Le VM potrebbero non essere avviate su cluster 1.13.7 che utilizzano un registro privato

Quando abiliti il runtime VM su GDC su un cluster della versione 1.13.7 nuova o aggiornata che utilizza un registro privato, le VM che si connettono alla rete di nodi o utilizzano una GPU potrebbero non avviarsi correttamente. Questo problema è dovuto al fatto che alcuni pod di sistema nello spazio dei nomi vm-system ricevono errori di pull dell'immagine. Ad esempio, se la VM utilizza la rete di nodi, alcuni pod potrebbero segnalare errori di pull delle immagini come i seguenti:

macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

Questo problema è stato risolto nella versione 1.14.0 e successive di GKE su cluster Bare Metal.

Soluzione

Se non riesci a eseguire immediatamente l'upgrade dei cluster, puoi eseguire il pull delle immagini manualmente. I seguenti comandi eseguono il pull dell'immagine del plug-in CNI macvtap per la tua VM ed esegue il push al tuo registro privato:

docker pull \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21

Sostituisci REG_HOST con il nome di dominio di un host di cui esegui il mirroring localmente.

Installazione 1,11, 1,12

Durante la creazione del cluster nel cluster di tipo, il pod gke-metric-agent non si avvia

Durante la creazione del cluster nel cluster di tipo, il pod gke-metrics-agent non si avvia a causa di un errore di pull dell'immagine come segue:

error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Inoltre, nel log containerd del cluster di bootstrap, vedrai la voce seguente:

Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Nel pod viene visualizzato il seguente errore "impossibile eseguire il pull":

gcr.io/gke-on-prem-staging/gke-metrics-agent

Soluzione

Nonostante gli errori, il processo di creazione del cluster non è bloccato perché lo scopo del pod gke-metrics-agent nel cluster tipo è facilitare la percentuale di successo della creazione del cluster e il monitoraggio e il monitoraggio interni. Pertanto, puoi ignorare questo errore.

Soluzione

Nonostante gli errori, il processo di creazione del cluster non è bloccato perché lo scopo del pod gke-metrics-agent nel cluster tipo è facilitare la percentuale di successo della creazione del cluster e il monitoraggio e il monitoraggio interni. Pertanto, puoi ignorare questo errore.

Operazione, networking 1,12; 1,13; 1,14; 1,15; 1,16; 1,28

L'accesso a un endpoint di servizio IPv6 ha un arresto anomalo del nodo LoadBalancer su CentOS o RHEL

Quando accedi a un servizio a doppio stack (un servizio che ha endpoint IPv4 e IPv6) e utilizzi l'endpoint IPv6, il nodo LoadBalancer che gestisce il servizio potrebbe arrestarsi in modo anomalo. Questo problema riguarda i clienti che utilizzano servizi a doppio stack con CentOS o RHEL e una versione del kernel precedente a kernel-4.18.0-372.46.1.el8_6.

Se ritieni che questo problema ti riguardi, controlla la versione del kernel sul nodo LoadBalancer utilizzando il comando uname -a.


Soluzione alternativa:

Aggiorna il nodo LoadBalancer alla versione del kernel kernel-4.18.0-372.46.1.el8_6 o successiva. Questa versione del kernel è disponibile per impostazione predefinita in CentOS e RHEL versione 8.6 e successive.

Networking 1,11; 1,12; 1,13; 1,14,0

Problemi di connettività intermittenti dopo il riavvio del nodo

Dopo aver riavviato un nodo, potresti riscontrare problemi di connettività intermittente per un servizio NodePort o LoadBalancer. Ad esempio, potresti riscontrare errori di handshake TLS intermittente o di reimpostazione della connessione. Questo problema è stato risolto per i cluster 1.14.1 e versioni successive.

Per verificare se questo problema ti riguarda, controlla le iptables regole di forwarding sui nodi in cui è in esecuzione il pod di backend per il servizio interessato:

sudo iptables -L FORWARD

Se vedi la regola KUBE-FORWARD prima della regola CILIUM_FORWARD in iptables, questo problema potrebbe essere interessato da questo problema. Il seguente output di esempio mostra un Nodo in cui si verifica il problema:

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */

Soluzione alternativa:

Riavvia il pod anetd sul nodo configurato in modo errato. Dopo aver riavviato il pod anetd, la regola di forwarding in iptables dovrebbe essere configurata correttamente.

Il seguente output di esempio mostra che la regola CILIUM_FORWARD è ora configurata correttamente prima della regola KUBE-FORWARD:

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
Upgrade e aggiornamenti 1,9, 1,10

La funzionalità di anteprima non conserva l'autorizzazione originale e le informazioni sul proprietario

La funzionalità di anteprima del cluster 1.9.x che utilizza bmctl 1.9.x non conserva le autorizzazioni originali e le informazioni sul proprietario. Per verificare se questa funzionalità ti riguarda, estrai il file di cui hai eseguito il backup utilizzando il seguente comando:

tar -xzvf BACKUP_FILE

Soluzione

Verifica se metadata.json è presente e se bmctlVersion è 1.9.x. Se metadata.json non è presente, esegui l'upgrade al cluster 1.10.x e utilizza bmctl 1.10.x per eseguire il backup e il ripristino.

Upgrade e creazioni 1.14.2

clientconfig-operator bloccato nello stato di attesa con CreateContainerConfigError

Se hai creato o eseguito l'upgrade a un cluster versione 1.14.2 con una configurazione OIDC/LDAP, potresti vedere il pod clientconfig-operator bloccato in stato In sospeso. Con questo problema sono presenti due pod clientconfig-operator, uno in stato in esecuzione e l'altro in stato In attesa.

Questo problema si applica solo ai cluster della versione 1.14.2. Le versioni precedenti dei cluster, come 1.14.0 e 1.14.1, non sono interessate. Questo problema è stato risolto nella versione 1.14.3 e in tutte le release successive, inclusa la versione 1.15.0 e successive.


Soluzione alternativa:

Come soluzione alternativa, puoi applicare una patch al deployment di clientconfig-operator per aggiungere ulteriore contesto di sicurezza e assicurarti che il deployment sia pronto.

Usa questo comando per applicare la patch a clientconfig-operator nel cluster di destinazione:

kubectl patch deployment clientconfig-operator -n kube-system \
    -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \
    --kubeconfig CLUSTER_KUBECONFIG

Sostituisci quanto segue:

  • CLUSTER_KUBECONFIG: il percorso del file kubeconfig per il cluster di destinazione.
Operazione 1,11; 1,12; 1,13; 1,14; 1,15

La rotazione dell'autorità di certificazione non riesce per i cluster senza bilanciamento del carico in bundle

Per i cluster senza bilanciamento del carico in bundle (spec.loadBalancer.mode impostato su manual), il comando bmctl update credentials certificate-authorities rotate può non rispondere e non riuscire con il seguente errore: x509: certificate signed by unknown authority.

Se riscontri questo problema, il comando bmctl potrebbe restituire il seguente messaggio prima di non rispondere:

Signing CA completed in 3/0 control-plane nodes

In questo caso, il comando non riesce. Il log di rotazione dell'autorità di certificazione per un cluster con tre piani di controllo può includere voci come le seguenti:

[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")

Soluzione

Se hai bisogno di ulteriore aiuto, contatta l'Assistenza Google.

Installazione, networking 1,11, 1,12, 1,13, 1,14,0-1,14,1

ipam-controller-manager arresto anomalo in cluster a doppio stack

Quando esegui il deployment di un cluster a doppio stack (un cluster con indirizzi IPv4 e IPv6), i pod ipam-controller-manager potrebbero arrestarsi in modo anomalo. Questo comportamento causa il ciclo dei nodi tra gli stati Ready e NotReady e potrebbe causare la mancata installazione del cluster. Questo problema può verificarsi quando il server API è sottoposto a un carico elevato.

Per verificare se questo problema ti riguarda, controlla se i pod ipam-controller-manager presentano errori e CrashLoopBackOff:

kubectl -n kube-system get pods | grep  ipam-controller-manager

Il seguente output di esempio mostra i pod in stato CrashLoopBackOff:

ipam-controller-manager-h7xb8   0/1  CrashLoopBackOff   3 (19s ago)   2m ipam-controller-manager-vzrrf   0/1  CrashLoopBackOff   3 (19s ago)   2m1s
ipam-controller-manager-z8bdw   0/1  CrashLoopBackOff   3 (31s ago)   2m2s

Ottieni i dettagli del nodo in stato NotReady:

kubectl describe node <node-name> | grep PodCIDRs

In un cluster con questo problema, a un nodo non sono assegnati PodCIDR, come mostrato nell'output di esempio seguente:

PodCIDRs:

In un cluster integro, a tutti i nodi devono essere assegnati PodCIDR a doppio stack, come mostrato nell'output di esempio seguente:

PodCIDRs:    192.168.6.0/24,222:333:444:555:5:4:7:0/120

Soluzione alternativa:

Riavvia i pod ipam-controller-manager:

kubectl -n kube-system rollout restart ds ipam-controller-manager
Operazione 1,6, 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13 e 1,14

CANNOT TRANSLATE

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

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

Questi problemi possono rendere il cluster non funzionante.

Questo problema è stato risolto in GDCV per Bare Metal versione 1.12.9, 1.13.6, 1.14.3 e versioni successive. Queste release più recenti utilizzano etcd la versione 3.4.21. Tutte le versioni precedenti di GDCV per Bare Metal sono interessate da questo problema.

Soluzione

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

Per visualizzare questa metrica in Metrics Explorer:

  1. Vai a Metrics Explorer nella console Google Cloud:

    Vai a Metrics Explorer

  2. Seleziona la scheda Configurazione.
  3. Espandi Seleziona una metrica, inserisci Kubernetes Container nella barra dei filtri, poi utilizza i sottomenu per selezionare la metrica:
    1. Nel menu Risorse attive, seleziona Container Kubernetes.
    2. Nel menu Categorie di metriche attive, seleziona Anthos.
    3. Nel menu Metriche attive, seleziona etcd_network_client_grpc_sent_bytes_total.
    4. Fai clic su Applica.
Networking 1.11.6, 1.12.3

Stato "Non riuscito " della modalità vfio-pci dell'operatore SR-IOV

L'elemento syncStatus dell'oggetto SriovNetworkNodeState può segnalare il valore "Non riuscito" per un nodo configurato. Per visualizzare lo stato di un nodo e determinare se il problema ti riguarda, esegui questo comando:

kubectl -n gke-operators get \
    sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
    -o jsonpath='{.status.syncStatus}'

Sostituisci NODE_NAME con il nome del nodo da controllare.


Soluzione alternativa:

Se lo stato dell'oggetto SriovNetworkNodeState è "Non riuscito", esegui l'upgrade del cluster alla versione 1.11.7 o successiva o alla versione 1.12.4 o successiva.

Upgrade e aggiornamenti 1,10; 1,11; 1,12; 1,13; 1,14,0; 1,14,1

Alcuni nodi worker non sono in stato Pronto dopo l'upgrade

Al termine dell'upgrade, la condizione Pronto di alcuni nodi worker potrebbe essere impostata su false. Nella risorsa Nodo, vedrai un errore accanto alla condizione Pronto simile all'esempio seguente:

container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Quando accedi alla macchina bloccata, la configurazione CNI sulla macchina è vuota:

sudo ls /etc/cni/net.d/

Soluzione

Riavvia il pod anetd del nodo eliminandolo.

Upgrade e aggiornamenti, Sicurezza 1,1

Più rotazioni di certificati da cert-manager generano incoerenze

Dopo più rotazioni manuali o automatiche dei certificati, il pod webhook, ad esempio anthos-cluster-operator, non viene aggiornato con i nuovi certificati emessi da cert-manager. Qualsiasi aggiornamento della risorsa personalizzata del cluster non riesce e genera un errore simile al seguente:

Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")

Questo problema può verificarsi nelle seguenti circostanze:

  • Se hai eseguito due rotazioni manuali dei certificati rilasciate dal gestore dei certificati su un cluster più vecchio di 180 giorni e non hai mai riavviato anthos-cluster-operator.
  • Se hai eseguito manualmente un cert-manager, hai emesso rotazioni di certificati su un cluster più vecchio di 90 giorni o più e non ha mai riavviato anthos-cluster-operator.

Soluzione

Riavvia il pod arrestando anthos-cluster-operator.

Upgrade e aggiornamenti 1.14.0

Pod del deployment del controller del ciclo di vita obsoleti creati durante l'upgrade del cluster utente

Nei cluster di amministrazione della versione 1.14.0, durante gli upgrade del cluster utente potrebbero essere creati uno o più pod del deployer del controller del ciclo di vita obsoleti. Questo problema si applica ai cluster utente creati inizialmente con versioni precedenti alla 1.12. I pod creati involontariamente non ostacolano le operazioni di upgrade, ma potrebbero trovarsi in uno stato imprevisto. Ti consigliamo di rimuovere i pod obsoleti.

Questo problema è stato risolto nella release 1.14.1.

Soluzione alternativa:

Per rimuovere i pod obsoleti del deployment del controller del ciclo di vita:

  1. Elenca le risorse per i controlli preflight:
    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A
    

    L'output sarà simile al seguente:

    NAMESPACE                    NAME                      PASS   AGE
    cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31c        true   20d
    cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31cd6jv6   false  20d
    

    dove ci-87a021b9dcbb31c è il nome del cluster.

  2. Elimina le risorse il cui valore nella colonna PASS è true o false.

    Ad esempio, per eliminare le risorse nell'output di esempio precedente, utilizza i comandi seguenti:

    kubectl delete preflightchecks ci-87a021b9dcbb31c \
        -n cluster-ci-87a021b9dcbb31c \
        --kubeconfig ADMIN_KUBECONFIG 
    kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
        -n cluster-ci-87a021b9dcbb31c \
        --kubeconfig ADMIN_KUBECONFIG
    
Networking 1,9; 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28

Lo stato BGPSession cambia costantemente a causa dell'elevato numero di route in entrata

Il networking avanzato GKE su Bare Metal non è in grado di gestire correttamente le sessioni BGP quando peer esterni pubblicizzano un numero elevato di route (circa 100 o più). Con un numero elevato di route in entrata, il controller BGP locale del nodo impiega troppo tempo per riconciliare le sessioni BGP e non riesce ad aggiornare lo stato. La mancanza di aggiornamenti dello stato o di un controllo di integrità causa l'eliminazione della sessione perché non aggiornata.

Ecco i comportamenti indesiderati delle sessioni BGP che potresti notare e indicare un problema:

  • Eliminazione e ricreazione continua di bgpsession.
  • bgpsession.status.state non diventa mai Established
  • Mancata pubblicità o ripetutamente pubblicizzate e ritirate.

I problemi di bilanciamento del carico BGP potrebbero essere evidenti con problemi di connettività ai servizi LoadBalancer.

Il problema FlatIP BGP potrebbe essere evidente in caso di problemi di connettività ai pod.

Per determinare se i problemi BGP sono causati dai peer remoti che pubblicizzano troppe route, utilizza i seguenti comandi per esaminare gli stati e l'output associati:

  • Usa kubectl get bgpsessions sul cluster interessato. L'output mostra bgpsessions con lo stato "Non stabilita" e l'orario dell'ultimo report conta fino a circa 10-12 secondi prima che sembri azzerato.
  • L'output di kubectl get bgpsessions indica che le sessioni interessate vengono ricreate ripetutamente:
    kubectl get bgpsessions \
        -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
    
  • I messaggi di log indicano che le sessioni BGP inattive vengono eliminate:
    kubectl logs ang-controller-manager-POD_NUMBER
    

    Sostituisci POD_NUMBER con il pod leader nel tuo cluster.


Soluzione alternativa:

Riduci o elimina il numero di route annunciate dal peer remoto al cluster con un criterio di esportazione.

Nel cluster GKE su Bare Metal versione 1.14.2 e successive, puoi anche disabilitare la funzionalità che elabora le route ricevute utilizzando un AddOnConfiguration. Aggiungi l'argomento --disable-received-routes al container bgpd del daemonset ang-daemon.

Networking 1,14; 1,15; 1,16; 1,28

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

I cluster in esecuzione su un sistema operativo Ubuntu che utilizza il kernel 5.15 o versioni successive sono soggetti a errori di inserimento della tabella di monitoraggio delle connessioni di netfilter (conntrack). Gli errori di inserimento possono verificarsi anche quando la tabella conntrack ha spazio per nuove voci. Gli errori sono causati da modifiche nel kernel 5.15 e nelle versioni successive che limitano gli inserimento delle tabelle in base alla lunghezza della catena.

Per verificare se questo problema ti riguarda, puoi controllare le statistiche di sistema di monitoraggio delle connessioni nel kernel con il seguente comando:

sudo conntrack -S

La risposta sarà simile alla seguente:

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

Se un valore chaintoolong nella risposta è un numero diverso da zero, sei interessato da questo problema.

Soluzione

La mitigazione a breve termine prevede l'aumento delle dimensioni della tabella di hash netfiler (nf_conntrack_buckets) e della tabella di monitoraggio delle connessioni netfilter (nf_conntrack_max). Utilizza i seguenti comandi su ciascun nodo cluster per aumentare le dimensioni delle tabelle:

sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE

sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

Sostituisci TABLE_SIZE con la nuova dimensione in byte. Il valore predefinito per le dimensioni della tabella è 262144. Ti suggeriamo di impostare un valore pari a 65.536 volte il numero di core sul nodo. Ad esempio, se il nodo ha otto core, imposta la dimensione della tabella su 524288.

Upgrade e aggiornamenti 1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1.13.4,

Impossibile ripristinare i backup del cluster con bmctl per alcune versioni

Ti consigliamo di eseguire il backup dei cluster prima dell'upgrade, in modo da poter ripristinare la versione precedente in caso di esito negativo. Un problema con il comando bmctl restore cluster ne impedisce il ripristino dei backup dei cluster con le versioni identificate. Questo problema riguarda in modo specifico gli upgrade, in cui stai ripristinando un backup di una versione precedente.

Se il cluster è interessato, il log bmctl restore cluster contiene il seguente errore:

Error: failed to extract image paths from profile: anthos version VERSION not supported

Soluzione alternativa:

Finché il problema non sarà risolto, ti consigliamo di seguire le istruzioni riportate in Effettuare il backup e il ripristino dei cluster per eseguire il backup manuale dei cluster e ripristinarli manualmente, se necessario.
Networking 1,10, 1,11, 1,12, 1,13, 1,14,0-1,14,2

NetworkGatewayGroup si arresta in modo anomalo se non è presente alcun indirizzo IP nell'interfaccia

NetworkGatewayGroup non riesce a creare daemon per i nodi che non hanno interfacce IPv4 e IPv6. Questo causa l'errore di funzionalità come BGP LB e OutboundNAT. Se controlli i log del pod ang-node con errori nello spazio dei nomi kube-system, vengono visualizzati errori simili all'esempio seguente quando manca un indirizzo IPv6:

ANGd.Setup    Failed to create ANG daemon    {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}

Nell'esempio precedente, non è presente un indirizzo IPv6 nell'interfaccia di ens192. Errori ARP simili vengono visualizzati se nel nodo manca un indirizzo IPv4.

NetworkGatewayGroup tenta di stabilire una connessione ARP e una connessione NDP all'indirizzo IP locale del collegamento. Se l'indirizzo IP non esiste (IPv4 per ARP, IPv6 per NDP), la connessione non riesce e il daemon non continua.

Questo problema è stato risolto nella release 1.14.3.


Soluzione alternativa:

Connettiti al nodo utilizzando SSH e aggiungi un indirizzo IPv4 o IPv6 al link che contiene l'IP del nodo. Nella voce di log di esempio precedente, questa interfaccia era ens192:

ip address add dev INTERFACE scope link ADDRESS

Sostituisci quanto segue:

  • INTERFACE: l'interfaccia del nodo, ad esempio ens192.
  • ADDRESS: l'indirizzo IP e la subnet mask da applicare all'interfaccia.
Ripristino/eliminazione 1,10, 1,11, 1,12, 1,13,0-1,13,2

Loop di arresto anomalo di anthos-cluster-operator durante la rimozione di un nodo del piano di controllo

Quando provi a rimuovere un nodo del piano di controllo rimuovendo l'indirizzo IP da Cluster.Spec, anthos-cluster-operator entra in uno stato di loop di arresto anomalo che blocca qualsiasi altra operazione.


Soluzione alternativa:

Il problema è stato risolto nelle versioni 1.13.3 e 1.14.0 e successive. Sono interessate tutte le altre versioni. Esegui l'upgrade a una delle versioni corrette

Come soluzione alternativa, esegui questo comando:

kubectl label baremetalmachine IP_ADDRESS \
    -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply-

Sostituisci quanto segue:

  • IP_ADDRESS: l'indirizzo IP del nodo in uno stato di loop di arresto anomalo.
  • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.
Installazione 1.13.1, 1.13.2 e 1.13.3

kubeadm join errore nei cluster di grandi dimensioni a causa di una mancata corrispondenza dei token

Quando installi GKE su cluster Bare Metal con un numero elevato di nodi, potresti visualizzare un messaggio di errore kubeadmin join simile al seguente esempio:

TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440   99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440   99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}

Soluzione alternativa:

Questo problema è stato risolto in GDCV per Bare Metal versione 1.13.4 e successive.

Se devi utilizzare una versione interessata, crea prima un cluster con meno di 20 nodi, quindi ridimensiona il cluster in modo da aggiungere altri nodi al termine dell'installazione.

Logging e monitoraggio 1,10; 1,11; 1,12; 1,13,0

Limite di CPU basso per metrics-server nei cluster perimetrali

Nei cluster GKE su Bare Metal Edge, i limiti bassi di CPU per metrics-server possono causare riavvii frequenti di metrics-server. Scalabilità automatica orizzontale dei pod (HPA) non funziona perché metrics-server non è integro.

Se il limite di metrics-server CPU è inferiore a 40m, i cluster possono essere interessati. Per verificare i limiti della CPU metrics-server, esamina uno dei seguenti file:

  • Cluster GKE su Bare Metal versione 1.x-1.12:
    kubectl get deployment metrics-server -n kube-system \
        -o yaml > metrics-server.yaml
    
  • Cluster GKE su Bare Metal versione 1.13 o successive:
    kubectl get deployment metrics-server -n gke-managed-metrics-server \
        -o yaml > metrics-server.yaml
    

Soluzione alternativa:

Questo problema è stato risolto in GKE su cluster Bare Metal versione 1.13.1 o successive. Per risolvere il problema, esegui l'upgrade dei cluster.

Una soluzione alternativa a breve termine fino a quando non puoi eseguire l'upgrade dei cluster consiste nell'aumentare manualmente i limiti della CPU per metrics-server come segue:

  1. Scale down di metrics-server-operator:
    kubectl scale deploy metrics-server-operator --replicas=0
  2. Aggiorna la configurazione e aumenta i limiti della CPU:
    • Cluster GKE su Bare Metal versione 1.x-1.12:
      kubectl -n kube-system edit deployment metrics-server
    • Cluster GKE su Bare Metal versione 1.13:
      kubectl -n gke-managed-metrics-server edit deployment metrics-server

    Rimuovi la riga --config-dir=/etc/config e aumenta i limiti della CPU, come mostrato nell'esempio seguente:

    [...]
    - command:
    - /pod_nanny
    # - --config-dir=/etc/config # <--- Remove this line
    - --container=metrics-server
    - --cpu=50m # <--- Increase CPU, such as to 50m
    - --extra-cpu=0.5m
    - --memory=35Mi
    - --extra-memory=4Mi
    - --threshold=5
    - --deployment=metrics-server
    - --poll-period=30000
    - --estimator=exponential
    - --scale-down-delay=24h
    - --minClusterSize=5
    - --use-metrics=true
    [...]
    
  3. Salva e chiudi metrics-server per applicare le modifiche.
Networking 1,14; 1,15; 1,16

La connessione NodePort diretta al pod hostNetwork non funziona

La connessione a un pod abilitato con hostNetwork tramite il servizio NodePort non riesce quando il pod di backend si trova sullo stesso nodo della NodePort di destinazione. Questo problema interessa i servizi LoadBalancer quando vengono utilizzati con pod hostNetwork. In presenza di più backend, si possono verificare sporadi errori di connessione.

Questo problema è causato da un bug del programma eBPF.


Soluzione alternativa:

Quando utilizzi un servizio Nodeport, non scegliere come target il nodo su cui viene eseguito il pod di backend. Quando utilizzi il servizio LoadBalancer, assicurati che i pod hostNetwork non vengano eseguiti su nodi LoadBalancer.

Upgrade e aggiornamenti 1.12.3, 1.13.0

I cluster di amministrazione 1.13.0 non possono gestire i cluster utente 1.12.3

I cluster di amministrazione che eseguono la versione 1.13.0 non possono gestire i cluster utente che eseguono la versione 1.12.3. Le operazioni su un cluster utente della versione 1.12.3 non riescono.


Soluzione alternativa:

Esegui l'upgrade del cluster di amministrazione alla versione 1.13.1 oppure del cluster utente alla stessa versione del cluster di amministrazione.

Upgrade e aggiornamenti 1,12

L'upgrade a 1.13.x è bloccato per i cluster di amministrazione con pool di nodi worker

I cluster di amministrazione della versione 1.13.0 e successive non possono contenere pool di nodi worker. Gli upgrade alla versione 1.13.0 o successive per i cluster di amministrazione con pool di nodi worker sono bloccati. Se l'upgrade del cluster di amministrazione è bloccato, puoi verificare se la causa è costituita dai pool di nodi worker controllando il seguente errore nel file upgrade-cluster.log all'interno della cartella bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.

Soluzione alternativa:

Prima di eseguire l'upgrade, sposta tutti i pool di nodi worker nei cluster utente. Per istruzioni su come aggiungere e rimuovere pool di nodi, consulta Gestire i pool di nodi in un cluster.

Upgrade e aggiornamenti 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28

Errori durante l'aggiornamento delle risorse utilizzando kubectl apply

Se aggiorni risorse esistenti come le risorse personalizzate ClientConfig o Stackdriver utilizzando kubectl apply, il controller potrebbe restituire un errore o ripristinare l'input e le modifiche pianificate.

Ad esempio, potresti provare a modificare la risorsa personalizzata Stackdriver come segue, recuperando prima la risorsa e poi applicando una versione aggiornata:

  1. Recupera la definizione YAML esistente:
    kubectl get stackdriver -n kube-system stackdriver \
        -o yaml > stackdriver.yaml
    
  2. Abilita le funzionalità o aggiorna la configurazione nel file YAML.
  3. Applica nuovamente il file YAML aggiornato:
    kubectl apply -f stackdriver.yaml
    

Il passaggio finale per kubectl apply è il punto in cui potresti riscontrare problemi.


Soluzione alternativa:

Non utilizzare kubectl apply per apportare modifiche alle risorse esistenti. Utilizza invece kubectl edit o kubectl patch come mostrato negli esempi seguenti:

  1. Modifica la risorsa personalizzata Stackdriver:
    kubectl edit stackdriver -n kube-system stackdriver
    
  2. Abilita le funzionalità o aggiorna la configurazione nel file YAML.
  3. Salva ed esci dall'editor

Approccio alternativo utilizzando kubectl patch:

  1. Recupera la definizione YAML esistente:
    kubectl get stackdriver -n kube-system stackdriver \
        -o yaml > stackdriver.yaml
    
  2. Abilita le funzionalità o aggiorna la configurazione nel file YAML.
  3. Applica nuovamente il file YAML aggiornato:
    kubectl patch stackdriver stackdriver --type merge \
        -n kube-system --patch-file stackdriver.yaml
    
Logging e monitoraggio 1,12; 1,13; 1,14; 1,15; 1,16

I blocchi di backlog danneggiati causano un arresto anomalo di stackdriver-log-forwarder

L'arresto anomalo di stackdriver-log-forwarder si arresta se tenta di elaborare un blocco di backlog danneggiato. Nei log dei container vengono visualizzati i seguenti errori di esempio:

[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks

Quando si verifica questo arresto anomalo, non puoi visualizzare i log in Cloud Logging.


Soluzione alternativa:

Per risolvere questi errori, completa i seguenti passaggi:

  1. Identifica i blocchi di backlog danneggiati. Esamina i seguenti messaggi di errore di esempio:
    [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
    [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
    
    In questo esempio, il file tail.1/1-1659339894.252926599.flb archiviato in var/log/fluent-bit-buffers/tail.1/ è errore. Ogni file *.flb con un controllo del formato non riuscito deve essere rimosso.
  2. Termina i pod in esecuzione per stackdriver-log-forwarder:
    kubectl --kubeconfig KUBECONFIG -n kube-system \
        patch daemonset stackdriver-log-forwarder \
        -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
    
    Sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster utente.

    Verifica che i pod stackdriver-log-forwarder vengano eliminati prima di andare al passaggio successivo.
  3. Connettiti al nodo tramite SSH su cui è in esecuzione stackdriver-log-forwarder.
  4. Elimina tutti i file *.flb danneggiati nel nodo in var/log/fluent-bit-buffers/tail.1/.

    Se ci sono troppi file danneggiati e vuoi applicare uno script per ripulire tutti i blocchi di backlog, utilizza gli script seguenti:
    1. Esegui il deployment di un DaemonSet per ripulire tutti i dati non più presenti nei buffer in fluent-bit:
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -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
      
    2. Assicurati che il DaemonSet abbia ripulito tutti i nodi. L'output dei due comandi seguenti dovrebbe essere uguale al numero di nodi nel cluster:
      kubectl --kubeconfig KUBECONFIG logs \
          -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
      kubectl --kubeconfig KUBECONFIG \
          -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
      
    3. Elimina il DaemonSet di pulizia:
      kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
          fluent-bit-cleanup
      
    4. Riavvia i pod stackdriver-log-forwarder:
      kubectl --kubeconfig KUBECONFIG \
          -n kube-system patch daemonset stackdriver-log-forwarder --type json \
          -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
      
Networking, runtime VM su GDC 1.14.0

Il riavvio di Dataplane V2 (anetd) sui cluster può comportare l'impossibilità di collegare le VM esistenti a una rete non pod

Nei cluster con più nic, il riavvio di Dataplane V2 (anetd) può comportare l'impossibilità di collegare le macchine virtuali alle reti. Nei log dei pod anetd potrebbe essere osservato un errore simile al seguente:

could not find an allocator to allocate the IP of the multi-nic endpoint

Soluzione alternativa:

Per risolvere rapidamente il problema, puoi riavviare la VM. Per evitare che il problema si ripeta, esegui l'upgrade del cluster alla versione 1.14.1 o successiva.

Operazione 1,13, 1.14.0, 1.14.1

gke-metrics-agent non ha limiti di memoria sui cluster del profilo perimetrale

A seconda del carico di lavoro del cluster, gke-metrics-agent potrebbe utilizzare più di 4608 MiB di memoria. Questo problema riguarda solo i cluster di profilo GKE su Bare Metal Edge. I cluster del profilo predefiniti non sono interessati.


Soluzione alternativa:

Esegui l'upgrade del cluster alla versione 1.14.2 o successive.

Installazione 1,12, 1,13

La creazione del cluster potrebbe non riuscire a causa delle condizioni di gara

Quando crei i cluster utilizzando kubectl, a causa delle condizioni di gara, il controllo preflight potrebbe non terminare. Di conseguenza, in alcuni casi la creazione del cluster potrebbe non riuscire.

Lo strumento di riconciliazione dei controlli preflight crea un SecretForwarder per copiare il secret ssh-key predefinito nello spazio dei nomi di destinazione. In genere, il controllo preflight si basa sui riferimenti del proprietario e si riconcilia una volta completato il criterio SecretForwarder. Tuttavia, in rari casi il proprietario fa riferimento a SecretForwarder può perdere il riferimento al controllo preflight, causando il blocco di quest'ultimo. Di conseguenza, la creazione del cluster non riesce. Per continuare la riconciliazione per il controllo preflight basato su controller, elimina il pod dell'operatore del cluster o la risorsa del controllo preflight. Quando elimini la risorsa di controllo preflight, ne viene creata un'altra e la riconciliazione continua. In alternativa, puoi eseguire l'upgrade dei cluster esistenti (creati con una versione precedente) a una versione fissa.

Networking 1,9; 1,10; 1,11; 1,12; 1,13; 1,14; 1,15

Gli indirizzi IP riservati non vengono rilasciati quando si utilizza il plug-in whereabouts con la funzionalità multi-NIC

Nella funzionalità multi-Nic, se utilizzi il plug-in CNI whereabouts e l'operazione CNI DEL per eliminare un'interfaccia di rete per un pod, alcuni indirizzi IP riservati potrebbero non essere rilasciati correttamente. Questo accade quando l'operazione CNI DEL viene interrotta.

Puoi verificare le prenotazioni di indirizzi IP inutilizzati dei pod eseguendo questo comando:

kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

Soluzione alternativa :

Elimina manualmente gli indirizzi IP (ippool) che non vengono utilizzati.

Installazione 1,10, 1.11.0, 1.11.1, 1.11.2

Il rilevatore dei problemi dei nodi non funziona nel cluster utente 1.10.4

Il rilevatore di problemi dei nodi potrebbe non funzionare nei cluster utente della versione 1.10.x, quando i cluster di amministrazione della versione 1.11.0, 1.11.1 o 1.11.2 gestiscono i cluster utente 1.10.x. In caso di errore del rilevatore di problemi dei nodi, il log viene aggiornato con il seguente messaggio di errore:

Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.

Soluzione

Esegui l'upgrade del cluster di amministrazione alla versione 1.11.3 per risolvere il problema.

Operazione 1,14

1.14 nodi cluster IPv4 in modalità isola hanno una dimensione della maschera CIDR dei pod di 24

Nella release 1.14, l'impostazione maxPodsPerNode non viene presa in considerazione per i cluster in modalità isola, pertanto ai nodi viene assegnata una dimensione della maschera CIDR dei pod di 24 (256 indirizzi IP).nQuesto potrebbe causare l'esaurimento degli indirizzi IP dei pod da parte del cluster prima del previsto. Ad esempio, se il cluster ha una dimensione della maschera CIDR del pod pari a 22, a ogni nodo verrà assegnata una maschera CIDR dei pod di 24, mentre il cluster potrà supportare solo un massimo di quattro nodi. Il cluster potrebbe anche riscontrare instabilità della rete in un periodo di elevato tasso di abbandono dei pod quando il valore di maxPodsPerNode è impostato su 129 o superiore e non è previsto un overhead sufficiente nel CIDR del pod per ogni nodo.

Se il cluster è interessato, il pod anetd segnala il seguente errore quando aggiungi un nuovo nodo al cluster. Inoltre, non è disponibile podCIDR:

error="required IPv4 PodCIDR not available"

Soluzione

Per risolvere il problema:

  1. Esegui l'upgrade alla versione 1.14.1 o successiva.
  2. Rimuovi i nodi worker e aggiungili di nuovo.
  3. Rimuovi i nodi del piano di controllo e aggiungili di nuovo, preferibilmente uno alla volta per evitare tempi di inattività dei cluster.
Upgrade e aggiornamenti 1.14.0, 1.14.1

Errore di rollback dell'upgrade del cluster

Il rollback di un upgrade potrebbe non riuscire per i cluster di versione 1.14.0 o 1.14.1. Se esegui l'upgrade di un cluster dalla versione 1.14.0 alla versione 1.14.1 e poi provi a eseguire il rollback alla versione 1.14.0 utilizzando il comando bmctl restore cluster, potrebbe essere restituito un errore come nell'esempio seguente:

I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

Soluzione alternativa:

Elimina tutte le risorse healthchecks.baremetal.cluster.gke.io sotto lo spazio dei nomi del cluster, quindi esegui nuovamente il comando bmctl restore cluster:

  1. Elenca tutte le healthchecks.baremetal.cluster.gke.io risorse:
    kubectl get healthchecks.baremetal.cluster.gke.io \
        --namespace=CLUSTER_NAMESPACE \
        --kubeconfig=ADMIN_KUBECONFIG
    

    Sostituisci quanto segue:

    • CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster.
    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
  2. Elimina tutte le risorse healthchecks.baremetal.cluster.gke.io elencate nel passaggio precedente:
    kubectl delete healthchecks.baremetal.cluster.gke.io \
        HEALTHCHECK_RESOURCE_NAME \
        --namespace=CLUSTER_NAMESPACE \
        --kubeconfig=ADMIN_KUBECONFIG
    
    Sostituisci HEALTHCHECK_RESOURCE_NAME con il nome delle risorse per il controllo di integrità.
  3. Esegui nuovamente il comando bmctl restore cluster.
Networking 1.12.0

L'indirizzo IP esterno del servizio non funziona in modalità flat

In un cluster in cui flatIPv4 è impostato su true, i servizi di tipo LoadBalancer non sono accessibili dai relativi indirizzi IP esterni.

Questo problema è stato risolto nella versione 1.12.1.


Soluzione alternativa:

In ConfigMap cilium-config, imposta enable-415 su "true", quindi riavvia i pod anetd.

Upgrade e aggiornamenti 1,13,0, 1,14

Gli aggiornamenti in loco da 1.13.0 a 1.14.x non terminano mai

Quando provi a eseguire un upgrade in loco da 1.13.0 a 1.14.x utilizzando bmctl 1.14.0 e il flag --use-bootstrap=false, l'upgrade non termina mai.

Un errore nell'operatore preflight-check fa sì che il cluster non pianifichi mai i controlli richiesti, perciò il controllo preflight non termina mai.


Soluzione alternativa:

Esegui l'upgrade alla versione 1.13.1 prima di passare alla versione 1.14.x. Un upgrade in loco da 1.13.0 a 1.13.1 dovrebbe funzionare. In alternativa, esegui l'upgrade dalla versione 1.13.0 alla versione 1.14.x senza il flag --use-bootstrap=false.

Upgrade e aggiornamenti, Sicurezza 1,13 e 1,14

I cluster aggiornati alla versione 1.14.0 perdono le incompatibilità master

I nodi del piano di controllo richiedono una delle due incompatibilità specifiche per impedire la pianificazione dei pod dei carichi di lavoro su questi nodi. Quando esegui l'upgrade dei cluster GKE dalla versione 1.13 alla versione 1.14.0, i nodi del piano di controllo perdono le seguenti incompatibilità richieste:

  • node-role.kubernetes.io/master:NoSchedule
  • node-role.kubernetes.io/master:PreferNoSchedule

Questo problema non causa errori di upgrade, ma i pod che non dovrebbero essere eseguiti sui nodi del piano di controllo potrebbero iniziare a farlo. Questi pod dei carichi di lavoro possono sovraccaricare i nodi del piano di controllo e causare l'instabilità dei cluster.

Determinare se il problema ti riguarda

  1. Trova i nodi del piano di controllo, utilizza il comando seguente:
    kubectl get node -l 'node-role.kubernetes.io/control-plane' \
        -o name --kubeconfig KUBECONFIG_PATH
    
  2. Per controllare l'elenco delle incompatibilità su un nodo, utilizza il seguente comando:
    kubectl describe node NODE_NAME \
        --kubeconfig KUBECONFIG_PATH
    

    Se nessuna delle incompatibilità richieste è elencata, significa che il problema ti riguarda.

Soluzione

Per ripristinare il funzionamento corretto, segui questi passaggi per ciascun nodo del piano di controllo del cluster versione 1.14.0 interessato. Questi passaggi si riferiscono all'incompatibilità node-role.kubernetes.io/master:NoSchedule e ai pod correlati. Se vuoi che i nodi del piano di controllo utilizzino l'incompatibilità PreferNoSchedule, modifica i passaggi di conseguenza.

Operazione, runtime VM su GDC 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28; 1,29

La creazione della VM non riesce a intermittenza con errori di caricamento

La creazione di una nuova macchina virtuale (VM) con il comando kubectl virt create vm non riesce spesso durante il caricamento delle immagini. Questo problema riguarda le VM Linux e Windows. L'errore è simile al seguente esempio:

PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,  ...

Soluzione

Riprova a utilizzare il comando kubectl virt create vm per creare la VM.

Upgrade e aggiornamenti, Logging e monitoraggio 1,11

I componenti delle raccolte gestite nei cluster 1.11 non vengono conservati negli upgrade alla versione 1.12

I componenti della raccolta gestita fanno parte di Managed Service per Prometheus. Se hai eseguito manualmente il deployment dei componenti della raccolta gestita nello spazio dei nomi gmp-system dei tuoi cluster della versione 1.11, le risorse associate non vengono conservate quando esegui l'upgrade alla versione 1.12.

A partire dai cluster della versione 1.12.0, i componenti di Managed Service per Prometheus nello spazio dei nomi gmp-system e le relative definizioni di risorse personalizzate sono gestiti da stackdriver-operator con il campo enableGMPForApplications. Per impostazione predefinita, il campo enableGMPForApplications è impostato su true, quindi se esegui manualmente il deployment dei componenti di Managed Service per Prometheus nello spazio dei nomi prima di eseguire l'upgrade alla versione 1.12, le risorse vengono eliminate da stackdriver-operator.

Soluzione

Per preservare le risorse di raccolta gestite manualmente:

  1. Esegui il backup di tutte le risorse personalizzate PodMonitoring esistenti.
  2. Esegui l'upgrade del cluster alla versione 1.12 e abilita Managed Service per Prometheus.
  3. Esegui di nuovo il deployment delle risorse personalizzate PodMonitoring nel cluster di cui è stato eseguito l'upgrade.
Upgrade e aggiornamenti 1,13

Alcuni cluster di versione 1.12 con il runtime del container Docker non possono eseguire l'upgrade alla versione 1.13

Se in un cluster versione 1.12 che utilizza il runtime del container Docker manca la seguente annotazione, non è possibile eseguire l'upgrade alla versione 1.13:

baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

Se questo problema riguarda questo problema, bmctl scrive il seguente errore nel file upgrade-cluster.log all'interno della cartella bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.

È molto probabile che questo problema si verifichi con i cluster Docker della versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11, in quanto questo upgrade non richiede l'annotazione per mantenere il runtime del container Docker. In questo caso, i cluster non hanno l'annotazione quando esegui l'upgrade alla versione 1.13. Tieni presente che a partire dalla versione 1.13, containerd è l'unico runtime dei container consentito.

Soluzione alternativa:

Se riscontri questo problema, aggiorna la risorsa cluster con l'annotazione mancante. Puoi aggiungere l'annotazione mentre l'upgrade è in esecuzione o dopo l'annullamento e prima di riprovare.

Installazione 1,11

bmctl si chiude prima del completamento della creazione del cluster

La creazione del cluster potrebbe non riuscire per GDCV per Bare Metal versione 1.11.0 (questo problema è stato risolto in GDCV per la release Bare Metal 1.11.1). In alcuni casi, il comando bmctl create cluster esce in anticipo e scrive errori come quelli indicati di seguito nei log:

Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

Soluzione

L'operazione non riuscita produce artefatti, ma il cluster non è operativo. Se questo problema ti riguarda, segui questi passaggi per eseguire la pulizia degli artefatti e creare un cluster:

Installazione, runtime VM su GDC 1,11, 1,12

Report sull'installazione Errore di riconciliazione del runtime VM

L'operazione di creazione del cluster potrebbe segnalare un errore simile al seguente:

I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

Soluzione

Questo errore non è valido e puoi tranquillamente ignorarlo.

Installazione 1,10, 1,11, 1,12

La creazione del cluster non riesce quando si utilizzano più NIC, containerd e proxy HTTPS

La creazione del cluster non riesce quando hai la seguente combinazione di condizioni:

  • Il cluster è configurato per utilizzare containerd come runtime del container (nodeConfig.containerRuntime impostato su containerd nel file di configurazione del cluster, predefinito per GDCV per Bare Metal versione 1.13 e successive).
  • Il cluster è configurato per fornire più interfacce di rete, multi-NIC, per i pod (clusterNetwork.multipleNetworkInterfaces impostato su true nel file di configurazione del cluster).
  • Il cluster è configurato per utilizzare un proxy (spec.proxy.url è specificato nel file di configurazione del cluster). Anche se la creazione del cluster non riesce, questa impostazione viene propagata quando tenti di creare un cluster. Potresti visualizzare questa impostazione proxy come variabile di ambiente HTTPS_PROXY o nella configurazione di containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Soluzione

Aggiungi i CIDR del servizio (clusterNetwork.services.cidrBlocks) alla variabile di ambiente NO_PROXY su tutte le macchine nodo.

Installazione 1,10, 1,11, 1,12

Errore su sistemi con impostazioni umask restrittive

La release 1.10.0 di GDCV per Bare Metal ha introdotto una funzionalità del piano di controllo senza root che esegue tutti i componenti del piano di controllo come utente non root. L'esecuzione di tutti i componenti come utente non root può causare errori di installazione o upgrade sui sistemi con un'impostazione umask più restrittiva pari a 0077.


Soluzione

Reimposta i nodi del piano di controllo e modifica l'impostazione umask in 0022 su tutte le macchine del piano di controllo. Dopo aver aggiornato le macchine, riprova a eseguire l'installazione.

In alternativa, puoi modificare le autorizzazioni di directory e file di /etc/kubernetes sulle macchine del piano di controllo per procedere con l'installazione o l'upgrade.

  • Rendi leggibili pubblicamente /etc/kubernetes e tutte le relative sottodirectory: chmod o+rx.
  • Rendi tutti i file di proprietà dell'utente root sotto la directory (in modo ricorsivo) /etc/kubernetes leggibili pubblicamente (chmod o+r). Escludi i file di chiavi private (.key) da queste modifiche poiché vengono già creati con proprietà e autorizzazioni corrette.
  • Rendi /usr/local/etc/haproxy/haproxy.cfg leggibile dal mondo.
  • Rendi /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml leggibile dal mondo.
Installazione 1,10; 1,11; 1,12; 1,13

Incompatibilità del gruppo di controllo v2

Il gruppo di controllo v2 (cgroup v2) non è supportato in GKE sui cluster Bare Metal versione 1.13 e precedenti di GDCV per Bare Metal. Tuttavia, la versione 1.14 supporta cgroup v2 come funzionalità di anteprima . La presenza di /sys/fs/cgroup/cgroup.controllers indica che il sistema utilizza cgroup v2.


Soluzione

Se il sistema utilizza cgroup v2, esegui l'upgrade del cluster alla versione 1.14.

Installazione 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28; 1,29

Controlli preflight e credenziali dell'account di servizio

Per le installazioni attivate da cluster di amministrazione o ibridi (ovvero, cluster non creati con bmctl, ad esempio cluster utente), il controllo preflight non verifica le credenziali dell'account di servizio Google Cloud o le autorizzazioni associate.

Installazione 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28; 1,29

Installazione su vSphere

Quando installi GKE su cluster Bare Metal su VM vSphere, devi impostare i flag tx-udp_tnl-segmentation e tx-udp_tnl-csum-segmentation su Off. Questi flag sono relativi all'offload della segmentazione hardware effettuato dal driver vSphere VMXNET3 e non funzionano con il tunnel GENEVE dei cluster GKE su Bare Metal.


Soluzione

Esegui questo comando su ciascun nodo per verificare i valori attuali di questi flag:

ethtool -k NET_INTFC | grep segm

Sostituisci NET_INTFC con l'interfaccia di rete associata all'indirizzo IP del nodo.

La risposta deve contenere voci simili alle seguenti:

...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
A volte in RHEL 8.4, ethtool mostra che questi flag sono disattivati, mentre non lo sono. Per disattivare esplicitamente questi flag, attiva e disattiva i flag utilizzando i seguenti comandi:
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation off

Questa modifica del flag non viene mantenuta tra i riavvii. Configura gli script di avvio per impostare in modo esplicito questi flag all'avvio del sistema.

Upgrade e aggiornamenti 1,1

bmctl non può creare, aggiornare o reimpostare i cluster utente di versioni precedenti

L'interfaccia a riga di comando bmctl non può creare, aggiornare o reimpostare un cluster utente con una versione secondaria inferiore, indipendentemente dalla versione del cluster di amministrazione. Ad esempio, non puoi utilizzare bmctl con una versione di 1.N.X per reimpostare un cluster utente di versione 1.N-1.Y, anche se anche il cluster di amministrazione è alla versione 1.N.X.

Se questo problema ti riguarda, dovresti vedere log simili al seguente quando usi bmctl:

[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:

*   cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported

Soluzione alternativa:

Utilizza kubectl per creare, modificare o eliminare la risorsa personalizzata del cluster utente all'interno del cluster di amministrazione.

La possibilità di eseguire l'upgrade dei cluster utente non è interessata.

Upgrade e aggiornamenti 1,12

Gli upgrade del cluster alla versione 1.12.1 potrebbero bloccarsi

L'upgrade dei cluster alla versione 1.12.1 a volte si blocca perché il server API non è più disponibile. Questo problema riguarda tutti i tipi di cluster e tutti i sistemi operativi supportati. Quando si verifica questo problema, il comando bmctl upgrade cluster potrebbe non funzionare in più punti, anche durante la seconda fase dei controlli preflight.


Soluzione

Puoi controllare i log dell'upgrade per determinare se questo problema ti riguarda. I log di upgrade si trovano in /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP per impostazione predefinita.

Il upgrade-cluster.log potrebbe contenere errori come il seguente:

Failed to upgrade cluster: preflight checks failed: preflight check failed
Il log della macchina potrebbe contenere errori come i seguenti (errori ripetuti indicano che questo problema ti riguarda:
FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left). ...

HAProxy e Keepaworthy devono essere in esecuzione su ciascun nodo del piano di controllo prima di tentare nuovamente di eseguire l'upgrade del cluster alla versione 1.12.1. Utilizza l' interfaccia a riga di comando crictl su ciascun nodo per verificare se i container haproxy e keepalived sono in esecuzione:

docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived

Se HAProxy o KeepaDuration non è in esecuzione su un nodo, riavvia kubelet sul nodo:

systemctl restart kubelet
Upgrade e aggiornamenti, runtime VM su GDC 1,11, 1,12

L'upgrade dei cluster alla versione 1.12.0 o successive non riesce se è abilitato il runtime VM su GDC

Nella versione 1.12.0 GKE su cluster Bare Metal viene eseguita la migrazione di tutte le risorse relative al runtime delle VM su GDC nello spazio dei nomi vm-system per supportare meglio la release GA del runtime VM su GDC. Se hai abilitato il runtime VM su GDC in un cluster della versione 1.11.x o precedente, l'upgrade alla versione 1.12.0 o successive non va a buon fine, a meno che non disabiliti prima il runtime VM su GDC. Se questo problema ti riguarda, l'operazione di upgrade segnala il seguente errore:

Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version

Soluzione

Per disabilitare il runtime VM su GDC:

  1. Modifica la risorsa personalizzata VMRuntime:
    kubectl edit vmruntime
    
  2. Imposta enabled su false nella specifica:
    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      enabled: false
      ...
    
  3. Salva la risorsa personalizzata nell'editor.
  4. Una volta completato l'upgrade del cluster, riabilita il runtime VM su GDC.

Per maggiori informazioni, consulta Utilizzo di carichi di lavoro basati su VM.

Upgrade e aggiornamenti 1,10, 1,11, 1,12

Upgrade bloccato a error during manifests operations

In alcune situazioni, gli upgrade del cluster non vengono completati e l'interfaccia a riga di comando bmctl non risponde. Questo problema può essere causato da una risorsa aggiornata in modo errato. Per determinare se questo problema ti riguarda e per risolverlo, controlla i log anthos-cluster-operator e cerca errori simili alle seguenti voci:

controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

Queste voci sono un sintomo di una risorsa aggiornata in modo errato, dove {RESOURCE_NAME} è il nome della risorsa problematica.


Soluzione

Se riscontri questi errori nei log, procedi nel seguente modo:

  1. Utilizza kubectl edit per rimuovere l'annotazione kubectl.kubernetes.io/last-applied-configuration dalla risorsa contenuta nel messaggio di log.
  2. Salva e applica le modifiche alla risorsa.
  3. Riprova a eseguire l'upgrade del cluster.
Upgrade e aggiornamenti 1,10, 1,11, 1,12

Gli upgrade sono bloccati per i cluster con funzionalità che utilizzano il gateway di rete per GDC

Gli upgrade dei cluster da 1.10.x a 1.11.x non riescono per i cluster che utilizzano il gateway NAT in uscita o il bilanciamento del carico in bundle con BGP. Entrambi queste funzionalità utilizzano il gateway di rete per GDC. Gli upgrade del cluster si bloccano al messaggio della riga di comando Waiting for upgrade to complete... e agli errori dei log anthos-cluster-operator come il seguente:

apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...

Soluzione

Per sbloccare l'upgrade, esegui questi comandi sul cluster di cui stai eseguendo l'upgrade:

kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler
kubectl -n kube-system delete deployment \
    ang-controller-manager
kubectl -n kube-system delete ds ang-node
Upgrade e aggiornamenti 1,10; 1,11; 1,12; 1,13; 1,14; 1,15

bmctl update non rimuove i blocchi di manutenzione

Il comando bmctl update non può rimuovere o modificare la sezione maintenanceBlocks dalla configurazione delle risorse cluster.


Soluzione

Per maggiori informazioni, incluse le istruzioni per rimuovere i nodi dalla modalità di manutenzione, consulta Attivare la modalità di manutenzione sui nodi.

Operazione 1,10, 1,11, 1,12

Nodi non contrassegnati se non utilizzi la procedura della modalità di manutenzione

Se esegui cluster della versione 1.12.0 (anthosBareMetalVersion: 1.12.0) o precedente e utilizzi manualmente kubectl cordon su un nodo, GKE su Bare Metal potrebbe annullare l'impostazione del nodo prima che tu sia pronto, nel tentativo di riconciliare lo stato previsto.


Soluzione

Per la versione 1.12.0 e i cluster precedenti, utilizza la modalità di manutenzione per contrassegnare e svuotare i nodi in modo sicuro.

Nella versione 1.12.1 (anthosBareMetalVersion: 1.12.1) o successiva, GKE su Bare Metal non contrassegna i nodi in modo imprevisto quando utilizzi kubectl cordon.

Operazione 1,11

I cluster di amministrazione della versione 11 che utilizzano un mirroring del registro non possono gestire i cluster della versione 1.10

Se il cluster di amministrazione è alla versione 1.11 e utilizza un mirroring del registro, non può gestire i cluster utente in una versione secondaria inferiore. Questo problema riguarda le operazioni di reimpostazione, aggiornamento ed upgrade sul cluster utente.

Per determinare se questo problema ti riguarda, controlla i log per le operazioni del cluster, come creazione, upgrade o reimpostazione. Questi log si trovano nella cartella bmctl-workspace/CLUSTER_NAME/ per impostazione predefinita. Se si verifica il problema, i log contengono il seguente messaggio di errore:

flag provided but not defined: -registry-mirror-host-to-endpoints
Operazione 1,10, 1,11

Il secret kubeconfig viene sovrascritto

Quando viene eseguito sui cluster utente, il comando bmctl check cluster sovrascrive il secret di kubeconfig del cluster utente con kubeconfig del cluster di amministrazione. Se sovrascrivi il file, le operazioni standard del cluster, come l'aggiornamento e l'upgrade, non riescono per i cluster utente interessati. Questo problema si applica ai cluster GKE su Bare Metal versione 1.11.1 e precedenti.

Per determinare se questo problema interessa un cluster utente, esegui questo comando:

kubectl --kubeconfig ADMIN_KUBECONFIG \
    get secret -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME -kubeconfig \
    -o json  | jq -r '.data.value'  | base64 -d

Sostituisci quanto segue:

  • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
  • USER_CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi per i cluster GKE su Bare Metal sono il nome del cluster preceduto da cluster-. Ad esempio, se assegni al cluster il nome test, lo spazio dei nomi predefinito è cluster-test.
  • USER_CLUSTER_NAME: il nome del cluster utente da controllare.

Se il nome del cluster nell'output (vedi contexts.context.cluster nel seguente output di esempio) è il nome del cluster di amministrazione, il cluster utente specificato è interessato.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Soluzione

I seguenti passaggi ripristinano la funzione in un cluster utente interessato (USER_CLUSTER_NAME):

  1. Individua il file kubeconfig del cluster utente. GKE su Bare Metal genera il file kubeconfig sulla workstation di amministrazione quando crei un cluster. Per impostazione predefinita, il file si trova nella directory bmctl-workspace/USER_CLUSTER_NAME.
  2. Verifica che kubeconfig sia corretto nel cluster utente kubeconfig:
    kubectl get nodes \
        --kubeconfig PATH_TO_GENERATED_FILE
    
    Sostituisci PATH_TO_GENERATED_FILE con il percorso del file kubeconfig del cluster utente. La risposta restituisce dettagli sui nodi per il cluster utente. Verifica che i nomi delle macchine siano corretti per il cluster.
  3. Esegui questo comando per eliminare il file kubeconfig danneggiato nel cluster di amministrazione:
    kubectl delete secret \
        -n USER_CLUSTER_NAMESPACE \
        USER_CLUSTER_NAME-kubeconfig
    
  4. Esegui questo comando per salvare di nuovo il secret kubeconfig corretto nel cluster di amministrazione:
    kubectl create secret generic \
        -n USER_CLUSTER_NAMESPACE \
        USER_CLUSTER_NAME-kubeconfig \
        --from-file=value=PATH_TO_GENERATED_FILE
    
Operazione 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28; 1,29

Creazione di uno snapshot come utente con accesso non root

Se utilizzi containerd come runtime del container, l'esecuzione dello snapshot come utente non root richiede che /usr/local/bin si trovi nel PERCORSO dell'utente. In caso contrario, l'operazione non andrà a buon fine e verrà visualizzato un errore crictl: command not found.

Se non hai eseguito l'accesso come utente root, viene utilizzato sudo per eseguire i comandi dello snapshot. Il PERCORSO sudo può essere diverso dal profilo principale e non può contenere /usr/local/bin.


Soluzione

Aggiorna secure_path in /etc/sudoers per includere /usr/local/bin. In alternativa, crea un link simbolico per crictl in un'altra directory /bin.

Logging e monitoraggio 1,1

stackdriver-log-forwarder ha [parser:cri] invalid time format log degli avvisi

Se l'analizzatore sintattico dell'interfaccia di runtime del container (CRI) utilizza un'espressione regolare errata per il tempo di analisi, i log del pod stackdriver-log-forwarder contengono errori e avvisi come il seguente:

[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

Soluzione alternativa:

Logging e monitoraggio 1,10; 1,11; 1,12; 1,13; 1,14; 1,15

Fatturazione del monitoraggio imprevista

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

  • Il monitoraggio delle applicazioni è abilitato (enableStackdriverForApplications=true)
  • Managed Service per Prometheus non è abilitato (enableGMPForApplications)
  • I pod di applicazione hanno l'annotazione prometheus.io/scrap=true

Per verificare se questo problema ti riguarda, elenca le metriche definite dall'utente. Se visualizzi la fatturazione per metriche indesiderate, questo problema si applica al tuo caso.


Soluzione

Se ti interessa questo problema, ti consigliamo di eseguire l'upgrade dei cluster alla versione 1.12 e di passare alla nuova soluzione di monitoraggio delle applicazioni managed-service-for-prometheus che risolvano questo problema:

  • Flag separati per controllare la raccolta dei log delle applicazioni rispetto alle metriche dell'applicazione
  • Google Cloud Managed Service in bundle per Prometheus
  • Se non riesci a eseguire l'upgrade alla versione 1.12, segui questi passaggi:

    1. Trova i pod e i servizi di origine con fatturazione indesiderata:
      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.
    Logging e monitoraggio 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28

    Le modifiche apportate a metrics-server-config non sono rese persistenti

    Un'elevata densità di pod può, in casi estremi, generare un overhead di logging e monitoraggio eccessivo, che può causare l'arresto e il riavvio di Metrics Server. Puoi modificare il ConfigMap metrics-server-config per allocare più risorse e mantenere in esecuzione il server delle metriche. Tuttavia, a causa della riconciliazione, le modifiche apportate a metrics-server-config possono essere ripristinate al valore predefinito durante un'operazione di aggiornamento o upgrade del cluster. Metrics Server non viene interessato immediatamente, ma al successivo riavvio riprende il ConfigMap ripristinato ed è vulnerabile a un sovraccarico eccessivo.


    Soluzione

    Per 1.11.x, puoi creare uno script della modifica di ConfigMap ed eseguirla insieme agli aggiornamenti o agli upgrade al cluster. A partire dalla versione 1.12 e successive, contatta l'assistenza.

    Logging e monitoraggio 1,11, 1,12

    Le metriche deprecate influiscono sulla dashboard di Cloud Monitoring

    Diverse metriche di GKE su Bare Metal sono state deprecate e, a partire da GDCV per Bare Metal release 1.11, i dati per queste metriche deprecate non vengono più raccolti. Se utilizzi queste metriche in uno qualsiasi dei tuoi criteri di avviso, non ci saranno dati per attivare la condizione di avviso.

    La seguente tabella elenca le singole metriche deprecate e la metrica che le sostituisce.

    Metriche deprecate Metrica di sostituzione
    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

    Nelle versioni dei cluster GKE su Bare Metal precedenti alla 1.11, il file di definizione dei criteri per l'avviso Anthos on baremetal node cpu usage exceeds 80 percent (critical) consigliato utilizza le metriche deprecate. Il file di definizione JSON node-cpu-usage-high.json viene aggiornato per le release 1.11.0 e successive.


    Soluzione

    Per eseguire la migrazione alle metriche di sostituzione:

    1. Nella console Google Cloud, seleziona Monitoring o fai clic sul pulsante seguente:
      Vai a Monitoring
    2. Nel riquadro di navigazione, seleziona Dashboard ed elimina la dashboard dello stato del nodo del cluster Anthos.
    3. Fai clic sulla scheda Libreria di esempio e reinstalla la dashboard Stato del nodo del cluster Anthos.
    4. Segui le istruzioni in Creazione dei criteri di avviso per creare un criterio utilizzando il file di definizione dei criteri aggiornato node-cpu-usage-high.json.
    Logging e monitoraggio 1,10, 1,11

    stackdriver-log-forwarder ha CrashloopBackOff errori

    In alcune situazioni, l'agente di logging fluent-bit può bloccarsi durante l'elaborazione di blocchi danneggiati. Quando l'agente Logging non è in grado di bypassare i blocchi danneggiati, potresti osservare che stackdriver-log-forwarder continua ad arrestarsi in modo anomalo con un errore CrashloopBackOff. Se si verifica questo problema, i log contengono voci simili alla seguente

    [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0  0x5590aa24bdd5
    in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
    #1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
    #2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
    #3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
    #4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5  0xffffffffffffffff  in  ???() at ???:0
    

    Soluzione alternativa:

    Esegui la pulizia dei blocchi del buffer per il forwarding dei log di Stackdriver.

    Nota: nei comandi seguenti, sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

    1. Termina tutti i pod stackdriver-log-forwarder:
      kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \
          stackdriver-log-forwarder -p \
          '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      
      Verifica che i pod stackdriver-log-forwarder siano stati eliminati prima di andare al passaggio successivo.
    2. Esegui il deployment del seguente DaemonSet per eliminare i dati danneggiati nei buffer fluent-bit:
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -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. Utilizza i comandi seguenti per verificare che il DaemonSet abbia pulito tutti i nodi:
      kubectl --kubeconfig KUBECONFIG logs \
          -n kube-system -l \
          app=fluent-bit-cleanup | grep "cleaned up" | wc -l
      kubectl --kubeconfig KUBECONFIG -n \
          kube-system get pods -l \
          app=fluent-bit-cleanup --no-headers | wc -l
      
      L'output dei due comandi dovrebbe essere uguale al numero di nodi nel cluster.
    4. Elimina il DaemonSet di pulizia:
      kubectl --kubeconfig KUBECONFIG -n \
          kube-system delete ds fluent-bit-cleanup
      
    5. Riavvia i pod del forwarding dei log:
      kubectl --kubeconfig 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; 1,28

    Errore delle metriche sconosciuto nel log gke-metrics-agent

    gke-metrics-agent è un daemonset che raccoglie metriche su ciascun nodo e le inoltra a Cloud Monitoring. Potrebbe generare log come seguenti:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
    

    Errori simili possono verificarsi con altri tipi di metriche, tra cui, a titolo esemplificativo:

    • 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

    Questi log degli errori possono essere tranquillamente ignorati poiché le metriche a cui fanno riferimento non sono supportate e non sono critiche per scopi di monitoraggio.

    Logging e monitoraggio 1,10, 1,11

    Interruzioni dell'esportazione delle metriche a intermittenza

    I cluster GKE su Bare Metal potrebbero riscontrare interruzioni nell'esportazione normale e continua delle metriche o metriche mancanti su alcuni nodi. Se questo problema interessa i tuoi cluster, potresti notare (almeno) lacune nei dati per le seguenti metriche:

    • 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

    Esegui l'upgrade dei cluster alla versione 1.11.1 o successive.

    Se non riesci a eseguire l'upgrade, per risolvere il problema procedi nel seguente modo:

    1. Apri la risorsa stackdriver per la modifica:
      kubectl -n kube-system edit stackdriver stackdriver
      
    2. Per aumentare la richiesta di CPU per gke-metrics-agent da 10m a 50m, aggiungi la seguente sezione resourceAttrOverride al manifest stackdriver:
      spec:
        resourceAttrOverride:
          gke-metrics-agent/gke-metrics-agent:
            limits:
              cpu: 100m
              memory: 4608Mi
            requests:
              cpu: 50m
              memory: 200Mi
      
      La risorsa modificata dovrebbe essere simile alla seguente:
      spec:
        anthosDistribution: baremetal
        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: 100m
              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 -n kube-system get daemonset \
          gke-metrics-agent -o yaml | grep "cpu: 50m"
      
      Il comando trova cpu: 50m se le modifiche sono state applicate.
    Networking 1,1

    Più gateway predefiniti interrompono la connettività agli endpoint esterni

    La presenza di più gateway predefiniti in un nodo può causare interruzioni della connettività dall'interno di un pod a endpoint esterni, ad esempio google.com.

    Per determinare se questo problema ti riguarda, esegui questo comando sul nodo:

    ip route show
    

    Più istanze di default nella risposta indicano che il problema ti riguarda.

    Networking 1,12

    Le modifiche alle risorse personalizzate di networking dei cluster utente vengono sovrascritte

    I cluster GKE su Bare Metal versione 1.12.x non ti impediscono di modificare manualmente le risorse personalizzate di networking nel tuo cluster utente. GKE su Bare Metal riconcilia le risorse personalizzate nei cluster utente con le risorse personalizzate nel cluster di amministrazione durante gli upgrade del cluster. Questa riconciliazione sovrascrive qualsiasi modifica apportata direttamente alle risorse personalizzate di networking nel cluster utente. Le risorse personalizzate di networking devono essere modificate solo nel cluster di amministrazione, ma i cluster della versione 1.12.x non applicano questo requisito.

    Le funzionalità di networking avanzate, come il bilanciamento del carico in bundle con BGP, il gateway NAT in uscita, le rete di networking SR-IOV, la modalità flat con BGP e multi-NIC per i pod utilizzano le seguenti risorse personalizzate:

    • BGPLoadBalancer
    • BGPPeer
    • NetworkGatewayGroup
    • NetworkAttachmentDefinition
    • ClusterCIDRConfig
    • FlatIPMode

    Modifica queste risorse personalizzate nel cluster di amministrazione e il passaggio di riconciliazione applica le modifiche ai cluster utente.


    Soluzione

    Se hai modificato una delle risorse personalizzate menzionate in precedenza su un cluster utente, modifica le risorse personalizzate corrispondenti nel cluster di amministrazione in modo che corrispondano prima dell'upgrade. Questo passaggio garantisce che le modifiche alla configurazione vengano conservate. La versione 1.13.0 e successive del cluster GKE su Bare Metal ti impedisce di modificare le risorse personalizzate di networking direttamente sui tuoi cluster utente.

    Networking 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28

    Errori di connettività dei pod e filtraggio del percorso inverso

    GKE su Bare Metal configura il filtro del percorso inverso sui nodi per disabilitare la convalida dell'origine (net.ipv4.conf.all.rp_filter=0). Se l'impostazione rp_filter viene modificata in 1 o 2, i pod avranno esito negativo a causa di timeout della comunicazione fuori nodo.

    Il filtro del percorso inverso è impostato su rp_filter file nella cartella di configurazione IPv4 (net/ipv4/conf/all). Questo valore può anche essere sostituito da sysctl, che archivia le impostazioni di filtro del percorso inverso in un file di configurazione della sicurezza di rete, come /etc/sysctl.d/60-gce-network-security.conf.


    Soluzione

    La connettività dei pod può essere ripristinata eseguendo una delle seguenti soluzioni alternative:

    Imposta di nuovo il valore di net.ipv4.conf.all.rp_filter su 0 manualmente, quindi esegui sudo sysctl -p per applicare la modifica.

    Oppure

    Riavvia il pod anetd per impostare net.ipv4.conf.all.rp_filter di nuovo su 0. Per riavviare il pod anetd, utilizza i comandi seguenti per individuare ed eliminare il pod anetd; al suo posto verrà avviato un nuovo pod anetd:

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    Sostituisci ANETD_XYZ con il nome del pod anetd.

    Dopo aver eseguito una delle soluzioni alternative, verifica che il valore net.ipv4.conf.all.rp_filter sia impostato su 0 eseguendo sysctl net.ipv4.conf.all.rp_filter su ciascun nodo.

    Networking 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28; 1,29

    Gli indirizzi IP del cluster di bootstrap (tipo) e gli indirizzi IP dei nodi cluster si sovrappongono

    192.168.122.0/24 e 10.96.0.0/27 sono i CIDR predefiniti di pod e servizi utilizzati dal cluster di bootstrap (tipo). I controlli preflight non andranno a buon fine se si sovrappongono agli indirizzi IP delle macchine dei nodi cluster.


    Soluzione

    Per evitare il conflitto, puoi passare i flag --bootstrap-cluster-pod-cidr e --bootstrap-cluster-service-cidr a bmctl per specificare valori diversi.

    Sistema operativo 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28

    Creazione o upgrade del cluster non riusciti su CentOS

    Nel dicembre 2020, la community di CentOS e Red Hat hanno annunciato il ritiro di CentOS. Il 31 gennaio 2022 CentOS 8 ha raggiunto la fine del ciclo di vita (EOL). A causa della fine del ciclo di vita, i repository yum hanno smesso di funzionare per CentOS, causando un errore delle operazioni di creazione e upgrade del cluster. Questo si applica a tutte le versioni supportate di CentOS e influisce su tutte le versioni di GKE su cluster Bare Metal.


    Soluzione

    Sicurezza 1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28

    Il container non può scrivere in VOLUME definito in Dockerfile con containerd e SELinux

    Se utilizzi containerd come runtime del container e il tuo sistema operativo ha SELinux abilitato, VOLUME definito nel Dockerfile dell'applicazione potrebbe non essere accessibile in scrittura. Ad esempio, i container creati con il seguente Dockerfile non sono in grado di scrivere nella cartella /tmp.

    FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp
    

    Per verificare se questo problema ti riguarda, esegui questo comando sul nodo che ospita il container problematico:

    ausearch -m avc
    

    Se questo problema ti riguarda, viene visualizzato un errore denied come il seguente:

    time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc:  denied { write } for  pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0
    

    Soluzione

    Per risolvere il problema, apporta una delle seguenti modifiche:

    • Disattiva SELinux.
    • Non utilizzare la funzionalità VOLUME all'interno di Dockerfile.
    Upgrade e aggiornamenti 1,10, 1,11, 1,12

    Il rilevatore dei problemi dei nodi non è abilitato per impostazione predefinita dopo gli upgrade del cluster

    Quando esegui l'upgrade di GKE su cluster Bare Metal, il rilevatore di problemi dei nodi non è abilitato per impostazione predefinita. Questo problema si applica agli upgrade dalle release 1.10 alla 1.12.1 ed è stato risolto nella release 1.12.2.


    Soluzione alternativa:

    Per abilitare il rilevatore dei problemi dei nodi:

    1. Verifica se il servizio node-problem-detector systemd è in esecuzione sul nodo.
      1. Utilizza il comando SSH e connettiti al nodo.
      2. Controlla se il servizio node-problem-detector systemd è in esecuzione sul nodo:
        systemctl is-active node-problem-detector
        
        Se il risultato del comando mostra inactive, significa che node-problem-detector non è in esecuzione sul nodo.
    2. Per abilitare il rilevatore dei problemi dei nodi, utilizza il comando kubectl edit e modifica il ConfigMap di node-problem-detector-config. Per ulteriori informazioni, consulta la sezione Rilevatore problemi dei nodi.
    Operazione 1,9, 1,10

    Il backup del cluster non va a buon fine quando si utilizza un accesso non root

    Il comando bmctl backup cluster non riesce se nodeAccess.loginUser è impostato su un nome utente non root.]


    Soluzione alternativa:

    Questo problema si applica alle versioni 1.9.x, 1.10.0 e 1.10.1 ed è stato risolto nella versione 1.10.2 e successive.

    Networking 1,10, 1,11, 1,12

    I servizi di bilanciamento del carico non funzionano con i container sulla rete host del piano di controllo

    Esiste un bug in anetd per cui i pacchetti vengono ignorati per i servizi LoadBalancer se i pod di backend sono entrambi in esecuzione sul nodo del piano di controllo e utilizzano il campo hostNetwork: true nelle specifiche del container.

    Il bug non è presente nella versione 1.13 o successive.


    Soluzione alternativa:

    Le seguenti soluzioni alternative possono aiutarti se utilizzi un servizio LoadBalancer supportato dai pod hostNetwork:

    1. Eseguili sui nodi worker (non sui nodi del piano di controllo).
    2. Utilizza externalTrafficPolicy: local nella specifica del servizio e assicurati che i carichi di lavoro vengano eseguiti sui nodi del bilanciatore del carico.
    Upgrade e aggiornamenti 1,12, 1,13

    Errore durante il pull dell'immagine per il pod anthos-version-$version$ orfano

    L'upgrade dei cluster da 1.12.x a 1.13.x potrebbe osservare un errore nel pod anthos-version-$version$ con errore ImagePullBackOff. Ciò si verifica a causa della race condition di anthos-cluster-operator in fase di upgrade e non dovrebbe influire sulle normali funzionalità dei cluster.

    Il bug non è presente dopo la versione 1.13 o successive.


    Soluzione alternativa:

    Elimina il job del programma di installazione della versione dinamica entro il giorno kubectl delete job anthos-version-$version$ -n kube-system

    Upgrade e aggiornamenti 1,13

    Non è possibile eseguire l'upgrade a 1.13.0 dei cluster di 1.12 con upgrade dalla versione 1.11

    Non è possibile eseguire l'upgrade alla versione 1.13.0 dei cluster della versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11. Questo problema di upgrade non si applica ai cluster creati nella versione 1.12.

    Per determinare se il problema ti riguarda, controlla i log del job di upgrade che contiene la stringa upgrade-first-no* nel cluster di amministrazione. Se visualizzi il seguente messaggio di errore, il problema ti riguarda.

    TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
    ...
    [upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name.
    ...
    

    Soluzione alternativa:

    Per risolvere questo problema:

    1. Esegui i comandi seguenti sulla workstation di amministrazione:
      echo '[{ "op": "remove", "path": \
          "/spec/clusterConfiguration/featureGates" }]' \
          > remove-feature-gates.patch
      export KUBECONFIG=$ADMIN_KUBECONFIG
      kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
          'kubectl patch kubeadmconfig $1 -n $0 --type json \
          --patch-file remove-feature-gates.patch'
      
    2. Riprova a eseguire l'upgrade del cluster.
    Logging e Monitoring 1.16.2, 1.16.3

    Utilizzo elevato della CPU per stackdriver-operator

    Si è verificato un problema in stackdriver-operator che riduce il consumo di tempo di CPU più elevato del normale. L'utilizzo normale della CPU è inferiore a 50 milliCPU (50m) per stackdriver-operator in stato inattivo. La causa è una mancata corrispondenza delle risorse dei certificati che stackdriver-operator si applica con le aspettative di cert-manager. Questa mancata corrispondenza causa una race condition tra cert-manager e stackdriver-operator nell'aggiornamento di queste risorse.

    Questo problema potrebbe comportare una riduzione delle prestazioni sui cluster con disponibilità di CPU limitata.


    Soluzione alternativa:

    Fino a quando non potrai eseguire l'upgrade a una versione che ha risolto questo bug, usa la seguente soluzione alternativa:

    1. Per fare lo scale down temporaneo di stackdriver-operator a 0 repliche, applica una risorsa personalizzata AddonConfiguration:
      kubectl scale deploy stackdriver-operator --replicas=0
      
    2. Dopo aver eseguito l'upgrade a una versione che corregge il problema, esegui nuovamente lo scale up di stackdriver-operator:
      kubectl scale deploy stackdriver-operator --replicas=1
      
    Logging e Monitoring 1.16.0, 1.16.1

    Lo scraping di metriche basate sulle annotazioni non funziona

    Nella release secondaria GDCV per Bare Metal 1.16, il campo enableStackdriverForApplications nella specifica delle risorse personalizzate stackdriver è deprecato. Questo campo è sostituito da due campi, enableCloudLoggingForApplications e enableGMPForApplications, nella risorsa personalizzata Stackdriver.

    Ti consigliamo di utilizzare Google Cloud Managed Service per Prometheus per monitorare i carichi di lavoro. Utilizza il campo enableGMPForApplications per abilitare questa funzionalità.

    Se fai affidamento sulla raccolta di metriche attivata dalle annotazioni prometheus.io/scrape sui tuoi carichi di lavoro, puoi utilizzare il flag della porta delle funzionalità annotationBasedApplicationMetrics per mantenere il comportamento precedente. Tuttavia, esiste un problema che impedisce a annotationBasedApplicationMetrics di funzionare correttamente, impedendo la raccolta delle metriche dalle applicazioni in Cloud Monitoring.


    Soluzione alternativa:

    Per risolvere questo problema, esegui l'upgrade del cluster alla versione 1.16.2 o successive.

    La raccolta di metriche dei carichi di lavoro basata su annotazioni abilitata dalla porta di funzionalità annotationBasedApplicationMetrics raccoglie metriche per gli oggetti che hanno l'annotazione prometheus.io/scrape. Molti sistemi software con origine open source possono utilizzare questa annotazione. Se continui a utilizzare questo metodo di raccolta delle metriche, tieni presente questa dipendenza per evitare di sorprenderti dagli addebiti relativi alle metriche in Cloud Monitoring.

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