s <0x0

Questa pagina elenca tutti i problemi noti di Google Distributed Cloud (solo software) per bare metal (precedentemente noto come Google Distributed Cloud Virtual, a sua volta noto come Anthos clusters on bare metal).

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

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

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

Seleziona la tua versione di Google Distributed Cloud:

1,34 1,33 1.32 1,31 1,30 1,29 1,28 1,16 1,15 1,14 1,13 1,12 1,11 1,10

Seleziona la categoria del problema:

Configurazione Installazione Upgrade e aggiornamenti Operazione Logging e monitoraggio Networking Sicurezza Reimpostazione/eliminazione VM Runtime su GDC

In alternativa, cerca il tuo problema:

Categoria	Versioni identificate	Problema e soluzione alternativa
Networking, upgrade e aggiornamenti	1.30 e versioni successive	Il pod Istiod non raggiunge lo stato di pronto durante gli upgrade La funzionalità Ingress inclusa in Google Distributed Cloud utilizza istiod. Questa funzionalità non utilizza definizioni di risorse personalizzate definite da Istio. Tuttavia, poiché il codice utilizzato è open source, i pod sono sensibili alle installazioni di Istio che potresti avere per i tuoi casi d'uso. Se nei cluster non sono presenti definizioni di risorse personalizzate Istio, Istiod si dichiara pronto senza attendere le definizioni di risorse personalizzate. Tuttavia, se nel cluster sono presenti definizioni di risorse personalizzate v1beta, Istiod attende le definizioni di risorse personalizzate v1 prima di dichiarare la disponibilità. Di conseguenza, il pod Istiod potrebbe non raggiungere lo stato di pronto, causando il mancato upgrade del cluster. Verifica: Per verificare se il tuo cluster è interessato, controlla lo stato del pod Istiod nello spazio dei nomi gke-system: kubectl get pods -n gke-system -l app=istiod Se lo stato del pod è Running, ma il controllo di idoneità non va a buon fine (ad esempio, 0/1 pronto), è probabile che il cluster sia interessato. Soluzione temporanea: Per risolvere il problema, utilizza una delle seguenti soluzioni alternative: Esegui manualmente il deployment delle definizioni di risorse personalizzate v1 di Istio nel tuo cluster. Disattiva la funzionalità di ingresso in bundle se non la utilizzi.
Installazione, upgrade e aggiornamenti	1.30.400 e precedenti	lifecycle-controllers-manager si arresta in modo anomalo durante il controllo delle risorse personalizzate PreflightCheck I cluster con la versione 1.30.400 o precedenti possono subire arresti anomali dei pod lifecycle-controllers-manager durante la convalida delle risorse personalizzate PreflightCheck. Questi arresti anomali bloccano il provisioning e gli upgrade dei cluster. Questo problema si verifica a causa di un dereferenziamento del puntatore nullo durante la convalida delle risorse PreflightCheck. Soluzione temporanea: Per consentire il provisioning o gli upgrade del cluster, ignora i controlli preflight. Imposta il campo bypassPreflightCheck su true nel file di configurazione del cluster: spec: bypassPreflightCheck: true Per ulteriori informazioni, consulta Ignorare i controlli preflight durante l'applicazione delle risorse Kubernetes.
Operazione, reimpostazione/eliminazione	1.33 e versioni precedenti	Node Problem Detector non si avvia dopo il ripristino del cluster Quando ripristini un cluster utilizzando bmctl restore cluster, il servizio systemd Node Problem Detector (NPD) non viene avviato sui nodi al termine dell'operazione di ripristino. Per verificare se il problema ti riguarda, esegui systemctl is-active node-problem-detector sui nodi del cluster dopo un'operazione di ripristino. Se il comando restituisce inactive, il tuo account è interessato da questo problema. Soluzione temporanea: Per ripristinare NPD: Disattiva NPD seguendo la procedura descritta in Come attivare e disattivare Node Problem Detector. Attiva NPD seguendo la procedura descritta in Come attivare e disattivare Node Problem Detector. La disattivazione e l'attivazione di NPD attivano esplicitamente i job di deployment di NPD che installano il servizio NPD su tutti i nodi.
Networking, Operation	1.28 e precedenti, 1.29.0-1.29.700, 1.30.0-1.30.300	I pod del bilanciatore del carico del control plane vengono riavviati ogni 7 giorni Nei cluster che utilizzano il bilanciatore del carico di livello 2 in bundle, potresti notare errori "Connessione rifiutata" o una breve indisponibilità del server API (circa 1 minuto) che si verifica ogni 7 giorni. Questo comportamento si verifica perché i pod haproxy e keepalived sui nodi del control plane vengono riavviati a causa di un'impostazione del tempo di sopravvivenza del job. Questo problema riguarda i cluster nelle versioni da 1.29.0 a 1.29.700, da 1.30.0 a 1.30.300 e 1.28 e precedenti. Verifica: Per verificare che il cluster sia interessato da questo problema specifico, controlla la configurazione del job di aggiornamento del bilanciatore del carico completando i seguenti passaggi: Trova il nome del job di aggiornamento: kubectl get jobs -n kube-system | grep bm-system-cplb-update Controlla l'impostazione della durata (TTL) per il job: kubectl get job JOB_NAME -n kube-system -o jsonpath='{.spec.ttlSecondsAfterFinished}' Sostituisci JOB_NAME con il nome restituito nel passaggio precedente. Se l'output è 604800 (ovvero 7 giorni in secondi), il tuo cluster è interessato da questo problema. Soluzione temporanea: Per evitare i riavvii settimanali, applica manualmente una patch al campo ttlSecondsAfterFinished nei job di aggiornamento del bilanciamento del carico esistenti impostando un valore più grande, completando i seguenti passaggi: Modifica il job di aggiornamento del bilanciatore del carico: kubectl edit job JOB_NAME -n kube-system Nell'editor, trova il campo ttlSecondsAfterFinished e modifica il valore in 7776000 (circa 90 giorni). Salva ed esci dall'editor per applicare le modifiche.
Operazione	1.32.0-1.32.700, 1.33.0-1.33.300, 1.34.0	cluster-operator: arresto anomalo del pod con dereferenziazione del puntatore nullo Il pod cluster-operator potrebbe arrestarsi in modo anomalo o entrare in un ciclo di arresti anomali a causa di un panico: assignment to entry in nil map in un controller. Ciò può accadere quando il controller tenta di aggiornare le annotazioni su una risorsa personalizzata, ad esempio un NodePool, che non ha annotazioni (mappa nulla). Soluzione temporanea: Per evitare il panico, assicurati che la risorsa personalizzata (ad esempio, NodePool) abbia almeno un'annotazione. Puoi aggiungere un'annotazione fittizia utilizzando il seguente comando: kubectl annotate nodepool NODEPOOL_NAME \ -n CLUSTER_NAMESPACE dummy-annotation="added-manually" --overwrite \ --kubeconfig=ADMIN_KUBECONFIG Sostituisci quanto segue: NODEPOOL_NAME: il nome della risorsa personalizzata NodePool. CLUSTER_NAMESPACE: lo spazio dei nomi del cluster. ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
Upgrade e aggiornamenti	1.34.0	L'upgrade del nodo di lavoro non riesce a causa della mancata corrispondenza del nome host Gli upgrade dei nodi di lavoro non riescono a causa di una regressione (kubernetes/kubeadm#3244) in kubeadm. La regressione si verifica quando il nome host Linux non corrisponde al valore dell'etichetta kubernetes.io/hostname sui nodi Kubernetes corrispondenti. Per verificare che il nodo interessato non funzioni, utilizza journalctl simile al seguente: [root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# journalctl -t kubeadm La risposta dovrebbe essere simile al seguente esempio: Dec 09 20:09:50 vm-lb-0--40b1a328a3448f5-112eaaafe1beedad kubeadm[3684235]: error: error execution phase kubelet-config: could not remove the CRI socket annotation from Node "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad": nodes "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad" not found In questo esempio, il nome host Linux riportato nella risposta journalctl non corrisponde all'etichetta kubernetes.io/hostname per il nodo, il che conferma che l'upgrade è interessato da questo problema: kubectl get nodes lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos \ -ojsonpath='{.metadata.labels.kubernetes\.io\/hostname}' La risposta: lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos Soluzione temporanea: Per fare in modo che il nodo interessato completi l'upgrade, prova a modificare temporaneamente il nome host in modo che corrisponda al valore dell'etichetta kubernetes.io/hostname sui nodi Kubernetes corrispondenti, in modo simile al seguente: [root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# hostname lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos
Networking	1.34.0	La migrazione controllata elimina le connessioni esistenti sul nodo cordon Quando abiliti il failover rapido NAT in uscita, l'isolamento di un nodo gateway con kubectl cordon <NODE_NAME> avvia una migrazione controllata che mantiene le connessioni in uscita esistenti. Tuttavia, nella release 1.34.0 solo software di Google Distributed Cloud, la funzionalità di migrazione controllata non funziona come previsto. Se un amministratore isola un nodo gateway di uscita attivo in un cluster versione 1.34.0 che utilizza il failover rapido, l'isolamento si comporta come un errore del nodo non pianificato e termina immediatamente tutte le connessioni stateful esistenti su quel nodo. Soluzione temporanea: Non esiste una soluzione alternativa per questo problema.
Networking	1.32.0	Errori di comunicazione del servizio ClusterIP I servizi ClusterIP potrebbero riscontrare connessioni intermittenti o non riuscite quando il traffico viene indirizzato ai pod di backend su nodi diversi. Questo errore di comunicazione è causato da una regressione in Cilium v1.15 che ha comportato la rimozione delle regole CILIUM_POST_nat da iptables. Le regole CILIUM_POST_nat sono necessarie per la Network Address Translation dell'origine (SNAT) e la loro rimozione comporta un mascheramento inaffidabile da parte di kube-proxy, il che comporta errori di comunicazione del servizio ClusterIP. Ad esempio, se stai eseguendo l'upgrade di un cluster e l'operazione si blocca, potresti visualizzare messaggi di log come i seguenti, che indicano che il handshake TLS ha raggiunto il timeout mentre il servizio ClusterIP tenta di connettersi al server API nel pool di nodi np1: I0527 15:42:39.261368 372146 upgrade.go:994] Error trying to connect to api server: Get "https://10.200.0.108:443/apis/baremetal.cluster.gke.io/v1/namespaces/cluster-baremetal-test/nodepools/np1": net/http: TLS handshake timeout E0527 15:42:39.264789 372146 exec.go:207] command "/root/bmctl-upgrade upgrade cluster --kubeconfig /root/bmctl-workspace/baremetal-test/baremetal-test-kubeconfig --quiet --cluster baremetal-test --manifest-profile-env staging" times out Questo problema è stato risolto nella versione 1.32.100 e successive. Soluzione temporanea: Se non puoi eseguire l'upgrade a una versione con la correzione, ti consigliamo di eseguire l'upgrade manuale dell'immagine Cilium alla versione v1.15.6-anthos1.32.50 o successive. Questo aggiornamento risolve il problema reintroducendo le regole CILIUM_POST_nat necessarie. Nota:puoi anche ripristinare la comunicazione aggiornando manualmente le regole iptables per aggiungere la regola NAT mancante, ma non consigliamo questo tipo di modifica. Modifiche alla configurazione di basso livello come questa potrebbero non essere mantenute dopo i riavvii dei nodi o gli aggiornamenti del cluster. Per eseguire l'upgrade dell'immagine Cilium: Modifica il DaemonSet anetd nello spazio dei nomi kube-system: kubectl edit ds anetd -n kube-system Replace all occurrences of the Cilium image tag with version v1.15.6-anthos1.32.50 or a later version. Example old image: image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.41@sha256:1940fccc... Esempio di nuova immagine: image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.50 Salva le modifiche e chiudi l'editor.
Installazione, upgrade e aggiornamenti	1,33	bmctl configure projects restituisce l'errore Identity Pool does not exist Quando tenti di utilizzare il comando bmctl configure projects per configurare la federazione delle identità per i carichi di lavoro per un nuovo progetto Google Cloud , il comando non va a buon fine e viene visualizzato il seguente messaggio di errore: Error ((retry 1) error adding iam policy bindings: failed to add project binding: failed to set project "<>" iam policy: googleapi: Error 400: Identity Pool does not exist (projectID.). Please check that you specified a valid resource name as returned in the `name` attribute in the configuration API., badRequest) ensuring iam policy binding: project-Id Questo errore si verifica perché il pool di identità del workload predefinito necessario denominato projectID. non viene sottoposto a provisioning automatico nel nuovo progetto. Soluzione temporanea: Per configurare la federazione delle identità per i carichi di lavoro per il tuo progetto, segui questi passaggi: Crea manualmente il pool di identità del workload predefinito mancante: gcloud iam workload-identity-pools create PROJECT_ID. \ --location=global \ --project=PROJECT_ID Sostituisci PROJECT_ID con l'ID progetto. Nella workstation di amministrazione, aggiorna la variabile di ambiente GCP_ACCESS_TOKEN con un token di accesso appena recuperato: export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token) Per impostazione predefinita, il token di accesso ha una durata di 3600 secondi (1 ora). Quando utilizzi l'autenticazione del cluster Workload Identity, bmctl controlla la scadenza del token. Se la scadenza del token è entro 1800 secondi (30 minuti), bmctl segnala un errore ed esce. Esegui di nuovo bmctl configure projects.
Upgrade e aggiornamenti, logging e monitoraggio	1.29, 1.30, 1.31, 1.32	cal-update Il playbook Ansible non riesce a modificare il flag di audit logging Il playbook Ansible cal-update contiene errori logici che ne causano l'esito negativo quando si tenta di modificare il flag disableCloudAuditLogging. Ciò impedisce l'attivazione o la disattivazione corretta dei log di controllo. Quando disableCloudAuditLogging viene modificato da true a false, i log di controllo non possono essere attivati perché lo script non va a buon fine prima di applicare la modifica alla configurazione di kube-apiserver. Quando disableCloudAuditLogging viene modificato da false a true, gli audit log possono essere disabilitati, ma il job cal-update non va a buon fine in modo continuo, impedendo al playbook di raggiungere i controlli di integrità. Il messaggio di errore osservato è: The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines' Soluzione temporanea: Non esiste una soluzione alternativa a questo problema, devi eseguire l'upgrade del cluster a una versione che contenga la correzione. Quando esegui l'upgrade, segui questi passaggi: Disabilita l'audit logging impostando disableCloudAuditLogging su true. Quando la patch è disponibile, esegui l'upgrade del cluster a una delle seguenti versioni patch di rilascio secondario (o successive), che contengono la correzione: 1.30.1200 1.31.800 1.32.400 Per riattivare gli audit log di Cloud, imposta disableCloudAuditLogging di nuovo su false.
Upgrade e aggiornamenti	1.32+	Gli upgrade dei cluster di amministrazione ad alta disponibilità (HA) non riescono dopo un'operazione di riparazione Sui cluster di amministrazione HA, il comando gkectl upgrade admin non riesce e si blocca quando lo esegui dopo aver eseguito il comando gkectl repair admin-master. Il comando gkectl repair admin-master aggiunge un'annotazione machine.onprem.gke.io/managed=false alle macchine riparate. Questa annotazione fa sì che il controller cluster-api rimanga bloccato in uno stato di riconciliazione quando esegui il comando gkectl upgrade admin. Gli upgrade per i cluster non HA includono una logica di pivot che rimuove questa annotazione, ma la logica di pivot non è presente negli upgrade per i cluster HA. Soluzione temporanea: Rimuovi manualmente l'annotazione machine.onprem.gke.io/managed dalle risorse macchina sul cluster di amministrazione prima di iniziare l'upgrade.
Upgrade, configurazione	1.32.0 - 1.32.200	Il mirror del registro causa l'errore del controllo preflight dell'upgrade I cluster configurati con un mirror del registro non superano il controllo preflight check_gcr_pass durante un upgrade alla versione 1.32.0 o successive. Questo errore è dovuto a una modifica nel modo in cui viene creata la risorsa personalizzata PreflightCheck, che omette le configurazioni del mirror del registro dalla specifica del cluster utilizzata nel controllo. Questo problema è stato scoperto durante i test interni sui cluster con configurazioni di proxy e mirror del registro. Soluzione temporanea: Puoi utilizzare una delle seguenti opzioni come soluzione alternativa a questo problema: Utilizza il flag --force quando attivi l'upgrade. Ottieni la configurazione attuale del cluster utilizzando bmctl get config e utilizza questo file di configurazione appena generato per attivare l'upgrade.
Configurazione, Aggiornamenti	Da 1.15 a 1.30, da 1.31.0 a 1.31.800, da 1.32.0 a 1.32.300	CronJob di controllo dell'integrità periodico non viene aggiornato dopo le modifiche alla specifica del cluster Nelle versioni del cluster specificate, i CronJob di controllo di integrità periodici potrebbero non aggiornare le proprie specifiche quando vengono apportate modifiche alla configurazione della risorsa Cluster. Questi errori di aggiornamento comportano controlli di integrità obsoleti e potenziali errori dei job. Questo problema è stato risolto nelle versioni 1.31.900, 1.32.400 e 1.33.0 e successive di Google Distributed Cloud. Soluzione temporanea: Per le versioni 1.30 e precedenti, puoi utilizzare la seguente procedura come soluzione alternativa: Disattiva controlli di integrità periodici. Questa operazione elimina la risorsa HealthCheck attuale. Riattiva i controlli di integrità periodici. Vengono create nuove risorse HealthCheck, che tengono conto della configurazione più recente del cluster.
Networking	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31	Interleaving gratuitous ARP per il VIP del control plane Keepalived viene utilizzato per spostare il VIP del control plane da una macchina all'altra per ottenere l'alta disponibilità. Quando il VIP del control plane viene gestito dal bilanciatore del carico di livello 2 in bundle, è possibile che i failover dell'istanza Keepalived possano causare brevi intervalli (meno di un secondo) di tempo in cui vengono intercalati ARP senza costi con indirizzi MAC diversi. L'infrastruttura di rete di commutazione può interpretare questo interleaving come anomalo e negare ulteriori messaggi ARP per periodi fino a 30 minuti. I messaggi ARP bloccati possono, a loro volta, comportare l'indisponibilità del VIP del control plane durante questo periodo. L'interleaving degli ARP senza costi è causato dalle impostazioni di Keepalived utilizzate nella versione 1.31 e precedenti. Nello specifico, tutti i nodi sono stati configurati per utilizzare la stessa priorità. Le modifiche alla configurazione di Keepalived nella versione 1.32 risolvono questo problema configurando priorità diverse per ogni istanza di Keepalived e fornendo anche un'impostazione del cluster, controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat, per ridurre il numero di ARP senza costi. Soluzione temporanea: Per le versioni 1.31 e precedenti, puoi ridurre l'interleaving degli ARP senza costi modificando direttamente il file di configurazione Keepalived, /usr/local/etc/keepalived/keepalived.conf. Per ciascuno dei nodi che eseguono il bilanciatore del carico del control plane, modifica il file di configurazione per cambiare le seguenti impostazioni: priority: imposta un valore priority distinto per ogni nodo (i valori validi sono compresi tra 1 e 254) weight: modifica il valore di weight da -2 a -253 per assicurarti che venga attivato un failover di Keepalived quando un controllo di integrità non va a buon fine.
Logging e monitoraggio	1.30, 1.31, 1.32, 1.33	Discrepanza nella metrica kubernetes.io/anthos/custom_resurce_watchers A causa di un errore di definizione interno, la metrica kubernetes.io/anthos/custom_resurce_watchers potrebbe mostrare dati imprecisi. Se il problema ti riguarda, potresti visualizzare errori nei log simili ai seguenti: One or more TimeSeries could not be written: timeSeries[42]: Value type for metric kubernetes.io/anthos/custom_resurce_watchers must be INT64, but is DOUBLE. Puoi ignorare questi errori. Questa metrica non viene utilizzata per avvisi di sistema critici e gli errori non influiscono sul funzionamento del tuo progetto o dei tuoi cluster.
Operazione	1.30, 1.31, 1.32, 1.33	L'acquisizione dello snapshot non è riuscita ad analizzare il file di configurazione del cluster Se la directory .manifests non è presente nella workstation di amministrazione quando esegui bmctl check cluster --snapshot, il comando non riesce e viene visualizzato un errore simile al seguente: Error message: failing while capturing snapshot failed to parse cluster config file failed to get CRD file Questo errore si verifica perché il comando bmctl check cluster --snapshot richiede i file di definizione di risorsa personalizzata nella directory .manifests per convalidare la configurazione del cluster. Questa directory viene in genere creata durante la configurazione del cluster. Se elimini accidentalmente la directory o esegui bmctl da una posizione diversa, il comando non può procedere con l'operazione di snapshot. Soluzioni: Puoi risolvere il problema rigenerando manualmente la directory .manifests utilizzando uno dei seguenti metodi: Esegui il comando bmctl check cluster: bmctl check cluster --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG Nell'ambito dei controlli iniziali, questo comando crea automaticamente la directory .manifests nella directory di lavoro corrente, indipendentemente dal fatto che il comando venga completato correttamente o meno. Nella directory contenente il file di configurazione del cluster corrente, esegui il comando bmctl create cluster: bmctl create cluster --cluster TEST_CLUSTER Sebbene questo comando probabilmente generi un errore, ad esempio Unable to Parse Cluster Configuration File, la directory .manifests viene comunque creata nella directory di lavoro corrente. La directory temporanea bmctl-workspace/TEST_CLUSTER generata può essere eliminata in sicurezza in un secondo momento. Dopo aver eseguito una delle soluzioni alternative precedenti, riprova il comando bmctl check cluster --snapshot.
Installazione, upgrade e aggiornamenti	1.32.0, 1.32.100	Il VIP del control plane non viene spostato quando HAProxy non è disponibile Se l'istanza HAProxy non è disponibile su un nodo che ospita il VIP del control plane, l'impostazione nopreempt nell'istanza Keepalived impedisce lo spostamento del VIP del control plane a un nodo con un HAProxy integro. Questo problema è correlato a una funzionalità che configura automaticamente le priorità del protocollo VRRP (Virtual Router Redundancy Protocol) di Keepalived incompatibili con l'impostazione nopreempt. Soluzione temporanea: Per risolvere il problema, segui questi passaggi per disattivare la funzionalità Keepalived: Aggiungi l'annotazione preview.baremetal.cluster.gke.io/keepalived-different-priorities: "disable" al cluster: kubectl annotate --kubeconfig ADMIN_KUBECONFIG \ -n CLUSTER_NAMESPACE \ clusters.baremetal.cluster.gke.io/CLUSTER_NAME \ preview.baremetal.cluster.gke.io/keepalived-different-priorities="disable" Rimuovi nopreempt da /usr/local/etc/keepalived/keepalived.conf sui nodi che eseguono il bilanciatore del carico del control plane. A seconda della configurazione del bilanciatore del carico, si tratta dei nodi del control plane o dei nodi di un pool di nodi del bilanciatore del carico. Dopo la rimozione di nopreempt, i pod statici keepalived devono essere riavviati per rilevare le modifiche apportate ai file di configurazione. Per farlo, su ogni nodo, utilizza il seguente comando per riavviare i pod keepalived: crictl rmp -f \ $(crictl pods --namespace=kube-system --name='keepalived-*' -q)
Installazione, upgrade e aggiornamenti	1.30, 1.31, 1.32.0	abm-tools-* cartelle non vengono pulite I job di preflight e controllo di integrità non riusciti possono lasciare artefatti nelle cartelle abm-tools-* con timestamp in /usr/local/bin. Se sei interessato da questo problema, potresti visualizzare numerose cartelle come la seguente: /usr/local/bin/abm-tools-preflight-20250410T114317. Errori ripetuti possono comportare un aumento dell'utilizzo del disco. Soluzione temporanea Se riscontri questo problema, rimuovi manualmente queste cartelle: rm -rf /usr/local/bin/abm-tools-*
Networking	1.28.0-1.28.200	Il traffico del bilanciatore del carico viene eliminato quando viene utilizzato un gateway NAT in uscita Nei cluster in cui è abilitato il gateway NAT in uscita, se un bilanciatore del carico sceglie backend che corrispondono alle regole di selezione del traffico specificate da una risorsa personalizzata EgressNATPolicy obsoleta, il traffico del bilanciatore del carico viene eliminato. Questo problema si verifica durante la creazione e l'eliminazione dei pod che corrispondono a un criterio di uscita. I criteri di uscita non vengono puliti come dovrebbero quando i pod vengono eliminati e i criteri di uscita obsoleti fanno sì che i pod LoadBalancer tentino di inviare traffico a una connessione che non esiste più. Questo problema è stato risolto nelle versioni 1.28.300 e successive di Google Distributed Cloud. Soluzione temporanea Per eseguire la pulizia delle risorse della policy NAT in uscita, riavvia ogni nodo che ospita un backend non funzionante.
Upgrade e aggiornamenti, ripristino/eliminazione	1,28	machine-init failure - new control plane node stuck during replacement Quando sostituisci (rimuovi, aggiungi) un nodo del control plane in Google Distributed Cloud 1.28, il nuovo nodo potrebbe non riuscire a unirsi al cluster. Questo perché il processo responsabile della configurazione del nuovo nodo (bm-system-machine-init) rileva il seguente errore: Failed to add etcd member: etcdserver: unhealthy cluster Questo errore si verifica quando un vecchio nodo del piano di controllo viene rimosso e la sua appartenenza a etcd-events non viene pulita correttamente, lasciando un membro obsoleto. Il membro obsoleto impedisce ai nuovi nodi di unirsi al cluster etcd-events, causando l'errore del processo machine-init e la ricreazione continua del nuovo nodo. Le conseguenze di questo problema includono: Il nuovo nodo del control plane non può essere avviato correttamente. Il cluster può bloccarsi nello stato RECONCILING. Il nodo del control plane viene eliminato e ricreato continuamente a causa dell'errore machine-init. Questo problema è stato risolto nelle versioni 1.29 e successive. Soluzione temporanea: Se non riesci a eseguire l'upgrade alla versione 1.29, puoi pulire manualmente il membro etcd-events difettoso dal cluster seguendo le istruzioni riportate di seguito: Utilizza SSH per accedere a un nodo del control plane funzionante. Esegui questo comando: ETCDCTL_API=3 etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=localhost:2382 \ member list Se la risposta include il nodo rimosso nell'elenco dei membri, trova l'ID membro nella prima colonna del nodo ed esegui il seguente comando: ETCDCTL_API=3 etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=localhost:2382 \ member remove MEMBER_ID Sostituisci MEMBER_ID con l'ID membro del nodo rimosso. Il nuovo nodo del control plane dovrebbe unirsi automaticamente al cluster dopo alcuni minuti.
Upgrade e aggiornamenti	1.30.500-gke.126, 1.30.600-gke.68, 1.31.100-gke.136, 1.31.200-gke.58	Errore di upgrade del control plane a causa della mancanza del file super-admin.conf Durante l'upgrade di un cluster, il processo di upgrade potrebbe non riuscire sul primo nodo del control plane con un messaggio di errore all'interno del job Ansible che indica che il file super-admin.conf non è presente. Questo problema si verifica perché il primo nodo del control plane di cui è stato eseguito l'upgrade potrebbe non essere il primo nodo di cui è stato eseguito il provisioning durante la creazione del cluster. Il processo di upgrade presuppone che il primo nodo da aggiornare sia quello che contiene il file super-admin.conf. Questo problema è stato risolto nei seguenti aggiornamenti delle patch: 1.30.500-gke.127, 1.30.600-gke.69 e 1.31.200-gke.59 Soluzione temporanea: Per mitigare il problema, esegui il seguente passaggio sul nodo non riuscito: Copia il file /etc/kubernetes/admin.conf in /etc/kubernetes/super-admin.conf: cp /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf Il processo di upgrade viene ritentato automaticamente e dovrebbe procedere correttamente.
Upgrade e aggiornamenti	1.29.0 - 1.29.1100, 1.30.0 - 1.30.400	Lo svuotamento dei nodi si blocca se i pod tollerano le incompatibilità NoSchedule I pod con una tolleranza NoSchedule vengono presi in considerazione per l'espulsione durante gli upgrade. Tuttavia, a causa della tolleranza NoSchedule, il controller Deployment o DaemonSet potrebbe pianificare nuovamente il pod sul nodo in manutenzione, ritardando potenzialmente l'upgrade. Per verificare se il problema ti riguarda, procedi nel seguente modo: Controlla i log dei pod anthos-cluster-operator per identificare i pod che impediscono lo svuotamento del nodo. Nello snippet di log di esempio seguente, il pod node-problem-detector-mgmt-ydhc2 non è ancora stato svuotato: nodepool_controller.go:720] controllers/NodePool "msg"="Pods yet to drain for 10.0.0.3 machine are 1 : [node-problem-detector-mgmt-ydhc2]" "nodepool"={"Namespace":"test-cluster","Name":"test-cluster"} Per ogni pod che impedisce lo svuotamento del nodo, esegui il comando seguente per controllare le tolleranze: kubectl get po POD_NAME -n kube-system \ -o json | jq '.spec.tolerations' Sostituisci POD_NAME con il nome del pod che impedisce lo svuotamento del nodo. Dovresti visualizzare una delle seguenti combinazioni: Tolleranza con effetto NoSchedule e operatore Exists Tolleranza con effetto NoSchedule e chiave "baremetal.cluster.gke.io/maintenance" Tolleranza con un effetto vuoto e chiave "baremetal.cluster.gke.io/maintenance" Ad esempio, la risposta potrebbe avere il seguente aspetto: { "effect": "NoSchedule", "operator": "Exists" }, Soluzione temporanea: Puoi sbloccare lo svuotamento del nodo in uno dei seguenti modi: Aggiungi la tolleranza baremetal.cluster.gke.io/maintenance:NoExecute ai pod che hanno una tolleranza baremetal.cluster.gke.io/maintenance:Schedule e non richiedono l'arresto controllato. Rimuovi le combinazioni di tolleranze identificate dai pod che devono essere espulsi durante lo svuotamento dei nodi.
Networking	1.28, 1.29 e 1.30	Le chiamate di rete ai pod con hostPort abilitato non riescono per le richieste provenienti dallo stesso nodo Le chiamate di rete ai pod con hostPort abilitato non vanno a buon fine e i pacchetti vengono eliminati se la richiesta ha origine dallo stesso nodo in cui è in esecuzione il pod. Ciò vale per tutti i tipi di cluster e nodi. I cluster creati senza kube-proxy, tuttavia, non sono interessati. Controlla se il problema ti riguarda: Recupera i nomi dei pod anetd: I pod anetd sono responsabili del controllo del traffico di rete. kubectl get pods -l k8s-app=cilium -n kube-system Controlla lo stato dei pod anetd: kubectl -n kube-system exec -it ANETD_POD_NAME -- cilium status --all-clusters Sostituisci ANETD_POD_NAME con il nome di uno dei pod anetd nel tuo cluster. Se la risposta include KubeProxyReplacement: Partial ..., allora il problema ti riguarda. Soluzione temporanea Se hai un caso d'uso per l'invio di richieste ai pod che utilizzano hostPort dallo stesso nodo su cui vengono eseguiti, puoi creare un cluster senza kube-proxy. In alternativa, puoi configurare i pod in modo che utilizzino un portmap plug-in Container Network Interface (CNI).
Logging e monitoraggio	Identificato nella versione 1.29.100, possibilità di verificarsi anche in altre versioni	I/O del disco elevato a causa della perdita di connettività di rete o di un service account non valido I pod stackdriver-log-forwarder potrebbero riscontrare una perdita di connettività o avere un account di servizio scaduto, il che causerà l'impossibilità di inviare questi log a logging.googleapis.com, con conseguente accumulo di log nel buffer e I/O su disco elevato. L'agente Cloud Logging (Fluent Bit), un daemonset denominato stackdriver-log-forwarder, utilizza un buffer basato sul file system con un limite di 4 GB. Quando è pieno, l'agente tenta di ruotare o svuotare il buffer, il che può causare un I/O elevato. Aspetti da verificare: Verifica se le chiavi del account di servizio (SA) sono scadute. In caso affermativo, ruotali per risolvere il problema. Puoi confermare il account di servizio attualmente utilizzato utilizzando il seguente comando e convalidarlo in IAM: kubectl get secret google-cloud-credentials -n CLUSTER_NAMESPACE -o jsonpath='{.data.credentials\.json}' | base64 --decode Soluzione temporanea: Avviso:la rimozione del buffer comporterà la perdita definitiva di tutti i log attualmente archiviati nel buffer (inclusi i log di nodi, pod e container Kubernetes). Se l'accumulo del buffer è causato dalla perdita di connettività di rete al servizio di logging di Google Cloud, questi log andranno persi definitivamente quando il buffer viene eliminato o se il buffer è pieno e l'agente non è in grado di inviare i log. Rimuovi il pod DaemonSet stackdriver-log-forwarder dal cluster aggiungendo un selettore di nodi (in questo modo viene mantenuto il DaemonSet stackdriver-log-forwarder, ma viene annullata la pianificazione dai nodi): 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 siano eliminati prima di passare al passaggio successivo. Se questo problema si verifica solo per uno o pochi nodi: Connettiti al nodo utilizzando SSH in cui era in esecuzione stackdriver-log-forwarder (verifica che stackdriver-log-forwarder non sia più in esecuzione su questi nodi). Sul nodo, elimina tutti i file buffer utilizzando rm -rf /var/log/fluent-bit-buffers/ e poi segui il passaggio 6. Se ci sono troppi nodi con questi file e vuoi applicare uno script per pulire tutti i nodi che hanno questi blocchi di backlog, utilizza i seguenti script: Esegui il deployment di un DaemonSet per pulire tutti i dati 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 Assicurati che DaemonSet abbia pulito tutti i nodi. L'output dei due comandi seguenti deve 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 Elimina il DaemonSet di pulizia: kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup 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"}]'
Upgrade e aggiornamenti, Operazione	1.28, 1.29, 1.30.0 e 1.30.100	Upgrade bloccati da pod bloccati a causa di un problema di containerd I pod possono bloccarsi durante la terminazione quando i nodi vengono svuotati. I pod bloccati possono bloccare operazioni, come gli upgrade, che svuotano i nodi. I pod possono bloccarsi quando il container viene visualizzato come in esecuzione anche se il processo principale sottostante del container è già terminato correttamente. In questo caso, il comando crictl stop non arresta neanche il container. Per verificare se il problema ti riguarda, segui questi passaggi: Controlla se nel cluster sono presenti pod bloccati con lo stato Terminating: kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -o wide | grep Terminating Per i pod bloccati in fase di terminazione, utilizza kubectl describe per verificare la presenza di eventi: kubectl describe pod POD_NAME \ --kubeconfig CLUSTER_KUBECONFIG \ -n NAMESPACE Se visualizzi avvisi come i seguenti con Unhealthy e FailedKillPod come motivi, il problema ti riguarda: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedKillPod 19m (x592 over 46h) kubelet error killing pod: [failed to "KillContainer" for "dnsmasq" with KillContainerError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded", failed to "KillPodSandbox" for "0843f660-461e-458e-8f07-efe052deae23" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"] Warning Unhealthy 4m37s (x16870 over 46h) kubelet (combined from similar events): Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "c1ea4ffe7e4f1bacaab4f312bcc45c879785f6e22e7dc2d94abc3a019e20e1a9": OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown Questo problema è causato da un problema upstream di containerd, che è stato risolto nelle versioni 1.28.1000, 1.29.600, 1.30.200, 1.31 e successive di Google Distributed Cloud. Soluzione temporanea Per sbloccare l'operazione del cluster: Forza l'eliminazione di eventuali pod bloccati: kubectl delete pod POD_NAME -n POD_NAMESPACE --force Quando i pod vengono riavviati correttamente, riprova l'operazione del cluster.
Upgrade e aggiornamenti, Operazione	1.28, 1.29 e 1.30.0-1.30.100	Aggiornamenti bloccati da pod bloccati a causa dell'impossibilità di rimuovere cgroups I pod possono bloccarsi durante la terminazione quando i nodi vengono svuotati. I pod bloccati possono bloccare le operazioni del cluster, come gli upgrade, che svuotano i nodi. I pod possono bloccarsi quando il processo runc init si blocca, il che impedisce a containerd di eliminare cgroups associato al pod. Per verificare se il problema ti riguarda, segui questi passaggi: Controlla se nel cluster sono presenti pod bloccati con lo stato Terminating: kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -o wide | grep Terminating Controlla i log kubelet nei nodi con pod bloccati in fase di terminazione: Il seguente comando restituisce le voci di log che contengono il testo Failed to remove cgroup. journalctl -u kubelet --no-pager -f | grep "Failed to remove cgroup" Se la risposta contiene avvisi come il seguente, il problema ti riguarda: May 22 23:08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[3751]: time="2024-05-22T23:08:00Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" ... May 22 23:09:04 control-1 kubelet[3751]: time="2024-05-22T23:09:04Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" ... Soluzione temporanea Per riattivare il processo runc init e sbloccare le operazioni del cluster: Utilizzando il percorso cgroup dai log di kubelet, verifica se cgroup è bloccato controllando i contenuti del file freezer.state: cat CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state I contenuti di freezer.state indicano lo stato di cgroup. Con un percorso dalle voci di log dell'esempio precedente, il comando avrebbe il seguente aspetto: cat /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope/freezer.state Sblocca cgroups che si trovano nello stato FREEZING o FROZEN: echo "THAWED" > CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state Quando i cgroups sono stati THAWED, i processi runc init corrispondenti vengono chiusi automaticamente e i cgroups vengono rimossi automaticamente. In questo modo non verranno visualizzati ulteriori avvisi Failed to remove cgroup nei log di kubelet. Anche i pod bloccati nello stato Terminating vengono rimossi automaticamente poco dopo la pulizia. Una volta puliti i cgroups bloccati e rimossi i pod bloccati, riprova l'operazione del cluster.
Configurazione, networking	Da 1.28.0 a 1.28.1000, da 1.29.0 a 1.29.500 e da 1.30.0 a 1.30.200	Eventi NodeNotReady a causa di aggiornamenti del lease non riusciti Nelle versioni identificate di Google Distributed Cloud, kubelet potrebbe non riuscire ad aggiornare i lease dei nodi per più di 40 secondi, generando eventi NodeNotReady. Il problema è intermittente e si verifica circa ogni 7 giorni. Il failover del VIP del control plane potrebbe verificarsi intorno al momento degli eventi NodeNotReady. Questo problema è stato risolto nelle versioni 1.28.1100, 1.29.600, 1.30.300 e successive. Soluzione temporanea: Per mitigare il problema, puoi configurare kubelet nel seguente modo: Crea /etc/default/kubelet e aggiungi le seguenti variabili di ambiente: HTTP2_READ_IDLE_TIMEOUT_SECONDS=10 HTTP2_PING_TIMEOUT_SECONDS=5 Riavvia kubelet: systemctl restart kubelet Recupera il nuovo ID processo (PID) per kubelet: pgrep kubelet Verifica che le variabili di ambiente diventino effettive dopo il riavvio di kubelet sul nodo: cat /proc/KUBELET_PID/environ | tr '\0' '\n' | grep -e HTTP2_READ_IDLE_TIMEOUT_SECONDS -e HTTP2_PING_TIMEOUT_SECONDS Sostituisci KUBELET_PID con l'output del comando nel passaggio precedente. L'output comando cat dovrebbe elencare le due variabili di ambiente aggiunte nelle ultime righe.
Aggiornamenti	1,30	Errore del campo immutabile durante l'aggiornamento dei cluster utente con bmctl versione 1.30.x Quando crei un cluster utente utilizzando il comando bmctl create cluster e trasmetti il campo cloudOperationsServiceAccountKeyPath nell'intestazione, il campo spec.clusterOperations.serviceAccountSecret viene aggiunto alla risorsa Cluster creata. Questo campo non è presente nel file di configurazione del cluster ed è immutabile. Il comando bmctl update cluster non compila questo campo dall'intestazione, quindi i tentativi di aggiornamento del cluster con il comando bmctl update cluster e il file di configurazione del cluster originale non vanno a buon fine e viene visualizzato il seguente errore: [2025-01-15 16:38:46+0000] Failed to calculate diff: --- E000090: Unable to calculate diff An error occurred while calculating diff between live configuration and cluster.yaml file Wrapped error: error in dryRunClient.Update for {map[apiVersion:baremetal.cluster.gke.io/v1 kind:Cluster metadata:map[annotations:map[baremetal.cluster.gke.io/enable-kubelet-read-only-port:false baremetal.cluster.gke.io/maintenance-mode-deadline-seconds:180 preview.baremetal.cluster.gke.io/add-on-configuration:enable] creationTimestamp: name:user-test namespace:cluster-user-test resourceVersion:1171702] spec:map[anthosBareMetalVersion:0.0.0-gke.0 bypassPreflightCheck:false clusterNetwork:map[multipleNetworkInterfaces:false pods:map[cidrBlocks:[10.240.0.0/13]] services:map[cidrBlocks:[172.26.0.0/16]]] clusterOperations:map[location:us-west1 projectID:baremetal-test] controlPlane:map[nodePoolSpec:map[nodes:[map[address:10.200.0.15]]]] gkeConnect:map[projectID:baremetal-test] loadBalancer:map[addressPools:[map[addresses:[10.200.0.20/32 10.200.0.21/32 10.200.0.22/32 10.200.0.23/32 10.200.0.24/32 fd00:1::15/128 fd00:1::16/128 fd00:1::17/128 fd00:1::18/128] name:pool1]] mode:bundled ports:map[controlPlaneLBPort:443] vips:map[controlPlaneVIP:10.200.0.19 ingressVIP:10.200.0.20]] nodeAccess:map[loginUser:root] nodeConfig:map[podDensity:map[maxPodsPerNode:250]] profile:default storage:map[lvpNodeMounts:map[path:/mnt/localpv-disk storageClassName:local-disks] lvpShare:map[numPVUnderSharedPath:5 path:/mnt/localpv-share storageClassName:local-shared]] type:user] status:map[]]}: admission webhook "vcluster.kb.io" denied the request: Cluster.baremetal.cluster.gke.io "user-test" is invalid: spec: Forbidden: Fields should be immutable. (A in old) (B in new) {"clusterNetwork":{"multipleNetworkInterfaces":false,"services":{"cidrBlocks":["172.26.0.0/16"]},"pods":{"cidrBlocks":["10.240.0.0/13"]},"bundledIngress":true},"controlPlane":{"nodePoolSpec":{"nodes":[{"address":"10.200.0.15"}],"operatingSystem":"linux"}},"credentials":{"sshKeySecret":{"name":"ssh-key","namespace":"cluster-user-test"},"imagePullSecret":{"name":"private-registry-creds","namespace":"cluster-user-test"}},"loadBalancer":{"mode":"bundled","ports":{"controlPlaneLBPort":443},"vips":{"controlPlaneVIP":"10.200.0.19","ingressVIP":"10.200.0.20"},"addressPools":[{"name":"pool1","addresses":["10.200.0.20/32","10.200.0.21/32","10.200.0.22/32","10.200.0.23/32","10.200.0.24/32","fd00:1::15/128","fd00:1::16/128","fd00:1::17/128","fd00:1::18/128"]}]},"gkeConnect":{"projectID":"baremetal-test","location":"global","connectServiceAccountSecret":{"name":"gke-connect","namespace":"cluster-user-test"},"registerServiceAccountSecret":{"name":"gke-register","namespace":"cluster-user-test"}},"storage":{"lvpShare":{"path":"/mnt/localpv-share","storageClassName":"local-shared","numPVUnderSharedPath":5},"lvpNodeMounts":{"path":"/mnt/localpv-disk","storageClassName":"local-disks"}},"clusterOperations":{"projectID":"baremetal-test","location":"us-west1" A: ,"serviceAccountSecret":{"name":"google-cloud-credentials","namespace":"cluster-user-test"}},"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"} B: },"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"} For more information, see https://cloud.google.com/distributed-cloud/docs/reference/gke-error-ref#E000090 Questo problema si verifica solo quando utilizzi una versione 1.30.x di bmctl per eseguire gli aggiornamenti. Soluzione temporanea: Come soluzione alternativa, puoi ottenere la configurazione del cluster della risorsa cluster effettiva prima di apportare gli aggiornamenti: Recupera il file di configurazione del cluster utente in base alla risorsa del cluster di cui è stato eseguito il deployment: bmctl get config --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG_PATH La risorsa personalizzata recuperata viene scritta in un file YAML denominato: bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP.yaml. Questo nuovo file di configurazione include spec.clusterOperations.serviceAccountSecret, necessario per il funzionamento del comando di aggiornamento. TIMESTAMP nel nome file indica la data e l'ora di creazione del file. Sostituisci il file di configurazione del cluster esistente con il file recuperato. Salva il backup del file esistente. Modifica il nuovo file di configurazione del cluster e utilizza bmctl update per aggiornare il cluster utente: bmctl update cluster --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG_PATH
Upgrade e aggiornamenti, Sicurezza	1.29, 1.30 e 1.31	La rotazione del certificato Kubelet non riesce quando i file del certificato corrente non sono link simbolici La rotazione dei certificati kubelet non riesce quando kubelet-client-current.pem e kubelet-server-current.pem sono file effettivi, anziché link simbolici. Questo problema può verificarsi dopo aver utilizzato bmctl restore per ripristinare un cluster da un backup. Soluzione temporanea: Se riscontri questo problema, puoi utilizzare i seguenti passaggi come soluzione alternativa: Esegui il backup dei file dei certificati attuali: mkdir -p ~/kubelet-backup/ cp -r /var/lib/kubelet/pki/ ~/kubelet-backup/ (Facoltativo) Elimina i file dei certificati accumulati: ls | grep -E "^kubelet-server-20*" | xargs rm -rf ls | grep -E "^kubelet-client-20*" | xargs rm -rf Rinomina i file kubelet-client-current.pem e kubelet-server-current.pem: L'utilizzo di un timestamp è uno schema di ridenominazione comune. datetime=$(date +%Y-%m-%d-%H-%M-%S) mv kubelet-server-current.pem kubelet-server-${datetime}.pem mv kubelet-client-current.pem kubelet-client-${datetime}.pem Nella stessa sessione del comando precedente, crea link simbolici che puntano ai certificati validi più recenti (rinominati): ln -s kubelet-server-${datetime}.pem kubelet-server-current.pem ln -s kubelet-client-${datetime}.pem kubelet-client-current.pem Imposta le autorizzazioni su 777 per i link simbolici: chmod 777 kubelet-server-current.pem chmod 777 kubelet-client-current.pem Se la rotazione dei certificati va a buon fine, elimina la directory di backup: rm -rf ~/kubelet-backup/
Installazione, upgrade e aggiornamenti	1,31	Errori durante la creazione di risorse personalizzate Nella versione 1.31 di Google Distributed Cloud, potresti ricevere errori quando tenti di creare risorse personalizzate, come cluster (di tutti i tipi) e carichi di lavoro. Il problema è causato da una modifica sostanziale introdotta in Kubernetes 1.31 che impedisce la transizione del campo caBundle in una definizione di risorsa personalizzata da uno stato valido a uno non valido. Per saperne di più sulla modifica, consulta il changelog di Kubernetes 1.31. Prima di Kubernetes 1.31, il campo caBundle veniva spesso impostato su un valore provvisorio di \n, perché nelle versioni precedenti di Kubernetes il server API non consentiva contenuti vuoti del bundle CA. L'utilizzo di \n era una soluzione alternativa ragionevole per evitare confusione, in quanto cert-manager in genere aggiorna caBundle in un secondo momento. Se caBundle è stata corretta una volta da uno stato non valido a uno valido, non dovrebbero esserci problemi. Tuttavia, se la definizione della risorsa personalizzata viene riconciliata con \n (o un altro valore non valido), potresti riscontrare il seguente errore: ...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block] Soluzione temporanea Se hai una definizione di risorsa personalizzata in cui caBundle è impostato su un valore non valido, puoi rimuovere in sicurezza l'intero campo caBundle. Il problema dovrebbe risolversi.
Installazione, upgrade e aggiornamenti	1.28, 1.29 e 1.30	Gli upgrade dei cluster richiedono troppo tempo Durante l'upgrade di un cluster, ogni nodo del cluster viene svuotato e sottoposto ad upgrade. Nelle versioni 1.28 e successive, Google Distributed Cloud è passato dallo svuotamento dei nodi basato su taint allo svuotamento basato sull'espulsione. Inoltre, per gestire le interdipendenze dei pod, lo svuotamento basato sull'espulsione segue un ordine di svuotamento in più fasi. In ogni fase di svuotamento, i pod hanno un periodo di tolleranza di 20 minuti per terminare, mentre lo svuotamento precedente basato su taint aveva un singolo timeout di 20 minuti. Se ogni fase richiede 20 minuti per espellere tutti i pod, il tempo per svuotare un nodo può essere significativamente più lungo rispetto allo svuotamento precedente basato sul taint. A sua volta, l'aumento del tempo di svuotamento dei nodi può aumentare notevolmente il tempo necessario per completare un upgrade del cluster o per mettere un cluster in modalità di manutenzione. Esiste anche un problema di Kubernetes upstream che influisce sulla logica di timeout per lo svuotamento basato sull'espulsione. Questo problema potrebbe anche aumentare i tempi di svuotamento dei nodi. Soluzione temporanea: Come soluzione alternativa, puoi disattivare lo svuotamento dei nodi basato sull'espulsione. In questo modo viene ripristinato lo svuotamento basato su taint. Tuttavia, non consigliamo lo svuotamento basato sui taint, perché non rispetta i budget di interruzione dei pod (PDB), il che potrebbe causare interruzioni del servizio.
Installazione, upgrade e aggiornamenti	1.16, 1.28 e 1.29	Il controllo preflight non riuscito obsoleto potrebbe bloccare le operazioni del cluster La riconciliazione del cluster è una fase standard per la maggior parte delle operazioni del cluster, tra cui la creazione e gli upgrade del cluster. Durante la riconciliazione del cluster, il controller del cluster Google Distributed Cloud attiva un controllo preflight. Se questo controllo preliminare non va a buon fine, l'ulteriore riconciliazione del cluster viene bloccata. Di conseguenza, anche le operazioni del cluster che includono la riconciliazione del cluster vengono bloccate. Questo controllo preflight non viene eseguito periodicamente, ma solo nell'ambito della riconciliazione del cluster. Pertanto, anche se risolvi il problema che ha causato l'errore preflight iniziale e i controlli preflight on demand vengono eseguiti correttamente, la riconciliazione del cluster è ancora bloccata a causa di questo controllo preflight non riuscito obsoleto. Se l'installazione o l'upgrade di un cluster è bloccato, puoi verificare se il problema ti riguarda seguendo questi passaggi: Controlla i log del pod anthos-cluster-operator per trovare voci come le seguenti: "msg"="Preflight check not ready. Won't reconcile" Controlla se il controllo preflight attivato dal controller del cluster è in stato di errore: kubectl describe preflightcheck PREFLIGHT_CHECK_NAME \ -n CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Sostituisci quanto segue: PREFLIGHT_CHECK_NAME: il nome del controllo preliminare da eliminare. In questo caso, il nome è uguale al nome del cluster. CLUSTER_NAMESPACE: lo spazio dei nomi del cluster per cui il controllo preflight non è riuscito. ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. Se il controllo preflight non è riuscito (Status.Pass è false), è probabile che tu sia interessato da questo problema. Questo problema è stato risolto nelle versioni 1.30 e successive. Soluzione temporanea Per sbloccare le operazioni del cluster, elimina manualmente il controllo preflight non riuscito dal cluster di amministrazione: kubectl delete preflightcheck PREFLIGHT_CHECK_NAME \ -n CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Una volta eliminato il controllo preflight non aggiornato non riuscito, il controller del cluster è in grado di creare un nuovo controllo preflight.
Installazione, upgrade e aggiornamenti	1.30.100, 1.30.200 e 1.30.300	Le operazioni di creazione o upgrade del cluster utente potrebbero non riuscire La creazione di cluster utente o l'upgrade di cluster utente esistenti alle versioni 1.30.100, 1.30.200 o 1.30.300 potrebbe non riuscire. Questo problema si verifica solo quando kubectl o un client API GKE On-Prem (la console Google Cloud , gcloud CLI o Terraform) viene utilizzato per le operazioni di creazione e upgrade del cluster utente. In questa situazione, l'operazione di creazione del cluster utente si blocca nello stato Provisioning e l'upgrade del cluster utente si blocca nello stato Reconciling. Per verificare se un cluster è interessato, segui questi passaggi: Recupera la risorsa del cluster: kubectl get cluster CLUSTER_NAME -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG Sostituisci quanto segue: CLUSTER_NAME: il nome del cluster utente bloccato. USER_CLUSTER_NAMESPACE: il nome dello spazio dei nomi del cluster utente. ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di gestione. Se il valore CLUSTER STATE è Provisioning o Reconciling, potresti essere interessato da questo problema. La seguente risposta di esempio indica che un upgrade è bloccato: NAME ABM VERSION DESIRED ABM VERSION CLUSTER STATE some-cluster 1.30.0-gke.1930 1.30.100-gke.96 Reconciling Le versioni non corrispondenti indicano anche che l'upgrade del cluster non è stato completato. Trova il nome completo del pod anthos-cluster-operator: kubectl get pods -n kube-system -o=name \ -l baremetal.cluster.gke.io/lifecycle-controller-component=true \ --kubeconfig ADMIN_KUBECONFIG Come mostrato nell'esempio seguente, l'output è un elenco di pod che include il pod anthos-cluster-operator: pod/anthos-cluster-operator-1.30.100-gke.96-d96cf6765-lqbsg pod/cap-controller-manager-1.30.100-gke.96-fcb5b5797-xzmb7 Trasmetti in streaming i log del pod anthos-cluster-operator per un messaggio ripetuto, che indica che il provisioning o la riconciliazione del cluster è bloccato: kubectl logs POD_NAME -n kube-system -f --since=15s \ --kubeconfig ADMIN_KUBECONFIG | \ grep "Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" Sostituisci POD_NAME con il nome completo del pod anthos-cluster-operator del passaggio precedente. Mentre il comando viene eseguito, cerca un flusso continuo di righe di log corrispondenti, che indica che l'operazione del cluster è bloccata. L'output di esempio seguente è simile a quello che vedi quando un cluster è bloccato durante la riconciliazione: ... I1107 17:06:32.528471 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="a09c70a6-059f-4e81-b6b2-aaf19fd5f926" I1107 17:06:37.575174 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="e1906c8a-cee0-43fd-ad78-88d106d4d30a""Name":"user-test-v2"} "err"="1 error occurred:\n\t* failed to construct the job: ConfigMap \"metadata-image-digests\" not found\n\n" ... Premi Ctrl+C per interrompere lo streaming dei log. Controlla se ConfigMapForwarder è bloccato: kubectl get configmapforwarder metadata-image-digests-in-cluster \ -n USER_CLUSTER_NAMESPACE \ -o jsonpath='{range .status.conditions[?(@.type=="Ready")]}Reason: {.reason}{"\n"}Message: {.message}{"\n"}{end}' \ --kubeconfig ADMIN_KUBECONFIG La risposta contiene i motivi e i messaggi della risorsa ConfigMapForwarder. Quando ConfigMapForwarder è in stallo, dovresti vedere un output simile al seguente: Reason: Stalled Message: cannot forward configmap kube-system/metadata-image-digests without "baremetal.cluster.gke.io/mark-source" annotation Verifica che ConfigMap metadata-image-digests non sia presente nello spazio dei nomi del cluster utente: kubectl get configmaps metadata-image-digests \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG La risposta dovrebbe essere simile alla seguente: Error from server (NotFound): configmaps "metadata-image-digests" not found Soluzione temporanea Come soluzione alternativa, puoi aggiornare manualmente ConfigMap per aggiungere l'annotazione mancante: Aggiungi l'annotazione mancante a ConfigMap: kubectl annotate configmap metadata-image-digests \ -n kube-system "baremetal.cluster.gke.io/mark-source"="true" \ --kubeconfig ADMIN_KUBECONFIG Se è annotato correttamente, il ConfigMap metadata-image-digests deve essere creato automaticamente nello spazio dei nomi del cluster utente. Verifica che ConfigMap venga creato automaticamente nello spazio dei nomi del cluster utente: kubectl get configmaps metadata-image-digests \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG Se ConfigMap è stato creato correttamente, la risposta del comando è simile alla seguente: NAME DATA AGE metadata-image-digests 0 7s Con la correzione e la verifica riportate sopra, dovresti vedere l'operatore del cluster sbloccato e le operazioni del cluster procedere come di consueto.
Operazione, reimpostazione/eliminazione	1.30.0 - 1.30.300, 1.29.0 - 1.29.700, 1.28.0 - 1.28.1100	Gli utenti non root non possono eseguire bmctl restore per ripristinare il quorum Quando esegui bmctl restore --control-plane-node come utente non root, si verifica un problema chown durante la copia dei file dal nodo del control plane alla macchina workstation. Soluzione temporanea: Esegui il comando bmctl restore --control-plane-node con sudo per gli utenti non root.
Upgrade	1.30.0-gke.1930	Il job upgrade-health-check rimane nello stato attivo a causa dell'immagine pause:3.9 mancante Durante un upgrade, il job upgrade-health-check potrebbe rimanere in stato attivo a causa dell'immagine pause:3.9 mancante. Questo problema non influisce sulla riuscita dell'upgrade. Soluzione temporanea: Elimina manualmente il job upgrade-health-check con il seguente comando: kubectl delete job upgrade-health-check-JOB_ID --cascade=true
Sistema operativo	1,28, 1,29, 1,30	Download lenti all'interno dei container su RHEL 9.2 I download di artefatti con dimensioni che superano il limite del cgroup memory.max potrebbero essere estremamente lenti. Questo problema è causato da un bug nel kernel Linux per Red Hat Enterprise Linux (RHEL) 9.2. I kernel con cgroup v2 abilitato sono interessati. Il problema è stato risolto nelle versioni del kernel 5.14.0-284.40.1.el_9.2 e successive. Soluzione temporanea: Per i pod interessati, aumenta le impostazioni del limite di memoria per i relativi container (spec.containers[].resources.limits.memory) in modo che i limiti siano superiori alle dimensioni degli artefatti scaricati.
Upgrade	Da 1.28 a 1.29.200	L'upgrade del cluster non riesce a causa di un conflitto nella definizione di risorsa personalizzata networks.networking.gke.io Durante l'upgrade di un cluster bare metal, l'upgrade potrebbe non riuscire con un messaggio di errore che indica che si è verificato un conflitto nella definizione della risorsa personalizzata networks.networking.gke.io. Nello specifico, l'errore indica che v1alpha1 non è presente in spec.versions. Questo problema si verifica perché la versione v1alpha1 della definizione di risorsa personalizzata non è stata migrata a v1 durante il processo di upgrade. Soluzione temporanea: Applica la patch ai cluster interessati con i seguenti comandi: kubectl patch customresourcedefinitions/networkinterfaces.networking.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/networks.networking.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Installazione, upgrade e aggiornamenti	Da 1.28.0 a 1.28.600 e da 1.29.0 a 1.29.200	Errori di controllo preflight della macchina per le impostazioni check_inotify_max_user_instances e check_inotify_max_user_watches Durante l'installazione o l'upgrade del cluster, i controlli preflight della macchina relativi alle impostazioni del kernel fs.inotify potrebbero non riuscire. Se sei interessato da questo problema, il log del controllo preliminare del computer contiene un errore come il seguente: Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value. Questo problema si verifica perché i valori fs.inotify max_user_instances e max_user_watches vengono letti in modo errato dagli host del control plane e di bootstrap, anziché dalle macchine nodo previste. Soluzione alternativa: Per risolvere questo problema, regola fs.inotify.max_user_instances e fs.inotify.max_user_watches sui valori consigliati su tutti i control plane e le macchine bootstrap: echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf sudo sysctl -p Al termine dell'operazione di installazione o upgrade, questi valori possono essere ripristinati, se necessario.
Upgrade	1.28.0 - 1.28.500	L'upgrade del cluster non riesce a causa di un errore di controllo dell'accessibilità di Google Cloud Quando utilizzi bmctl per eseguire l'upgrade di un cluster, l'upgrade potrebbe non riuscire con un errore GCP reachability check failed anche se l'URL di destinazione è raggiungibile dalla workstation di amministrazione. Questo problema è causato da un bug nelle versioni 1.28.0-1.28.500 di bmctl. Soluzione temporanea: Prima di eseguire il comando bmctl upgrade, imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che punti a un file delle chiavi per l'account di servizio valido: export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG L'impostazione delle credenziali predefinite dell'applicazione (ADC) in questo modo garantisce che bmctl disponga delle credenziali necessarie per accedere all'endpoint dell'API Google.
Configurazione, installazione, upgrade e aggiornamenti, networking, sicurezza	1.15, 1.16, 1.28, 1.29	L'installazione e l'upgrade del cluster non riescono quando è richiesto ipam-controller-manager L'installazione e l'upgrade del cluster non vanno a buon fine quando è richiesto ipam-controller-manager e il cluster è in esecuzione su Red Hat Enterprise Linux (RHEL) 8.9 o versioni successive (a seconda delle modifiche upstream di RHEL) con SELinux in esecuzione in modalità di applicazione. Ciò si applica in modo specifico quando la versione di container-selinux è superiore a 2.225.0. Il cluster richiede ipam-controller-manager in una delle seguenti situazioni: Il cluster è configurato per il networking a doppio stack IPv4/IPv6 Il cluster è configurato con clusterNetwork.flatIPv4 impostato su true Il cluster è configurato con l'annotazione preview.baremetal.cluster.gke.io/multi-networking: enable L'installazione e l'upgrade del cluster non vanno a buon fine quando è installato ipam-controller-manager. Soluzione temporanea Imposta il contesto predefinito per la directory /etc/kubernetes su ogni nodo del control plane digitando etc_t: semanage fcontext /etc/kubernetes --add -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t restorecon -R /etc/kubernetes Questi comandi ripristinano la modifica di container-selinux nella directory /etc/kubernetes. Dopo l'upgrade del cluster a una versione con la correzione, annulla la modifica del contesto del file precedente su ogni nodo del piano di controllo: semanage fcontext /etc/kubernetes --delete -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t restorecon -R /etc/kubernetes
Upgrade	1.28.0 - 1.28.500	L'upgrade del cluster non riesce a causa di un errore di controllo dell'accessibilità di Google Cloud Quando utilizzi bmctl per eseguire l'upgrade di un cluster, l'upgrade potrebbe non riuscire con un errore GCP reachability check failed anche se l'URL di destinazione è raggiungibile dalla workstation di amministrazione. Questo problema è causato da un bug nelle versioni 1.28.0-1.28.500 di bmctl. Soluzione temporanea: Prima di eseguire il comando bmctl upgrade, imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che punti a un file delle chiavi per l'account di servizio valido: export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG L'impostazione delle credenziali predefinite dell'applicazione (ADC) in questo modo garantisce che bmctl disponga delle credenziali necessarie per accedere all'endpoint dell'API Google.
Installazione	1,29	Problema di autorizzazione binaria per il cluster con un pool di nodi del bilanciatore del carico separato L'installazione di un cluster con un pool di nodi del bilanciatore del carico separato potrebbe non riuscire se abiliti il criterio di autorizzazione binaria durante la creazione del cluster. Questo problema si verifica perché la creazione del pod GKE Identity Service e di altri pod critici è bloccata dal webhook Autorizzazione binaria. Per verificare se il problema ti riguarda, completa i seguenti passaggi: Identifica i pod che non funzionano: kubectl get pods \ -n anthos-identity-service \ --kubeconfig CLUSTER_KUBECONFIG Descrivi il pod in errore. Cerca il seguente messaggio nell'output: admission webhook "binaryauthorization.googleapis.com" denied the request: failed to post request to endpoint: Post "https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview": oauth2/google: status code 400: {"error":"invalid_target","error_description":"The target service indicated by the \"audience\" parameters is invalid. This might either be because the pool or provider is disabled or deleted or because it doesn't exist."} Se visualizzi il messaggio precedente, il tuo cluster presenta questo problema. Soluzione temporanea: Per risolvere il problema, completa i seguenti passaggi: Annulla l'operazione di creazione del cluster. Rimuovi il blocco spec.binaryAuthorization dal file di configurazione del cluster. Crea il cluster con Autorizzazione binaria disabilitata. Al termine dell'installazione, abilita il criterio di autorizzazione binaria per un cluster esistente.
Configurazione, installazione	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30	Punti di montaggio con SELinux abilitato che causano problemi Se hai abilitato SELinux e monti i file system nelle directory correlate a Kubernetes, potresti riscontrare problemi come la creazione del cluster non riuscita, file illeggibili o problemi di autorizzazione. Per determinare se il problema ti riguarda, esegui questo comando: ls -Z /var/lib/containerd . Se vedi system_u:object_r:unlabeled_t:s0 dove ti aspetteresti di vedere un'altra etichetta, ad esempio system_u:object_r:container_var_lib_t:s0, il problema ti riguarda. Soluzione temporanea: Se di recente hai montato file system in directory, assicurati che queste directory siano aggiornate con la configurazione SELinux. Devi anche eseguire i seguenti comandi su ogni macchina prima di eseguire bmctl create cluster: restorecon -R -v /var restorecon -R -v /etc Questa correzione una tantum verrà mantenuta dopo il riavvio, ma è necessaria ogni volta che viene aggiunto un nuovo nodo con gli stessi punti di montaggio. Per saperne di più, consulta Montaggio di file system nella documentazione di Red Hat.
Reimpostazione/eliminazione	1.29.0	Il ripristino del cluster utente non riesce durante il tentativo di eliminazione dello spazio dei nomi Quando esegui bmctl reset cluster -c ${USER_CLUSTER}, dopo che tutti i job correlati sono stati completati, il comando non riesce a eliminare lo spazio dei nomi del cluster utente. Lo spazio dei nomi del cluster utente è bloccato nello stato Terminating. Alla fine, il ripristino del cluster scade e restituisce un errore. Soluzione temporanea: Per rimuovere lo spazio dei nomi e completare il ripristino del cluster utente, segui questi passaggi: 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. Nel cluster di amministrazione, forza la rimozione del finalizer 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 il ripristino del cluster è completato.
Configurazione, installazione, sicurezza	Da 1.16.0 a 1.16.7 e da 1.28.0 a 1.28.400	Il deployment di Autorizzazione binaria non ha un nodeSelector Se hai attivato Binary Authorization per Google Distributed Cloud e utilizzi una versione compresa tra 1.16.0 e 1.16.7 o tra 1.28.0 e 1.28.400, potresti riscontrare un problema con la pianificazione dei pod per la funzionalità. In queste versioni, il deployment di Autorizzazione binaria non include un nodeSelector, pertanto i pod per la funzionalità possono essere pianificati sui nodi worker anziché sui nodi del piano di controllo. Questo comportamento non causa errori, ma non è intenzionale. Soluzione temporanea: Per tutti i cluster interessati, completa i seguenti passaggi: Apri il file di deployment di Autorizzazione binaria: kubectl edit -n binauthz-system deployment binauthz-module-deployment Aggiungi il seguente nodeSelector nel blocco spec.template.spec: nodeSelector: node-role.kubernetes.io/control-plane: "" Salva le modifiche. Una volta salvata la modifica, i pod vengono nuovamente implementati solo nei nodi del control plane. 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 alla versione 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 causare l'inserimento del pod di deployment del controller del ciclo di vita in uno stato di errore durante l'upgrade. In questo caso, i log del pod di deployment del controller del ciclo di vita contengono 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 temporanea: 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 seguenti comandi 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 vengono taggati con un ID progetto diverso in resource.labels.project_id in Esplora log. Ciò può verificarsi 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 account di servizio del progetto PROJECT_TWO. In questi casi, tutti i log vengono indirizzati a PROJECT_ONE, ma resource.labels.project_id è etichettato come PROJECT_TWO. Soluzione temporanea: Utilizza una delle seguenti opzioni per risolvere il problema: Utilizza un account di servizio dello stesso progetto di destinazione. Modifica project_id nel file JSON della chiave del account di servizio con il progetto corrente. Modifica project_id direttamente nel filtro dei log da Esplora log.
Networking	1.29, 1.30	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 di bilanciamento del carico possono peggiorare man mano che il numero totale di servizi di tipo LoadBalancer si avvicina a 2000. Man mano che le prestazioni peggiorano, i servizi appena creati impiegano molto tempo per connettersi o non possono essere connessi da un client. I servizi esistenti continuano a funzionare, ma non gestiscono in modo efficace le modalità di errore, ad esempio la perdita di un nodo del bilanciatore del carico. Questi problemi del servizio si verificano quando il deployment di ang-controller-manager viene terminato a causa dell'esaurimento della memoria. Se il tuo 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 uno stato CrashLoopBackOff. La risposta quando elenca le implementazioni 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 temporanea Come soluzione alternativa, puoi aumentare il limite di risorse di memoria del deployment ang-controller-manager di 100 MiB e rimuovere il limite di CPU: kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG Dopo aver apportato le modifiche e chiuso l'editor, dovresti visualizzare 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 Artifact Registry gcr.io possono bloccare le operazioni del cluster Le operazioni su più cluster per i cluster di amministrazione creano un cluster di bootstrap. Prima di creare un cluster di bootstrap, bmctl esegue un controllo di raggiungibilità Google Cloud dalla workstation di amministrazione. Questo controllo potrebbe non riuscire a causa di problemi di connettività con l'endpoint Artifact 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 temporanea Per risolvere il problema, riprova l'operazione con il flag --ignore-validation-errors.
Networking	1.15, 1.16	GKE Dataplane V2 incompatibile con alcuni driver di archiviazione I cluster bare metal utilizzano GKE Dataplane V2, che non è compatibile con alcuni provider di spazio di archiviazione. Potresti riscontrare problemi con i pod o i volumi NFS bloccati. Ciò è particolarmente probabile se hai carichi di lavoro che utilizzano volumi ReadWriteMany supportati da driver di archiviazione sensibili a questo problema: Robin.io Portworx (volumi di servizio sharedv4) csi-nfs Questo elenco non è esaustivo. Soluzione temporanea È disponibile una correzione per questo problema 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 che esiste sullo stesso nodo di kube-state-metrics non ha più memoria (OOM). Ciò può verificarsi in cluster con più di 50 nodi o con molti oggetti Kubernetes. Soluzione temporanea Per risolvere il problema, aggiorna la definizione della risorsa personalizzata stackdriver per utilizzare il feature gate ksmNodePodMetricsOnly. Questo gate della funzionalità assicura che vengano esposte solo un numero limitato di metriche critiche. Per utilizzare questa soluzione alternativa, completa i seguenti passaggi: Controlla la definizione di risorsa personalizzata stackdriver per i feature gate disponibili: kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly Aggiorna la definizione di risorsa personalizzata stackdriver per abilitare ksmNodePodMetricsOnly: kind:stackdriver spec: featureGates: ksmNodePodMetricsOnly: true
Installazione	1.28.0-1.28.200	Il controllo preflight non riesce su RHEL 9.2 a causa della mancanza di iptables Quando installi 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 Google Distributed Cloud versione 1.28. Soluzione temporanea 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. Ciò accade perché MetalLB utilizza una coda con limitazione di frequenza che, in caso di scalabilità elevata, può richiedere un po' di tempo per raggiungere il servizio che deve eseguire il failover. Soluzione temporanea 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 il failover più rapido del servizio.
Operazione	1.16.0-1.16.6, 1.28.0-1.28.200	Se il proxy è abilitato, le variabili di ambiente devono essere impostate sulla workstation di amministrazione bmctl check cluster può non riuscire a causa di errori del proxy se non hai definito le variabili di ambiente HTTPS_PROXY e NO_PROXY sulla workstation amministrativa. Il comando bmctl segnala un messaggio di errore relativo alla chiamata di alcuni servizi Google, come il seguente esempio: [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 temporanea 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, il file /var/log/apiserver/audit.log sui nodi del control plane ha la proprietà sia del gruppo che dell'utente impostata su root. Questa impostazione della proprietà del file causa errori di upgrade per i nodi del control plane durante l'upgrade di un cluster dalla versione 1.16.x alla versione 1.28.0-gke.435. Questo problema riguarda solo i cluster creati prima della versione 1.11 e in cui Cloud Audit Logs era disattivato. Cloud Audit Logs è abilitato per impostazione predefinita per i cluster con versione 1.9 e successive. Soluzione temporanea Se non riesci a eseguire l'upgrade del cluster alla versione 1.28.100-gke.146, utilizza i seguenti 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 Audit log di Cloud è disattivato, cambia la proprietà di /var/log/apiserver/audit.log in modo che corrisponda a quella della directory principale, /var/log/apiserver.
Networking, upgrade e aggiornamenti	1.28.0-gke.435	MetalLB non assegna indirizzi IP ai servizi VIP Google Distributed Cloud utilizza MetalLB per il bilanciamento del carico in bundle. Nella release 1.28.0-gke.435 di Google Distributed Cloud, MetalLB in bundle viene aggiornato 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 del 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 un IPPool per la selezione, la conversione del nome impedisce a MetalLB di effettuare una selezione del pool e assegnare indirizzi IP. Pertanto, 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 nella versione 1.28.100-gke.146 di Google Distributed Cloud. Soluzione temporanea Se non riesci a eseguire l'upgrade del cluster alla versione 1.28.100-gke.146, utilizza i seguenti passaggi come soluzione alternativa: Recupera il nome convertito di IPAddressPool: kubectl get IPAddressPools -n kube-system 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 è persistente.
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 dei cluster alla versione 1.14.x, alcune risorse della versione precedente non vengono eliminate. Nello specifico, potresti visualizzare 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 i seguenti 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 Google Distributed Cloud versione 1.15.0 e successive.
Installazione	1,14	Creazione del cluster bloccata sul job machine-init Se provi a installare Google Distributed Cloud versione 1.14.x, potresti riscontrare un errore a causa dei job machine-init, simile a 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 temporanea: Rimuovi il membro etcd obsoleto che causa l'errore del job machine-init. Completa i seguenti passaggi su un nodo del control plane funzionante: 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 lo stato unstarted, come mostrato nell'output di esempio seguente: 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 Rimuovi il membro etcd non riuscito: 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 non riuscito. Nell'output dell'esempio precedente, questo ID è bd1949bcb70e2cb5. L'output di esempio seguente mostra che il membro è stato rimosso: Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
Networking	1.28.0	Cilium-operator Node list e watch mancanti In Cilium 1.13, le autorizzazioni ClusterRole cilium-operator non sono corrette. Mancano le autorizzazioni list e watch del nodo. Il cilium-operator non riesce ad avviare i garbage collector, il che comporta i seguenti problemi: Perdita di risorse Cilium. Le identità obsolete non vengono rimosse dalle mappe delle policy BFP. Le mappe delle policy potrebbero raggiungere il limite di 16.000. Non è possibile aggiungere nuove voci. Applicazione errata di NetworkPolicy. Le identità potrebbero raggiungere il limite di 64.000. Non è possibile creare nuovi pod. Un operatore a cui mancano le autorizzazioni del nodo 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 delle policy, come nel seguente esempio: 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 temporanea: Rimuovi le identità Cilium, quindi aggiungi le autorizzazioni ClusterRole mancanti all'operatore: Rimuovi gli oggetti CiliumIdentity esistenti: kubectl delete ciliumid –-all Modifica l'oggetto ClusterRole cilium-operator: kubectl edit clusterrole cilium-operator Aggiungi una sezione per nodes che includa le autorizzazioni mancanti, come mostrato nell'esempio seguente: - apiGroups: - "" resources: - nodes verbs: - get - list - watch Salva e chiudi l'editor. L'operatore rileva dinamicamente 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	Problema temporaneo riscontrato durante il controllo preflight Una delle attività di controllo di integrità di kubeadm eseguite durante il controllo preliminare dell'upgrade potrebbe non riuscire e restituire 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 osservi questo errore quando esegui il controllo preliminare utilizzando il comando bmctl preflightcheck, nulla viene bloccato da questo errore. Puoi eseguire di nuovo il controllo preflight per ottenere informazioni preflight accurate. Soluzione temporanea: Esegui di nuovo il comando di upgrade o, se si è verificato durante bmctl preflightcheck, esegui di nuovo 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à periodico della rete non riesce quando un nodo viene sostituito o rimosso Questo problema interessa i cluster che eseguono controlli di integrità di rete periodici dopo la sostituzione o la rimozione di un nodo. Se il tuo cluster è sottoposto a controlli di integrità periodici, il controllo di integrità di rete periodico non riesce dopo la sostituzione o la rimozione di un nodo, perché ConfigMap dell'inventario di rete non viene aggiornato una volta creato. Soluzione temporanea: La soluzione alternativa consigliata è eliminare ConfigMap dell'inventario e il controllo di integrità di rete periodico. L'operatore del 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 i seguenti 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	Network Gateway for GDC non può applicare la 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, Network Gateway for GDC considera il punto come un percorso nella directory quando esegue sysctl per apportare modifiche. Quando Network Gateway for GDC controlla se il rilevamento di indirizzi duplicati (DAD) è abilitato, il controllo potrebbe non riuscire e quindi non verrà riconciliato. Il comportamento è diverso tra le versioni del cluster: 1.14 e 1.15: questo errore si verifica solo quando utilizzi indirizzi IP mobili IPv6. Se non utilizzi indirizzi IP mobili IPv6, non noterai questo problema quando i nomi dei dispositivi contengono un punto. 1.16.0 - 1.16.2: questo errore si verifica sempre quando i nomi dei dispositivi contengono un punto. Soluzione temporanea: Esegui l'upgrade del cluster alla versione 1.16.3 o successive. Come soluzione alternativa finché non puoi eseguire l'upgrade dei cluster, rimuovi il punto (.) dal nome del dispositivo.
Upgrade e aggiornamenti, networking, sicurezza	1.16.0	Gli upgrade alla versione 1.16.0 non riescono quando seccomp è disattivato Se seccomp è disattivato per il tuo cluster (spec.clusterSecurity.enableSeccomp impostato su false), gli upgrade alla versione 1.16.0 non vanno a buon fine. Google Distributed Cloud versione 1.16 utilizza Kubernetes versione 1.27. In Kubernetes versione 1.27.0 e successive, la funzionalità per l'impostazione dei profili seccomp è GA e non utilizza più un gate di funzionalità. Questa modifica di Kubernetes causa l'esito negativo degli upgrade alla versione 1.16.0 quando seccomp è disattivato nella configurazione del cluster. Questo problema è stato risolto nei cluster versione 1.16.1 e successive. 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 di containerd potrebbero danneggiarsi dopo il riavvio quando /var/lib/containerd è montato Se hai montato facoltativamente /var/lib/containerd, i metadati di containerd potrebbero danneggiarsi dopo un riavvio. Metadati danneggiati potrebbero causare errori nei pod, inclusi quelli critici per il sistema. Per verificare se questo problema ti riguarda, controlla se è definita una posizione di montaggio facoltativa in /etc/fstab per /var/lib/containerd/ e se nofail è presente nelle opzioni di montaggio. Soluzione temporanea: Rimuovi l'opzione di montaggio nofail in /etc/fstab o esegui l'upgrade del cluster alla versione 1.15.6 o successiva.
Operazione	1.13, 1.14, 1.15, 1.16, 1.28	Pulisci i pod obsoleti nel cluster Potresti visualizzare i pod gestiti da un deployment (ReplicaSet) in uno stato Failed e con lo stato TaintToleration. Questi pod non utilizzano le risorse del cluster, ma devono essere eliminati. Puoi utilizzare il seguente comando kubectl per elencare i pod che puoi pulire: kubectl get pods –A | grep TaintToleration L'output di esempio seguente mostra un pod con lo stato TaintToleration: kube-system stackdriver-metadata-agent-[...] 0/1 TaintToleration 0 Soluzione temporanea: Per ogni pod con i sintomi descritti, controlla il ReplicaSet a cui appartiene il pod. Se ReplicaSet è soddisfatto, puoi eliminare i pod: Recupera il ReplicaSet che gestisce il pod e trova il valore di ownerRef.Kind: kubectl get pod POD_NAME -n NAMESPACE -o yaml Recupera il ReplicaSet e verifica che status.replicas sia uguale a spec.replicas: kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml Se i nomi corrispondono, elimina il pod: kubectl delete pod POD_NAME -n NAMESPACE.
Upgrade	1.16.0	etcd-events può bloccarsi durante l'upgrade alla versione 1.16.0 Quando esegui l'upgrade di un cluster esistente alla versione 1.16.0, gli errori dei pod correlati a etcd-events possono bloccare l'operazione. Nello specifico, il job upgrade-node non riesce per il passaggio TASK [etcd_events_install : Run etcdevents]. Se il problema ti riguarda, visualizzi errori del pod come i seguenti: L'avvio del pod kube-apiserver non riesce con il seguente errore: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused" L'avvio del pod etcd-events non riesce e viene visualizzato il seguente errore: Error: error syncing endpoints with etcd: context deadline exceeded Soluzione temporanea: Se non riesci a eseguire l'upgrade del cluster a una versione con la correzione, utilizza la seguente soluzione alternativa temporanea per risolvere gli errori: Utilizza SSH per accedere al nodo del control plane con gli errori segnalati. Modifica il file manifest etcd-events, /etc/kubernetes/manifests/etcd-events.yaml, e rimuovi il flag initial-cluster-state=existing. Applica il manifest. 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. Google Distributed Cloud utilizza sempre Random. Questo problema si verifica perché il modello CoreDNS non è stato aggiornato, il che causa l'ignoramento di orderPolicy. Soluzione temporanea: Aggiorna il modello CoreDNS e applica la correzione. Questa correzione persiste fino a un upgrade. 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, Operation	1.10, 1.11, 1.12, 1.13, 1.14	Gateway di rete per i componenti GDC espulsi o in attesa a causa della classe di priorità mancante I pod gateway di rete in kube-system potrebbero mostrare lo stato Pending o Evicted, come mostrato nel seguente output di esempio compresso: $ kubectl -n kube-system get pods | grep ang-node ang-node-bjkkc 2/2 Running 0 5d2h ang-node-mw8cq 0/2 Evicted 0 6m5s ang-node-zsmq7 0/2 Pending 0 7h Questi errori indicano eventi di espulsione o l'impossibilità di pianificare i pod a causa delle risorse del nodo. Poiché il gateway di rete per i pod GDC non ha PriorityClass, ha la stessa priorità predefinita degli altri workload. Quando i nodi sono vincolati dalle risorse, i pod del gateway di rete potrebbero essere eliminati. Questo comportamento è particolarmente dannoso per il DaemonSet ang-node, in quanto questi pod devono essere pianificati su un nodo specifico e non possono essere migrati. Soluzione temporanea: Esegui l'upgrade alla versione 1.15 o successive. Come soluzione a breve termine, puoi assegnare manualmente un PriorityClass al gateway di rete per i componenti GDC. Il controller Google Distributed Cloud sovrascrive queste modifiche manuali durante una procedura di riconciliazione, ad esempio durante un upgrade del cluster. Assegna system-cluster-critical PriorityClass ai deployment dei controller dei cluster ang-controller-manager e autoscaler. Assegna la PriorityClass system-node-critical al DaemonSet del nodo ang-daemon.
Installazione, upgrade e aggiornamenti	1.15.0, 1.15.1, 1.15.2	La creazione e gli upgrade dei cluster non riescono a causa della lunghezza del nome del cluster La creazione di cluster 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 se il nome del cluster è più lungo 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, Google Distributed Cloud crea una risorsa di controllo di integrità'integrità con un nome che include il nome e la versione del cluster: Per i cluster versione 1.15.0, il nome della risorsa di 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 il limite 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 non va a buon fine. Per verificare se il problema ti riguarda, utilizza kubectl describe per controllare la risorsa non funzionante: 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 un 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 temporanea Per sbloccare la creazione o l'upgrade del cluster, puoi ignorare il controllo di integrità. Utilizza il seguente comando per applicare la patch alla risorsa personalizzata di controllo dell'integrità con lo stato di superamento: (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 delle versioni 1.14.0 e 1.14.1 con funzionalità in anteprima non possono essere aggiornati alla versione 1.15.x Se i cluster delle versioni 1.14.0 e 1.14.1 hanno una funzionalità in anteprima abilitata, l'upgrade alla versione 1.15.x viene bloccato. Ciò vale per le funzionalità di anteprima come la possibilità di creare un cluster senza kube-proxy, che viene abilitato con la seguente annotazione nel file di configurazione del cluster: preview.baremetal.cluster.gke.io/kube-proxy-free: "enable" Se riscontri questo problema, durante l'upgrade del cluster ricevi un errore simile al 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 nei cluster versione 1.14.2 e successive. Soluzione temporanea: 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 l'upgrade direttamente 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 Network Gateway per GDC non consente di creare nuove risorse personalizzate NetworkGatewayGroup che contengono indirizzi IP in spec.floatingIPs già utilizzati in risorse personalizzate NetworkGatewayGroup esistenti. Questa regola viene applicata da un webhook nei 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 del 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 rete avanzate, come il gateway NAT in uscita, non mette in guardia contro gli indirizzi IP duplicati. Inizialmente, il riconciliatore riconosceva solo la risorsa NetworkGatewayGroup denominata default. Network Gateway for GDC ora riconosce tutte le risorse personalizzate NetworkGatewayGroup nello spazio dei nomi di sistema. Le risorse personalizzate NetworkGatewayGroup esistenti vengono rispettate così come sono. Soluzione temporanea: Gli errori si verificano solo per la creazione di una nuova risorsa personalizzata NetworkGatewayGroup. Per risolvere l'errore: Utilizza il seguente comando per elencare le risorse personalizzate NetworkGatewayGroups: kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system -o yaml 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 Per applicare le modifiche, chiudi e salva le risorse personalizzate modificate.
VM Runtime su GDC	1.13.7	Le VM potrebbero non avviarsi sui cluster 1.13.7 che utilizzano un registro privato Quando abiliti VM Runtime su GDC su un cluster di versione 1.13.7 nuovo o aggiornato che utilizza un registro privato, le VM che si connettono alla rete dei 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 generano errori di pull delle immagini. Ad esempio, se la VM utilizza la rete dei nodi, alcuni pod potrebbero segnalare errori di pull dell'immagine come il seguente: macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m Questo problema è stato risolto nei cluster versione 1.14.0 e successive. Soluzione temporanea Se non riesci a eseguire immediatamente l'upgrade dei cluster, puoi estrarre le immagini manualmente. I seguenti comandi recuperano l'immagine del plug-in CNI macvtap per la tua VM e la inviano 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 in locale.
Installazione	1.11, 1.12	Durante la creazione del cluster nel cluster kind, l'avvio del pod gke-metric-agent non riesce Durante la creazione del cluster nel cluster kind, il pod gke-metrics-agent non viene avviato 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 di containerd del cluster di bootstrap, vedrai la seguente voce: 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 verrà visualizzato il seguente errore "failing to pull": gcr.io/gke-on-prem-staging/gke-metrics-agent Soluzione temporanea Nonostante gli errori, il processo di creazione del cluster non è bloccato perché lo scopo del pod gke-metrics-agent nel cluster kind è facilitare il tasso di successo della creazione del cluster e per il monitoraggio e il monitoraggio interni. Pertanto, puoi ignorare questo errore. Soluzione temporanea Nonostante gli errori, il processo di creazione del cluster non è bloccato perché lo scopo del pod gke-metrics-agent nel cluster kind è facilitare il tasso di successo della creazione del cluster e per 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 causa l'arresto anomalo del nodo LoadBalancer su CentOS o RHEL Quando accedi a un servizio a doppio stack (un servizio con endpoint IPv4 e IPv6) e utilizzi l'endpoint IPv6, il nodo LoadBalancer che gestisce il servizio potrebbe arrestarsi in modo anomalo. Questo problema interessa i clienti che utilizzano servizi dual-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 temporanea: Aggiorna il nodo LoadBalancer alla versione del kernel kernel-4.18.0-372.46.1.el8_6 o successive. 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 intermittenti di handshake TLS o di reimpostazione della connessione. Questo problema è risolto per le versioni 1.14.1 e successive del cluster. Per verificare se questo problema ti riguarda, esamina le regole di inoltro iptables sui nodi in cui è in esecuzione il pod di backend per il servizio interessato: sudo iptables -L FORWARD Se visualizzi la regola KUBE-FORWARD prima della regola CILIUM_FORWARD in iptables, potresti essere interessato da questo problema. L'output di esempio seguente mostra un nodo in cui esiste 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 temporanea: 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. L'output di esempio seguente 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 le informazioni originali su autorizzazione e proprietario La funzionalità di anteprima del cluster 1.9.x che utilizza bmctl 1.9.x non conserva le informazioni originali su proprietario e autorizzazione. Per verificare se sei interessato da questa funzionalità, estrai il file di backup utilizzando il seguente comando: tar -xzvf BACKUP_FILE Soluzione temporanea 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 il backup/ripristino.
Esegue l'upgrade e crea	1.14.2	clientconfig-operator bloccato nello stato In attesa con CreateContainerConfigError Se hai eseguito l'upgrade a un cluster versione 1.14.2 o ne hai creato uno con una configurazione OIDC/LDAP, potresti visualizzare il pod clientconfig-operator bloccato in stato in attesa. Con questo problema, ci sono due pod clientconfig-operator, uno in esecuzione e l'altro in stato in attesa. Questo problema riguarda solo i cluster della versione 1.14.2. Le versioni precedenti del 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, incluse la 1.15.0 e versioni successive. Soluzione temporanea: Come soluzione alternativa, puoi applicare una patch al deployment di clientconfig-operator per aggiungere un ulteriore contesto di sicurezza e assicurarti che il deployment sia pronto. Utilizza il seguente 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 potrebbe smettere di rispondere e non riuscire a essere eseguito con il seguente errore: x509: certificate signed by unknown authority. Se il problema ti riguarda, il comando bmctl potrebbe restituire il seguente messaggio prima di non rispondere più: Signing CA completed in 3/0 control-plane nodes In questo caso, il comando non va a buon fine. Il log rotate certificate-authority per un cluster con tre control plane 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 temporanea Se hai bisogno di ulteriore assistenza, contatta l'Assistenza Google.
Installazione, networking	1.11, 1.12, 1.13, 1.14.0-1.14.1	ipam-controller-manager crashloop in cluster dual-stack Quando esegui il deployment di un cluster a doppio stack (un cluster con indirizzi sia IPv4 che IPv6), i pod ipam-controller-manager potrebbero andare in crash loop. Questo comportamento fa sì che i nodi alternino gli stati Ready e NotReady e potrebbe causare l'esito negativo dell'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 non funzionano con errori CrashLoopBackOff: kubectl -n kube-system get pods | grep ipam-controller-manager Il seguente output di esempio mostra i pod nello 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 Visualizza i dettagli del nodo nello 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 riportato di seguito: PodCIDRs: In un cluster integro, a tutti i nodi devono essere assegnati PodCIDR dual-stack, come mostrato nell'output di esempio seguente: PodCIDRs: 192.168.6.0/24,222:333:444:555:5:4:7:0/120 Soluzione temporanea: 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	etcd watch starvation I cluster che eseguono etcd versione 3.4.13 o precedenti potrebbero subire watch starvation e watch delle risorse non operativi, il che può portare ai seguenti problemi: La pianificazione dei pod viene interrotta I nodi non possono registrarsi kubelet non osserva le modifiche ai pod Questi problemi possono rendere il cluster non funzionante. Questo problema è stato risolto in Google Distributed Cloud versione 1.12.9, 1.13.6, 1.14.3 e nelle release successive. Queste versioni più recenti utilizzano etcd versione 3.4.21. Tutte le versioni precedenti di Google Distributed Cloud sono interessate da questo problema. Soluzione temporanea Se non puoi eseguire l'upgrade immediatamente, puoi mitigare il rischio di errore del cluster riducendo il numero di nodi nel cluster. Rimuovi nodi finché la metrica etcd_network_client_grpc_sent_bytes_total non è inferiore a 300 MBps. Per visualizzare questa metrica in Metrics Explorer: Vai a Metrics Explorer nella console Google Cloud : Vai a Esplora metriche Seleziona la scheda Configurazione. Espandi Seleziona una metrica, inserisci Kubernetes Container nella barra dei filtri e poi utilizza i sottomenu per selezionare la metrica: Nel menu Risorse attive, seleziona Container Kubernetes. Nel menu Categorie di metriche attive, seleziona Anthos. Nel menu Metriche attive, seleziona etcd_network_client_grpc_sent_bytes_total. Fai clic su Applica.
Networking	1.11.6, 1.12.3	Stato "Non riuscito " della modalità vfio-pci dell'operatore SR-IOV L'oggetto SriovNetworkNodeState's syncStatus può segnalare il valore "Failed" (Errore) 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 temporanea: Se lo stato dell'oggetto SriovNetworkNodeState è "Failed" (Errore), esegui l'upgrade del cluster alla versione 1.11.7 o successiva oppure 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 Ready di alcuni nodi di lavoro potrebbe essere impostata su false. Nella risorsa Nodo, vedrai un errore accanto alla condizione Ready simile al seguente esempio: 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 temporanea Riavvia il pod anetd del nodo eliminandolo.
Upgrade e aggiornamenti, Sicurezza	1,10	Più rotazioni dei certificati da cert-manager comportano un'incoerenza 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 emessi da cert-manager su un cluster meno recente di 180 giorni o più e non hai mai riavviato anthos-cluster-operator. Se hai eseguito rotazioni manuali dei certificati emessi su un cluster precedente a 90 giorni o più e non hai mai riavviato anthos-cluster-operator.cert-manager Soluzione temporanea Riavvia il pod terminando anthos-cluster-operator.
Upgrade e aggiornamenti	1.14.0	Pod di 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 dei cluster utente potrebbero essere creati uno o più pod di deployment del controller del ciclo di vita obsoleti. Questo problema si verifica per i 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 temporanea: Per rimuovere i pod di deployment del controller del ciclo di vita obsoleti: Elenca le risorse di controllo preliminare: kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A L'output ha il seguente aspetto: 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. 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 seguenti comandi: 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	Stato BGPSession in continua evoluzione a causa dell'elevato numero di route in entrata La rete avanzata di Google Distributed Cloud non riesce a gestire correttamente le sessioni BGP quando i peer esterni annunciano 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 di stato o di un controllo di integrità comporta l'eliminazione della sessione perché è obsoleta. I comportamenti indesiderati nelle sessioni BGP che potresti notare e che indicano un problema includono: Eliminazione e ricreazione continue di bgpsession. bgpsession.status.state non diventa mai Established Itinerari che non vengono pubblicizzati o che vengono pubblicizzati e ritirati ripetutamente. I problemi di bilanciamento del carico BGP potrebbero essere evidenti con i problemi di connettività ai servizi LoadBalancer. Il problema BGP FlatIP potrebbe essere evidente con i problemi di connettività ai pod. Per determinare se i problemi BGP sono causati dai peer remoti che annunciano troppe route, utilizza i seguenti comandi per esaminare gli stati e l'output associati: Utilizza kubectl get bgpsessions sul cluster interessato. L'output mostra bgpsessions con lo stato "Non stabilito" e l'ora dell'ultimo report aumenta continuamente fino a circa 10-12 secondi prima di azzerarsi. L'output di kubectl get bgpsessions mostra 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 obsolete vengono eliminate: kubectl logs ang-controller-manager-POD_NUMBER Sostituisci POD_NUMBER con il pod leader nel tuo cluster. Soluzione temporanea: Riduci o elimina il numero di route pubblicizzate dal peer remoto al cluster con una policy di esportazione. Nelle versioni del cluster 1.14.2 e successive, puoi anche disattivare la funzionalità che elabora le route ricevute utilizzando un AddOnConfiguration. Aggiungi l'argomento --disable-received-routes al contenitore bgpd del daemonset ang-daemon.
Networking	1.14, 1.15, 1.16, 1.28	Timeout dell'applicazione causati da errori di inserimento nella 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 (conntrack) netfilter. Gli errori di inserimento possono verificarsi anche quando la tabella conntrack ha spazio per nuove voci. Gli errori sono causati da modifiche al kernel 5.15 e versioni successive che limitano gli inserimenti di tabelle in base alla lunghezza della catena. Per verificare se il problema ti riguarda, puoi controllare le statistiche del sistema di monitoraggio delle connessioni in-kernel con il seguente comando: sudo conntrack -S La risposta è simile alla seguente: cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0 ... Se un valore chaintoolong nella risposta è un numero diverso da zero, il problema ti riguarda. Soluzione temporanea La mitigazione a breve termine consiste nell'aumentare le dimensioni sia della tabella hash netfiler (nf_conntrack_buckets) sia della tabella di monitoraggio delle connessioni netfilter (nf_conntrack_max). Utilizza i seguenti comandi su ogni nodo del cluster per aumentare le dimensioni delle tabelle: sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE Sostituisci TABLE_SIZE con le nuove dimensioni in byte. Il valore predefinito per la dimensione della tabella è 262144. Ti consigliamo di impostare un valore pari a 65.536 volte il numero di core sul nodo. Ad esempio, se il nodo ha otto core, imposta la dimensione della tabella su 524288.
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.5	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 se l'upgrade non va a buon fine. Un problema con il comando bmctl restore cluster impedisce il ripristino dei backup dei cluster con le versioni identificate. Questo problema è specifico degli upgrade, in cui ripristini un backup di una versione precedente. Se il tuo 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 temporanea: Fino a quando il problema non verrà risolto, ti consigliamo di utilizzare le istruzioni riportate in Eseguire il backup e il ripristino dei cluster per eseguire il backup dei cluster manualmente 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 sull'interfaccia NetworkGatewayGroup non riesce a creare daemon per i nodi che non hanno interfacce IPv4 e IPv6. Di conseguenza, funzionalità come BGP LB e EgressNAT non funzionano. Se controlli i log del pod ang-node non riuscito nello spazio dei nomi kube-system, vengono visualizzati errori simili al seguente esempio 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 alcun indirizzo IPv6 sull'interfaccia ens192. Se al nodo manca un indirizzo IPv4, vengono visualizzati errori ARP simili. NetworkGatewayGroup tenta di stabilire una connessione ARP e una connessione NDP all'indirizzo IP locale rispetto al collegamento. Se l'indirizzo IP non esiste (IPv4 per ARP, IPv6 per NDP), la connessione non va a buon fine e il daemon non continua. Questo problema è stato risolto nella release 1.14.3. Soluzione temporanea: Connettiti al nodo utilizzando SSH e aggiungi un indirizzo IPv4 o IPv6 al link che contiene l'IP del nodo. Nella voce di log dell'esempio precedente, questa interfaccia era ens192: ip address add dev INTERFACE scope link ADDRESS Sostituisci quanto segue: INTERFACE: L'interfaccia per il tuo nodo, ad esempio ens192. ADDRESS: l'indirizzo IP e la subnet mask da applicare all'interfaccia.
Reimpostazione/eliminazione	1.10, 1.11, 1.12, 1.13.0-1.13.2	anthos-cluster-operator crash loop durante la rimozione di un nodo del control plane Quando tenti di rimuovere un nodo del control plane rimuovendo l'indirizzo IP da Cluster.Spec, anthos-cluster-operator entra in uno stato di ciclo di arresto anomalo che blocca qualsiasi altra operazione. Soluzione temporanea: Il problema è stato risolto nelle versioni 1.13.3 e 1.14.0 e successive. Tutte le altre versioni sono interessate. Esegui l'upgrade a una delle versioni corrette Per risolvere il problema, 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 non riesce nei cluster di grandi dimensioni a causa di una mancata corrispondenza dei token Quando installi cluster 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 temporanea: Questo problema è stato risolto in Google Distributed Cloud versione 1.13.4 e successive. Se devi utilizzare una versione interessata, crea prima un cluster con meno di 20 nodi, poi ridimensiona il cluster per aggiungere nodi aggiuntivi al termine dell'installazione.
Logging e monitoraggio	1.10, 1.11, 1.12, 1.13.0	Limite CPU basso per metrics-server nei cluster edge Nei cluster Google Distributed Cloud Edge, i limiti di CPU bassi per metrics-server possono causare riavvii frequenti di metrics-server. La scalabilità automatica orizzontale dei pod (HPA) non funziona perché metrics-server non è integro. Se il limite di CPU di metrics-server è inferiore a 40m, i tuoi cluster potrebbero essere interessati. Per controllare i limiti della CPU metrics-server, esamina uno dei seguenti file: Versioni cluster 1.x-1.12: kubectl get deployment metrics-server -n kube-system \ -o yaml > metrics-server.yaml Cluster versione 1.13 o successive: kubectl get deployment metrics-server -n gke-managed-metrics-server \ -o yaml > metrics-server.yaml Soluzione temporanea: Questo problema è stato risolto nelle versioni 1.13.1 o successive del cluster. Per risolvere il problema, esegui l'upgrade dei cluster. Una soluzione alternativa a breve termine, in attesa dell'upgrade dei cluster, consiste nell'aumentare manualmente i limiti della CPU per metrics-server nel seguente modo: Riduzione della scalabilità metrics-server-operator: kubectl scale deploy metrics-server-operator --replicas=0 Aggiorna la configurazione e aumenta i limiti della CPU: Versioni dei cluster 1.x-1.12: kubectl -n kube-system edit deployment metrics-server Versioni dei cluster 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 [...] 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 utilizzando NodePort non riesce quando il pod di backend si trova sullo stesso nodo del NodePort di destinazione. Questo problema interessa i servizi LoadBalancer quando vengono utilizzati con pod con hostNetwork. Con più backend, può verificarsi un errore di connessione sporadico. Questo problema è causato da un bug nel programma eBPF. Soluzione temporanea: Quando utilizzi un servizio NodePort, non scegliere come target il nodo su cui viene eseguito uno dei pod di backend. Quando utilizzi il servizio LoadBalancer, assicurati che i pod con hostNetwork non vengano eseguiti sui 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 versione 1.12.3 non riescono. Soluzione temporanea: Esegui l'upgrade del cluster di amministrazione alla versione 1.13.1 o del cluster utente alla stessa versione del cluster di amministrazione.
Upgrade e aggiornamenti	1,12	L'upgrade alla versione 1.13.x è bloccato per i cluster di amministrazione con pool di nodi worker I cluster di amministrazione versione 1.13.0 e successive non possono contenere node pool 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 i pool di nodi worker sono la causa 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 temporanea: Prima di eseguire l'upgrade, sposta tutti i pool di nodi worker nei cluster utente. Per istruzioni su come aggiungere e rimuovere i node pool, consulta Gestire i node pool 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 ottenendo prima la risorsa e poi applicando una versione aggiornata: Ottieni la definizione YAML esistente: kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml Attiva le funzionalità o aggiorna la configurazione nel file YAML. Applica di nuovo il file YAML aggiornato: kubectl apply -f stackdriver.yaml L'ultimo passaggio per kubectl apply è quello in cui potresti riscontrare problemi. Soluzione temporanea: Non utilizzare kubectl apply per apportare modifiche alle risorse esistenti. Utilizza invece kubectl edit o kubectl patch come mostrato negli esempi seguenti: Modifica la risorsa personalizzata Stackdriver: kubectl edit stackdriver -n kube-system stackdriver Attiva le funzionalità o aggiorna la configurazione nel file YAML. Salva ed esci dall'editor Approccio alternativo utilizzando kubectl patch: Ottieni la definizione YAML esistente: kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml Attiva le funzionalità o aggiorna la configurazione nel file YAML. Applica di nuovo 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 chunk di backlog danneggiati causano stackdriver-log-forwarder crashloop stackdriver-log-forwarder va in crash se tenta di elaborare un blocco di backlog danneggiato. I seguenti errori di esempio vengono visualizzati nei log del container: [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 ciclo di arresti anomali, non puoi visualizzare i log in Cloud Logging. Soluzione temporanea: Per risolvere questi errori, completa i seguenti passaggi: 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/ è difettoso. Tutti i file *.flb per cui il controllo del formato non è riuscito devono essere rimossi. 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 siano eliminati prima di procedere con il passaggio successivo. Connettiti al nodo utilizzando SSH in cui è in esecuzione stackdriver-log-forwarder. Sul nodo, elimina tutti i file *.flb danneggiati in var/log/fluent-bit-buffers/tail.1/. Se ci sono troppi file danneggiati e vuoi applicare uno script per pulire tutti i chunk del backlog, utilizza i seguenti script: Esegui il deployment di un DaemonSet per pulire tutti i dati non validi 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 Assicurati che DaemonSet abbia pulito tutti i nodi. L'output dei due comandi seguenti deve 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 Elimina il DaemonSet di pulizia: kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup 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ò impedire alle VM esistenti di connettersi a una rete non pod. Sui cluster multi-NIC, il riavvio di Dataplane V2 (anetd) può impedire alle macchine virtuali di connettersi alle reti. Nei log del pod anetd potrebbe essere visualizzato un errore simile al seguente: could not find an allocator to allocate the IP of the multi-nic endpoint Soluzione temporanea: Puoi riavviare la VM come soluzione rapida. Per evitare il ripetersi del problema, 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 di profili Edge A seconda del workload del cluster, gke-metrics-agent potrebbe utilizzare più di 4608 MiB di memoria. Questo problema riguarda solo i cluster di profili Edge di Google Distributed Cloud per bare metal. I cluster di profili predefiniti non sono interessati. Soluzione temporanea: 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 di condizioni di competizione Quando crei cluster utilizzando kubectl, a causa di condizioni di competizione, il controllo preflight potrebbe non terminare mai. Di conseguenza, la creazione del cluster potrebbe non riuscire in alcuni casi. Il riconciliatore del controllo preliminare 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 viene riconciliato una volta completato il SecretForwarder. Tuttavia, in rari casi, i riferimenti del proprietario di SecretForwarder possono perdere il riferimento al controllo preflight, causando il blocco del controllo preflight. Di conseguenza, la creazione del cluster non riesce. Per continuare la riconciliazione per il controllo preflight basato sul controller, elimina il pod cluster-operator o la risorsa preflight-check. Quando elimini la risorsa di controllo preliminare, 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 corretta.
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. Ciò accade quando l'operazione CNI DEL viene interrotta. Puoi verificare le prenotazioni di indirizzi IP non utilizzati dei pod eseguendo il seguente comando: kubectl get ippools -A --kubeconfig KUBECONFIG_PATH Soluzione temporanea: Elimina manualmente gli indirizzi IP (ippools) non utilizzati.
Installazione	1.10, 1.11.0, 1.11.1, 1.11.2	Il rilevatore problemi nodo non funziona nel cluster utente 1.10.4 Node Problem Detector potrebbe non funzionare nei cluster utente versione 1.10.x, quando i cluster di amministrazione versione 1.11.0, 1.11.1 o 1.11.2 gestiscono i cluster utente 1.10.x. Quando il rilevatore problemi nodo non funziona, 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 temporanea Esegui l'upgrade del cluster di amministrazione alla versione 1.11.3 per risolvere il problema.
Operazione	1,14	I nodi del cluster IPv4 in modalità isola 1.14 hanno una maschera CIDR pod di dimensione 24 Nella versione 1.14, l'impostazione maxPodsPerNode non viene presa in considerazione per i cluster in modalità isolata, quindi ai nodi viene assegnata una dimensione della maschera CIDR pod di 24 (256 indirizzi IP).Ciò potrebbe causare l'esaurimento degli indirizzi IP dei pod nel cluster prima del previsto. Ad esempio, se il cluster ha una maschera CIDR pod di 22, a ogni nodo verrà assegnata una maschera CIDR pod di 24 e il cluster potrà supportare solo fino a 4 nodi. Il cluster potrebbe anche riscontrare instabilità della rete in un periodo di elevato churn dei pod quando maxPodsPerNode è impostato su 129 o un valore superiore e non è presente un overhead sufficiente nel CIDR pod per ogni nodo. Questo problema interessa solo i cluster IPv4 in modalità isolata che utilizzano maxPodsPerNode al di fuori dell'intervallo da 65 a 128. Se il tuo cluster è interessato, il pod anetd segnala il seguente errore quando aggiungi un nuovo nodo al cluster e non è disponibile alcun podCIDR: error="required IPv4 PodCIDR not available" Soluzione temporanea Per risolvere il problema, procedi nel seguente modo: Esegui l'upgrade alla versione 1.14.1 o a una versione successiva. Rimuovi i nodi worker e aggiungili di nuovo. Rimuovi i nodi del control plane e aggiungili di nuovo, preferibilmente uno alla volta per evitare tempi di inattività del cluster.
Upgrade e aggiornamenti	1.14.0, 1.14.1	Rollback dell'upgrade del cluster non riuscito Il rollback di un upgrade potrebbe non riuscire per i cluster versione 1.14.0 o 1.14.1. Se esegui l'upgrade di un cluster dalla versione 1.14.0 alla 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 simile al seguente esempio: 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 temporanea: Elimina tutte le risorse healthchecks.baremetal.cluster.gke.io nello spazio dei nomi del cluster e poi esegui di nuovo il comando bmctl restore cluster: Elenca tutte le risorse healthchecks.baremetal.cluster.gke.io: kubectl get healthchecks.baremetal.cluster.gke.io \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Sostituisci quanto segue: CLUSTER_NAMESPACE: lo spazio dei nomi del cluster. ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. 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 di controllo di integrità. Esegui di nuovo 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 tramite i relativi indirizzi IP esterni. Questo problema è stato risolto nella versione 1.12.1. Soluzione temporanea: Nel ConfigMap cilium-config, imposta enable-415 su "true", quindi riavvia i pod anetd.
Upgrade e aggiornamenti	1.13.0, 1.14	Gli upgrade in loco dalla versione 1.13.0 alla 1.14.x non vengono mai completati Quando tenti di eseguire un upgrade in loco dalla versione 1.13.0 alla versione 1.14.x utilizzando bmctl 1.14.0 e il flag --use-bootstrap=false, l'upgrade non viene mai completato. Un errore con l'operatore preflight-check fa sì che il cluster non pianifichi mai i controlli richiesti, il che significa che il controllo preflight non termina mai. Soluzione temporanea: Esegui prima l'upgrade alla versione 1.13.1 prima di eseguire l'upgrade alla versione 1.14.x. Un upgrade in loco dalla versione 1.13.0 alla 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 di cui è stato eseguito l'upgrade alla versione 1.14.0 perdono i taint del master I nodi del control plane richiedono una delle due contaminazioni specifiche per impedire la pianificazione dei pod del carico di lavoro. Quando esegui l'upgrade dei cluster della versione 1.13 alla versione 1.14.0, i nodi del control plane perdono i seguenti taint obbligatori: node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/master:PreferNoSchedule Nota: i cluster autogestiti, come un cluster di tipo autonomo, utilizzano il taint PreferNoSchedule per impostazione predefinita. Questo problema non causa errori di upgrade, ma i pod che non devono essere eseguiti sui nodi del control plane potrebbero iniziare a farlo. Questi pod del workload possono sovraccaricare i nodi del control plane e causare instabilità del cluster. Determinare se sei interessato Per trovare i nodi del control plane, utilizza il seguente comando: kubectl get node -l 'node-role.kubernetes.io/control-plane' \ -o name --kubeconfig KUBECONFIG_PATH Per controllare l'elenco dei taint su un nodo, utilizza il seguente comando: kubectl describe node NODE_NAME \ --kubeconfig KUBECONFIG_PATH Se non è elencata nessuna delle contaminazioni richieste, il tuo dispositivo è interessato. Soluzione temporanea Segui questi passaggi per ogni nodo del control plane del cluster 1.14.0 interessato per ripristinare il corretto funzionamento. Questi passaggi riguardano il taint node-role.kubernetes.io/master:NoSchedule e i pod correlati. Se intendi che i nodi del control plane utilizzino il taint PreferNoSchedule, modifica i passaggi di conseguenza. Visualizzare i passaggi della soluzione alternativa Applica l'intent mancante: kubectl taint nodes NODE_NAME \ node-role.kubernetes.io/master:NoSchedule \ -–kubeconfig KUBECONFIG_PATH Trova i pod senza la tolleranza node-role.kubernetes.io/master:NoSchedule: kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \ -o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \ --kubeconfig KUBECONFIG_PATH | \ grep -v "node-role.kubernetes.io/master" | uniq Elimina i pod che non hanno la tolleranza node-role.kubernetes.io/master:NoSchedule: kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
Operazione, runtime delle VM su GDC	1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31	La creazione della VM non riesce in modo intermittente con errori di caricamento La creazione di una nuova macchina virtuale (VM) con il comando kubectl virt create vm non riesce di rado durante il caricamento dell'immagine. Questo problema si verifica per 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 temporanea Riprova il comando kubectl virt create vm per creare la VM.
Upgrade e aggiornamenti, logging e monitoraggio	1,11	I componenti della raccolta gestita 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 il deployment manuale dei componenti della raccolta gestita nello spazio dei nomi gmp-system dei tuoi cluster 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 definizioni di risorse personalizzate correlate sono gestiti da stackdriver-operator con il campo enableGMPForApplications. Il campo enableGMPForApplications ha come valore predefinito true, quindi se esegui il deployment manuale dei componenti di Managed Service per Prometheus nello spazio dei nomi prima dell'upgrade alla versione 1.12, le risorse vengono eliminate da stackdriver-operator. Soluzione temporanea Per preservare le risorse della raccolta gestite manualmente: Esegui il backup di tutte le risorse personalizzate PodMonitoring esistenti. Esegui l'upgrade del cluster alla versione 1.12 e abilita Managed Service per Prometheus. Esegui nuovamente il deployment delle risorse personalizzate PodMonitoring sul cluster di cui è stato eseguito l'upgrade.
Upgrade e aggiornamenti	1,13	Alcuni cluster versione 1.12 con il runtime dei container Docker non possono eseguire l'upgrade alla versione 1.13 Se un cluster versione 1.12 che utilizza il runtime del container Docker non dispone della seguente annotazione, non può eseguire l'upgrade alla versione 1.13: baremetal.cluster.gke.io/allow-docker-container-runtime: "true" Se il problema ti riguarda, 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. Ciò si verifica più probabilmente con i cluster Docker versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11, poiché questo upgrade non richiede l'annotazione per mantenere il runtime del container Docker. In questo caso, i cluster non hanno l'annotazione durante l'upgrade alla versione 1.13. Tieni presente che a partire dalla versione 1.13, containerd è l'unico runtime container consentito. Soluzione temporanea: Se riscontri questo problema, aggiorna la risorsa cluster con l'annotazione mancante. Puoi aggiungere l'annotazione mentre l'upgrade è in corso o dopo averlo annullato e prima di riprovare.
Installazione	1,11	bmctl esce prima del completamento della creazione del cluster La creazione del cluster potrebbe non riuscire per Google Distributed Cloud versione 1.11.0 (questo problema è stato risolto nella release 1.11.1 di Google Distributed Cloud). In alcuni casi, il comando bmctl create cluster termina in anticipo e scrive errori come i seguenti 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 temporanea L'operazione non riuscita produce artefatti, ma il cluster non è operativo. Se questo problema ti riguarda, segui questi passaggi per pulire gli artefatti e creare un cluster: Visualizzare i passaggi della soluzione alternativa Per eliminare gli artefatti del cluster e reimpostare la macchina del nodo, esegui questo comando: bmctl reset -c USER_CLUSTER_NAME Per avviare l'operazione di creazione del cluster, esegui questo comando: bmctl create cluster -c USER_CLUSTER_NAME \ --keep-bootstrap-cluster Il flag --keep-bootstrap-cluster è importante se questo comando non va a buon fine. Se il comando di creazione del cluster va a buon fine, puoi ignorare i passaggi restanti. In caso contrario, continua. Esegui questo comando per ottenere la versione del cluster di bootstrap: kubectl get cluster USER_CLUSTER_NAME \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig bmctl-workspace/.kindkubeconfig \ -o=jsonpath='{.status.anthosBareMetalVersion} L'output dovrebbe essere 1.11.0. Se l'output non è 1.11.0, attendi un minuto o due e riprova. Per spostare manualmente le risorse dal cluster di bootstrap al cluster di destinazione, esegui questo comando: bmctl move --from-kubeconfig bmctl-workspace/.kindkubeconfig \ --to-kubeconfig \ bmctl-workspace/USER_CLUSTER_NAME/USER_CLUSTER_NAME-kubeconfig \ -n USER_CLUSTER_NAMESPACE Per eliminare il cluster di bootstrap, esegui questo comando: bmctl reset bootstrap
Installazione, runtime delle VM su GDC	1.11, 1.12	I report sull'installazione mostrano un errore di riconciliazione del runtime della 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 temporanea Questo errore è innocuo e puoi ignorarlo.
Installazione	1.10, 1.11, 1.12	La creazione del cluster non riesce quando si utilizzano più NIC, containerd e il proxy HTTPS La creazione del cluster non riesce quando si verifica 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, il valore predefinito per Google Distributed Cloud 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 va a buon fine, questa impostazione viene propagata quando tenti di creare un cluster. Potresti visualizzare questa impostazione proxy come variabile di ambiente HTTPS_PROXY o nella configurazione containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf). Soluzione temporanea Aggiungi i CIDR del servizio (clusterNetwork.services.cidrBlocks) alla variabile di ambiente NO_PROXY su tutte le macchine dei nodi.
Installazione	1.10, 1.11, 1.12	Errore sui sistemi con impostazione umask restrittiva La release 1.10.0 di Google Distributed Cloud ha introdotto una funzionalità del piano di controllo rootless che esegue tutti i componenti del piano di controllo come utente non root. L'esecuzione di tutti i componenti come utente non root potrebbe causare errori di installazione o di upgrade sui sistemi con un'impostazione umask più restrittiva di 0077. Soluzione temporanea 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 l'installazione. In alternativa, puoi modificare le autorizzazioni di directory e file di /etc/kubernetes sulle macchine del control plane per procedere con l'installazione o l'upgrade. Rendi /etc/kubernetes e tutte le relative sottodirectory leggibili a livello globale: chmod o+rx. Rendi tutti i file di proprietà dell'utente root nella directory (in modo ricorsivo) /etc/kubernetes leggibili da tutti (chmod o+r). Escludi i file di chiavi private (.key) da queste modifiche, in quanto sono già stati creati con proprietà e autorizzazioni corrette. Rendi /usr/local/etc/haproxy/haproxy.cfg leggibile in tutto il mondo. Rendi /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml leggibile a livello globale.
Installazione	1.10, 1.11, 1.12, 1.13	Incompatibilità del gruppo di controllo v2 Il gruppo di controllo v2 (cgroup v2) non è supportato nelle versioni 1.13 e precedenti di Google Distributed Cloud. Tuttavia, la versione 1.14 supporta cgroup v2 come funzionalità di anteprima . La presenza di /sys/fs/cgroup/cgroup.controllers indica che il tuo sistema utilizza cgroup v2. Soluzione temporanea Se il tuo 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 del account di servizio Per le installazioni attivate da cluster amministratore o ibridi (in altre parole, cluster non creati con bmctl, come i cluster utente), il controllo preliminare non verifica le credenziali del service account o le autorizzazioni associate. Google Cloud
Installazione	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30	Installazione su vSphere Quando installi 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 correlati all'offload della segmentazione hardware eseguito dal driver vSphere VMXNET3 e non funzionano con il tunnel GENEVE dei cluster bare metal. Soluzione temporanea Esegui il seguente comando su ogni nodo per controllare 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 come le 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 impostare esplicitamente questi flag su off, attiva e disattiva i flag con 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 dopo i riavvii. Configura gli script di avvio in modo da impostare esplicitamente questi flag all'avvio del sistema.
Upgrade e aggiornamenti	1,10	bmctl non può creare, aggiornare o reimpostare cluster utente di versioni precedenti La CLI bmctl non può creare, aggiornare o reimpostare un cluster utente con una versione secondaria precedente, 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 il cluster di amministrazione è anch'esso alla versione 1.N.X. Se sei interessato da questo problema, dovresti visualizzare log simili a quanto segue quando utilizzi 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 temporanea: 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 dei 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 può non riuscire in più punti, anche durante la seconda fase dei controlli preliminari. Soluzione temporanea Puoi controllare i log di upgrade per determinare se il problema ti riguarda. I log di upgrade si trovano in /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP per impostazione predefinita. Il modulo upgrade-cluster.log potrebbe contenere errori come i seguenti: Failed to upgrade cluster: preflight checks failed: preflight check failed Il log della macchina potrebbe contenere errori come i seguenti (i guasti ripetuti indicano che sei interessato da questo problema): 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 Keepalived devono essere in esecuzione su ogni nodo del control plane prima di tentare di nuovo l'upgrade del cluster alla versione 1.12.1. Utilizza l'interfaccia a riga di comando crictl su ogni 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 Keepalived non sono in esecuzione su un nodo, riavvia kubelet sul nodo: systemctl restart kubelet
Upgrade e aggiornamenti, runtime delle VM su GDC	1.11, 1.12	L'upgrade dei cluster alla versione 1.12.0 o successive non va a buon fine quando VM Runtime su GDC è abilitato Nei cluster della versione 1.12.0, tutte le risorse correlate a VM Runtime su GDC vengono migrate nello spazio dei nomi vm-system per supportare meglio la release GA di VM Runtime su GDC. Se hai abilitato VM Runtime su GDC in un cluster versione 1.11.x o precedente, l'upgrade alla versione 1.12.0 o successive non va a buon fine a meno che tu non disattivi prima VM Runtime su GDC. Quando riscontri questo problema, 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 temporanea Per disabilitare VM Runtime su GDC: Modifica la risorsa personalizzata VMRuntime: kubectl edit vmruntime Imposta enabled su false nella specifica: apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: false ... Salva la risorsa personalizzata nell'editor. Una volta completato l'upgrade del cluster, riattiva VM Runtime su GDC. Per saperne di più, vedi Attivare o disattivare VM Runtime su GDC.
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 la CLI bmctl non risponde. Questo problema può essere causato da una risorsa aggiornata in modo errato. Per determinare se il 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 temporanea Se trovi questi errori nei log, completa i seguenti passaggi: Utilizza kubectl edit per rimuovere l'annotazione kubectl.kubernetes.io/last-applied-configuration dalla risorsa contenuta nel messaggio di log. Salva e applica le modifiche alla risorsa. 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 Network Gateway per GDC Gli upgrade dei cluster dalla versione 1.10.x alla 1.11.x non riescono per i cluster che utilizzano gateway NAT in uscita o bilanciamento del carico in bundle con BGP. Entrambe 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 i log anthos-cluster-operator mostrano errori come i seguenti: apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable... Soluzione temporanea Attenzione:la seguente soluzione alternativa elimina i manifest e causa un breve tempo di inattività di 30-60 secondi per il bilanciamento del carico in bundle con BGP. Le sessioni BGP vengono interrotte e ristabilite e i servizi LoadBalancer non sono disponibili durante questo periodo. La funzionalità viene ripristinata quando anthos-cluster-operator reinstalla i manifest. Per sbloccare l'upgrade, esegui i seguenti comandi sul cluster che stai aggiornando: 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 del cluster. Soluzione temporanea Per saperne di più, incluse le istruzioni per rimuovere i nodi dalla modalità di manutenzione, consulta Attivazione della modalità di manutenzione dei nodi.
Operazione	1.10, 1.11, 1.12	Nodi non isolati se non utilizzi la procedura della modalità di manutenzione Se esegui cluster versione 1.12.0 (anthosBareMetalVersion: 1.12.0) o precedenti e utilizzi manualmente kubectl cordon su un nodo, Google Distributed Cloud for bare metal potrebbe ripristinare il nodo prima che tu sia pronto nel tentativo di riconciliare lo stato previsto. Soluzione temporanea Per i cluster versione 1.12.0 e precedenti, utilizza la modalità di manutenzione per isolare e svuotare i nodi in modo sicuro. Nella versione 1.12.1 (anthosBareMetalVersion: 1.12.1) o successiva, Google Distributed Cloud per bare metal non rimuove in modo imprevisto il cordone dai nodi quando utilizzi kubectl cordon.
Operazione	1,11	I cluster di amministrazione della versione 11 che utilizzano un mirror del registro non possono gestire i cluster della versione 1.10 Se il cluster di amministrazione utilizza la versione 1.11 e uno specchio del registro, non può gestire i cluster utente che utilizzano una versione secondaria precedente. Questo problema influisce sulle operazioni di ripristino, aggiornamento e upgrade del cluster utente. Per determinare se questo problema ti riguarda, controlla i log per le operazioni del cluster, ad esempio creazione, upgrade o ripristino. Questi log si trovano nella cartella bmctl-workspace/CLUSTER_NAME/ per impostazione predefinita. Se il problema ti riguarda, i log contengono il seguente messaggio di errore: flag provided but not defined: -registry-mirror-host-to-endpoints
Operazione	1.10, 1.11	kubeconfig Secret sovrascritto Il comando bmctl check cluster, se eseguito sui cluster utente, sovrascrive il secret kubeconfig del cluster utente con il kubeconfig del cluster di amministrazione. La sovrascrittura del file causa l'esito negativo delle operazioni standard del cluster, come l'aggiornamento e l'upgrade, per i cluster utente interessati. Questo problema si verifica nelle versioni 1.11.1 e precedenti dei cluster. 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 del cluster. Per impostazione predefinita, i nomi degli spazi dei nomi del cluster 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 nell'output di esempio seguente) è 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 temporanea I seguenti passaggi ripristinano la funzionalità di un cluster utente interessato (USER_CLUSTER_NAME): Individua il file kubeconfig del cluster utente. Google Distributed Cloud per 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. Verifica che kubeconfig sia il kubeconfig corretto del cluster utente: 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 i dettagli sui nodi del cluster utente. Verifica che i nomi delle macchine siano corretti per il tuo cluster. Esegui questo comando per eliminare il file kubeconfig danneggiato nel cluster di amministrazione: kubectl delete secret \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig 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, 1.30	Acquisizione di uno snapshot come utente di accesso non root Se utilizzi containerd come runtime dei container, l'esecuzione dello snapshot come utente non root richiede che /usr/local/bin si trovi nel PATH dell'utente. In caso contrario, l'operazione non riuscirà e verrà visualizzato un errore crictl: command not found. Quando non hai eseguito l'accesso come utente root, sudo viene utilizzato per eseguire i comandi snapshot. Il percorso sudo può essere diverso dal profilo root e non può contenere /usr/local/bin. Soluzione temporanea Aggiorna secure_path in /etc/sudoers in modo da includere /usr/local/bin. In alternativa, crea un link simbolico per crictl in un'altra directory /bin.
Logging e monitoraggio	1,10	stackdriver-log-forwarder presenta [parser:cri] invalid time format log degli avvisi Se il parser dell'interfaccia di runtime del container (CRI) utilizza un'espressione regolare errata per l'analisi del tempo, i log del pod stackdriver-log-forwarder contengono errori e avvisi come i seguenti: [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 temporanea: Visualizzare i passaggi della soluzione alternativa Esegui l'upgrade del cluster alla versione 1.11.0 o successive. Se non riesci ad eseguire immediatamente l'upgrade dei cluster, segui i passaggi riportati di seguito per aggiornare l'espressione regolare di analisi CRI: Per evitare che le modifiche successive vengano ripristinate, fare lo scale down di stackdriver-operator: kubectl --kubeconfig KUBECONFIG \ -n kube-system scale deploy \ stackdriver-operator --replicas=0 Modifica la voce Regex in ConfigMap stackdriver-log-forwarder-config: kubectl --kubeconfig KUBECONFIG \ -n kube-system edit configmap \ stackdriver-log-forwarder-config La risorsa modificata dovrebbe essere simile alla seguente: [PARSER] # https://rubular.com/r/Vn30bO78GlkvyB Name cri Format regex # The timestamp is described in https://www.rfc-editor.org/rfc/rfc3339#section-5.6 Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9] {2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9] {2}:[0-9]{2})) (?<stream>stdout|stderr) (?<logtag>[^ ]*) (?<log>.*)$ Time_Key time Time_Format %Y-%m-%dT%H:%M:%S.%L%z Time_Keep off Riavvia i pod di inoltro dei log: kubectl --kubeconfig KUBECONFIG \ -n kube-system rollout restart daemonset \ stackdriver-log-forwarder
Logging e monitoraggio	1.10, 1.11, 1.12, 1.13, 1.14, 1.15	Fatturazione del monitoraggio imprevista Per le versioni del cluster da 1.10 a 1.15, alcuni clienti hanno riscontrato una fatturazione inaspettatamente elevata per Metrics volume nella pagina Fatturazione. Questo problema ti riguarda solo quando si verificano tutte le seguenti circostanze: Il monitoraggio delle applicazioni è abilitato (enableStackdriverForApplications=true) Managed Service per Prometheus non è abilitato (enableGMPForApplications) I pod dell'applicazione hanno l'annotazione prometheus.io/scrap=true Per verificare se sei interessato da questo problema, elenca le metriche definite dall'utente. Se vedi la fatturazione per metriche indesiderate, questo problema ti riguarda. Soluzione temporanea Se il problema ti riguarda, 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 risolve questo problema: Flag separati per controllare la raccolta dei log delle applicazioni rispetto alle metriche delle applicazioni Google Cloud Managed Service per Prometheus in bundle Se non riesci a eseguire l'upgrade alla versione 1.12, segui questi passaggi: Trova i pod e i servizi di origine con la 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"' 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 a metrics-server-config non vengono mantenute In casi estremi, l'elevata densità di pod può creare un overhead eccessivo di logging e monitoraggio, che può causare l'arresto e il riavvio di Metrics Server. Puoi modificare il ConfigMap metrics-server-config per allocare più risorse per mantenere in esecuzione Metrics Server. 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 è interessato immediatamente, ma al successivo riavvio recupera ConfigMap ripristinato ed è di nuovo vulnerabile a un overhead eccessivo. Soluzione temporanea Per la versione 1.11.x, puoi creare uno script per la modifica di ConfigMap ed eseguirlo insieme agli aggiornamenti o agli upgrade del cluster. Per la versione 1.12 e successive, contatta l'assistenza.
Logging e monitoraggio	1.11, 1.12	Le metriche ritirate influiscono sulla dashboard di Cloud Monitoring Diverse metriche solo software di Google Distributed Cloud sono state ritirate e, a partire dalla versione 1.11 di Google Distributed Cloud, i dati non vengono più raccolti per queste metriche ritirate. Se utilizzi queste metriche in uno dei tuoi criteri di avviso, non ci saranno dati per attivare la condizione di avviso. La tabella seguente elenca le singole metriche ritirate e la metrica che le sostituisce. Metriche ritirate 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 del cluster 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 versioni 1.11.0 e successive. Soluzione temporanea Segui questi passaggi per eseguire la migrazione alle metriche sostitutive: Nella console Google Cloud , seleziona Monitoring o fai clic sul pulsante seguente: Vai a Monitoring Nel riquadro di navigazione, seleziona Dashboard ed elimina la dashboard Stato dei nodi del cluster Anthos. Fai clic sulla scheda Libreria di esempi e reinstalla la dashboard Stato dei nodi del cluster Anthos. Segui le istruzioni riportate in Creazione di criteri di avviso per creare un criterio utilizzando il file di definizione dei criteri node-cpu-usage-high.json aggiornato.
Logging e monitoraggio	1.10, 1.11	stackdriver-log-forwarder presenta CrashloopBackOff errori In alcune situazioni, l'agente di logging fluent-bit può bloccarsi durante l'elaborazione di blocchi danneggiati. Quando l'agente di logging non è in grado di bypassare i blocchi danneggiati, potresti notare che stackdriver-log-forwarder continua ad arrestarsi in modo anomalo con un errore CrashloopBackOff. Se riscontri questo problema, i tuoi log contengono voci come le seguenti [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 temporanea: Pulisci i blocchi del buffer per Stackdriver Log Forwarder. Nota: nei seguenti comandi, sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione. 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 eliminati prima di procedere con il passaggio successivo. Esegui il deployment del seguente DaemonSet per pulire 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 Utilizza i seguenti comandi per verificare che 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 deve essere uguale al numero di nodi nel cluster. Elimina il DaemonSet di pulizia: kubectl --kubeconfig KUBECONFIG -n \ kube-system delete ds fluent-bit-cleanup Riavvia i pod di inoltro 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 relativo alle metriche sconosciute nel log di gke-metrics-agent gke-metrics-agent è un daemonset che raccoglie metriche su ogni nodo e le inoltra a Cloud Monitoring. Potrebbe produrre log come i seguenti: Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile Errori simili possono verificarsi per 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 ignorati in sicurezza, in quanto le metriche a cui si riferiscono non sono supportate e non sono fondamentali per il monitoraggio.
Logging e monitoraggio	1.10, 1.11	Interruzioni intermittenti dell'esportazione delle metriche I cluster potrebbero subire interruzioni nell'esportazione normale e continua delle metriche o potrebbero mancare metriche in alcuni nodi. Se questo problema interessa i tuoi cluster, potresti notare lacune nei dati per le seguenti metriche (come minimo): kubernetes.io/anthos/container_memory_working_set_bytes kubernetes.io/anthos/container_cpu_usage_seconds_total kubernetes.io/anthos/container_network_receive_bytes_total Soluzione temporanea Esegui l'upgrade dei cluster alla versione 1.11.1 o successive. Se non riesci a eseguire l'upgrade, segui questi passaggi come soluzione alternativa: Apri la risorsa stackdriver per la modifica: kubectl -n kube-system edit stackdriver stackdriver 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 Salva le modifiche e chiudi l'editor di testo. 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,10	Più gateway predefiniti interrompono la connettività agli endpoint esterni La presenza di più gateway predefiniti in un nodo può causare un'interruzione della connettività dall'interno di un pod agli endpoint esterni, ad esempio google.com. Per determinare se il problema ti riguarda, esegui questo comando sul nodo: ip route show La presenza di più istanze di default nella risposta indica che sei interessato.
Networking	1,12	Le modifiche alle risorse personalizzate di networking nei cluster utente vengono sovrascritte I cluster versione 1.12.x non ti impediscono di modificare manualmente le risorse personalizzate di rete nel cluster utente. Google Distributed Cloud 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 versione 1.12.x non applicano questo requisito. Le funzionalità di rete avanzate, come bilanciamento del carico in bundle con BGP, gateway NAT in uscita, rete SR-IOV, 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 temporanea Se hai modificato una delle risorse personalizzate menzionate in precedenza su un cluster utente, modifica le risorse personalizzate corrispondenti sul cluster di amministrazione in modo che corrispondano prima di eseguire l'upgrade. Questo passaggio garantisce che le modifiche alla configurazione vengano mantenute. Le versioni del cluster 1.13.0 e successive impediscono di modificare direttamente le risorse personalizzate di rete sui 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 filtro del percorso inverso Google Distributed Cloud configura il filtro del percorso inverso sui nodi per disattivare la convalida dell'origine (net.ipv4.conf.all.rp_filter=0). Se l'impostazione rp_filter viene modificata in 1 o 2, i pod non funzioneranno a causa dei timeout di comunicazione out-of-node. Il filtro del percorso inverso è impostato con i file rp_filter nella cartella di configurazione IPv4 (net/ipv4/conf/all). Questo valore può anche essere sostituito da sysctl, che archivia le impostazioni del filtro del percorso inverso in un file di configurazione della sicurezza di rete, ad esempio /etc/sysctl.d/60-gce-network-security.conf. Soluzione temporanea La connettività del pod può essere ripristinata eseguendo una delle seguenti soluzioni alternative: Imposta di nuovo manualmente il valore di net.ipv4.conf.all.rp_filter su 0 e poi 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 seguenti comandi per individuare ed eliminare il pod anetd e un nuovo pod anetd verrà avviato al suo posto: 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 di net.ipv4.conf.all.rp_filter sia impostato su 0 eseguendo sysctl net.ipv4.conf.all.rp_filter su ogni nodo.
Networking	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31, 1.32, 1.33, 1.34	Indirizzi IP del cluster di bootstrap (kind) e indirizzi IP dei nodi del cluster sovrapposti 192.168.122.0/24 e 10.96.0.0/27 sono i CIDR di pod e servizi predefiniti utilizzati dal cluster di bootstrap (kind). I controlli preflight non andranno a buon fine se si sovrappongono agli indirizzi IP delle macchine dei nodi del cluster. Soluzione temporanea Per evitare il conflitto, puoi trasmettere 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	La creazione o l'upgrade del cluster non riesce su CentOS A 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 seguito della fine del ciclo di vita, i repository yum hanno smesso di funzionare per CentOS, il che causa il mancato funzionamento delle operazioni di creazione e upgrade del cluster. Ciò vale per tutte le versioni supportate di CentOS e interessa tutte le versioni dei cluster. Soluzione temporanea Visualizzare i passaggi della soluzione alternativa Come soluzione alternativa, esegui i seguenti comandi per fare in modo che CentOS utilizzi un feed di archivio: sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-* sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \ /etc/yum.repos.d/CentOS-Linux-* Come soluzione a lungo termine, valuta la possibilità di eseguire la migrazione a un altro sistema operativo supportato.
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 scrivibile. 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 il problema ti riguarda, esegui questo comando sul nodo che ospita il container problematico: ausearch -m avc Se riscontri questo problema, 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 temporanea Per risolvere il problema, effettua una delle seguenti modifiche: Disattiva SELinux. Non utilizzare la funzionalità VOLUME all'interno di Dockerfile.
Upgrade e aggiornamenti	1.10, 1.11, 1.12	Node Problem Detector non è abilitato per impostazione predefinita dopo gli upgrade del cluster Quando esegui l'upgrade dei cluster, Node Problem Detector non è abilitato per impostazione predefinita. Questo problema è applicabile agli upgrade nelle release da 1.10 a 1.12.1 ed è stato risolto nella release 1.12.2. Soluzione temporanea: Per attivare il rilevatore problemi nodo: Verifica se il servizio node-problem-detector systemd è in esecuzione sul nodo. Utilizza il comando SSH e connettiti al nodo. 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, node-problem-detector non è in esecuzione sul nodo. Per abilitare Node Problem Detector, utilizza il comando kubectl edit e modifica il ConfigMap node-problem-detector-config. Per saperne di più, consulta Node Problem Detector.
Operazione	1.9, 1.10	Il backup del cluster non riesce quando si utilizza l'accesso non root Il comando bmctl backup cluster non va a buon fine se nodeAccess.loginUser è impostato su un nome utente non root.] Soluzione temporanea: Questo problema si verifica nelle 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 control plane Esiste un bug in anetd in cui i pacchetti vengono eliminati per i servizi LoadBalancer se i pod di backend vengono eseguiti sul nodo del control plane e utilizzano il campo hostNetwork: true nella specifica del container. Il bug non è presente nella versione 1.13 o successive. Soluzione temporanea: Le seguenti soluzioni alternative possono essere utili se utilizzi un servizio LoadBalancer supportato da pod hostNetwork: Esegui questi componenti sui nodi worker (non sui nodi del control plane). Utilizza externalTrafficPolicy: local nella specifica del servizio e assicurati che i tuoi carichi di lavoro vengano eseguiti sui nodi del bilanciatore del carico.
Upgrade e aggiornamenti	1.12, 1.13	Il pod anthos-version-$version$ orfano non riesce a eseguire il pull dell'immagine L'upgrade del cluster dalla versione 1.12.x alla 1.13.x potrebbe causare l'errore ImagePullBackOff nel pod anthos-version-$version$. Ciò si verifica a causa della race condition di anthos-cluster-operator viene eseguito l'upgrade e non dovrebbe influire sulle normali funzionalità del cluster. Il bug non è presente nella versione 1.13 o successive. Soluzione temporanea: Elimina il job di dynamic-version-installer tramite kubectl delete job anthos-version-$version$ -n kube-system
Upgrade e aggiornamenti	1,13	I cluster 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11 non possono essere aggiornati alla versione 1.13.0 I cluster versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11 non possono essere aggiornati alla versione 1.13.0. 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 temporanea: Per risolvere il problema: Esegui questi comandi 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' Riprova a eseguire l'upgrade del cluster.
Logging e monitoraggio	1.16.2, 1.16.3	Utilizzo elevato della CPU per stackdriver-operator Si è verificato un problema in stackdriver-operator che causa un consumo di tempo della CPU superiore al normale. L'utilizzo normale della CPU è inferiore a 50 milliCPU (50m) per stackdriver-operator in stato di inattività. La causa è una mancata corrispondenza delle risorse del certificato che stackdriver-operator si applica alle aspettative di cert-manager. Questa mancata corrispondenza causa una race condition tra cert-manager e stackdriver-operator durante l'aggiornamento di queste risorse. Questo problema potrebbe comportare una riduzione del rendimento dei cluster con disponibilità limitata della CPU. Soluzione temporanea: Fino a quando non potrai eseguire l'upgrade a una versione che ha corretto questo bug, utilizza la seguente soluzione alternativa: Per ridurre temporaneamente fare lo scale down di stackdriver-operator a 0 repliche, applica una risorsa personalizzata AddonConfiguration: kubectl scale deploy stackdriver-operator --replicas=0 Dopo aver eseguito l'upgrade a una versione che risolve il problema, aumenta di nuovo la scala stackdriver-operator: kubectl scale deploy stackdriver-operator --replicas=1
Logging e monitoraggio	1.16.0, 1.16.1	Lo scraping delle metriche basate sulle annotazioni non funziona Nella release secondaria 1.16 di Google Distributed Cloud, il campo enableStackdriverForApplications nella specifica della risorsa personalizzata stackdriver è ritirato. 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 attivare questa funzionalità. Se ti affidi alla raccolta delle metriche attivata dalle annotazioni prometheus.io/scrape sui tuoi workload, puoi utilizzare il flag di gate della funzionalità annotationBasedApplicationMetrics per mantenere il comportamento precedente. Tuttavia, si è verificato un problema che impedisce il corretto funzionamento di annotationBasedApplicationMetrics, impedendo la raccolta delle metriche dalle tue applicazioni in Cloud Monitoring. Soluzione temporanea: Per risolvere il problema, esegui l'upgrade del cluster alla versione 1.16.2 o successive. La raccolta delle metriche dei workload basata sulle annotazioni abilitata dal feature gate annotationBasedApplicationMetrics raccoglie le metriche per gli oggetti che hanno l'annotazione prometheus.io/scrape. Molti sistemi software di origine open source potrebbero utilizzare questa annotazione. Se continui a utilizzare questo metodo di raccolta delle metriche, tieni presente questa dipendenza in modo da non essere sorpreso dagli addebiti per le metriche in Cloud Monitoring.
Logging e monitoraggio	1.15, 1.16, 1.28.0-1.28.900, 1.29.0-1.29.400, 1.30.0, 1.30.100	Errore di audit logging di Cloud a causa dell'autorizzazione negata Cloud Audit Logs richiede una configurazione speciale delle autorizzazioni che viene eseguita automaticamente da cluster-operator tramite GKE Hub. Tuttavia, nei casi in cui un cluster di amministrazione gestiva più cluster con ID progetto diversi, un bug in cluster-operator causava l'aggiunta ripetuta dello stesso service account all'allowlist e il mancato completamento della richiesta di allowlisting a causa della limitazione delle dimensioni. Di conseguenza, l'inserimento degli audit log di alcuni o di tutti questi cluster in Google Cloudnon andrà a buon fine. Il sintomo è una serie di errori Permission Denied nel pod audit-proxy del cluster interessato. Un altro sintomo è lo stato di errore e un lungo elenco di account di servizio duplicati quando controlli la lista consentita di Cloud Audit Logs tramite GKE Hub: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging { "name": "projects/PROJECT_ID/locations/global/features/cloudauditlogging", "spec": { "cloudauditlogging": { "allowlistedServiceAccounts": [ "SERVICE-ACCOUNT-EMAIL", ... ... multiple lines of the same service account ] } }, "state": { "state": { "code": "ERROR" } } } Per risolvere il problema, puoi eseguire l'upgrade del cluster almeno alla versione 1.28.1000, 1.29.500 o 1.30.200 in cui il problema è stato risolto. In alternativa, puoi applicare la seguente soluzione alternativa: Visualizzare i passaggi della soluzione alternativa Elimina e ricrea la funzionalità GKE Hub di Cloud Audit Logging per forzare l'attivazione automatica della lista consentita. Elimina la funzionalità dell'hub:cloudauditlogging curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging Ricrea la funzionalità dell'hub cloudauditlogging: curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \ '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}' Nei comandi riportati sopra: Sostituisci PROJECT_ID con il progetto di operazioni del cluster� del cluster. Sostituisci SERVICE_ACCOUNT_EMAIL con l'indirizzo email del service account di logging e monitoraggio del cluster.
Configurazione	Tutte le versioni patch 1.29 e precedenti, 1.30.400 e precedenti e 1.31.0	Configurazione del mirror del registro sui nodi non aggiornata quando viene modificato solo il campo hosts Quando aggiorni il campo containerRuntime.registryMirrors.hosts per un endpoint mirror del registro nella specifica del cluster, le modifiche non vengono applicate automaticamente ai nodi del cluster. Questo problema si verifica perché la logica di riconciliazione non rileva le modifiche apportate esclusivamente al campo hosts e, di conseguenza, i job di aggiornamento della macchina responsabili dell'aggiornamento della configurazione di containerd sui nodi non vengono attivati. Verifica: Puoi verificare questo problema modificando solo il campo hosts per un mirror del registro e poi esaminando il file di configurazione di containerd (il percorso potrebbe essere /etc/containerd/config.toml o altri percorsi come /etc/containerd/config.d/01-containerd.conf a seconda della versione e della configurazione) su un nodo di lavoro. Il file non mostra l'elenco hosts aggiornato per l'endpoint mirror. Soluzione temporanea: Scegli una delle opzioni seguenti: Esegui l'upgrade a una versione con la correzione:esegui l'upgrade dei cluster alla versione 1.30.500-gke.126 o successive, 1.31.100-gke.136 o successive o 1.32.0. Attiva un aggiornamento tramite una modifica di NodePool:apporta una modifica banale alla specifica NodePool per i nodi interessati. Ad esempio, aggiungi un'etichetta o un'annotazione temporanea. Viene attivata la procedura di aggiornamento della macchina, che rileva le modifiche al mirror del registro. Puoi rimuovere la modifica banale in un secondo momento.

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:

• Requisiti per l'apertura di una richiesta di assistenza.
• Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
• Componenti supportati.