Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.
Google Distributed Cloud per problemi noti bare metal
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina elenca tutti i problemi noti di Google Distributed Cloud (solo software) per
bare metal, precedentemente noto come Google Distributed Cloud. Per filtrare i problemi noti in base a una versione o categoria del prodotto, seleziona i filtri dai seguenti menu a discesa.
Seleziona la versione di Google Distributed Cloud:
Seleziona la categoria del problema:
In alternativa, cerca il problema:
Categoria
Versioni identificate
Problema e soluzione alternativa
Installazione, upgrade e aggiornamenti
Da 1.28.0 a 1.28.600 e da 1.29.0 a 1.29.200
Errori del 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 si verifica questo problema, il log dei controlli preflight della macchina contiene un errore simile al 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 dal piano di controllo e dagli host di bootstrap, invece che dalle macchine nodo previste.
Soluzione:
Per aggirare il problema, modifica fs.inotify.max_user_instances
e fs.inotify.max_user_watches sui valori consigliati su
tutte le macchine del piano di controllo e di 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.
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 RHEL upstream) con SELinux in esecuzione in modalità di applicazione forzata. Ciò si applica in particolare quando la versione di container-selinux è successiva alla 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 l'opzione clusterNetwork.flatIPv4
impostata 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
ipam-controller-manager è installato.
Soluzione alternativa
Imposta il contesto predefinito per la directory /etc/kubernetes su ciascun nodo del piano di controllo in modo da digitare etc_t:
Questi comandi ripristinano la modifica container-selinux nella
directory /etc/kubernetes.
Dopo aver eseguito l'upgrade del cluster a una versione con la correzione, annulla la precedente modifica del contesto dei file su ciascun nodo del piano di controllo:
L'upgrade del cluster non va a buon fine a causa dell'errore del controllo della connettività di Google Cloud
Quando utilizzi bmctl per eseguire l'upgrade di un cluster, l'upgrade potrebbe non riuscire e restituire 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 da 1.28.0 a 1.28.500 di bmctl.
Soluzione:
Prima di eseguire il comando bmctl upgrade, imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che punti a un file di chiave dell'account di servizio valido:
L'impostazione delle credenziali predefinite dell'applicazione (ADC) in questo modo garantisce che bmctl disponga delle credenziali necessarie per accedere all'endpoint API di 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 RHEL upstream) con SELinux in esecuzione in modalità di applicazione forzata. Ciò si applica in particolare quando la versione di container-selinux è successiva alla 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 l'opzione clusterNetwork.flatIPv4
impostata 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
ipam-controller-manager è installato.
Soluzione alternativa
Imposta il contesto predefinito per la directory /etc/kubernetes su ciascun nodo del piano di controllo in modo da digitare etc_t:
Questi comandi ripristinano la modifica container-selinux nella
directory /etc/kubernetes.
Dopo aver eseguito l'upgrade del cluster a una versione con la correzione, annulla la precedente modifica del contesto dei file su ciascun nodo del piano di controllo:
L'upgrade del cluster non va a buon fine a causa dell'errore del controllo della connettività di Google Cloud
Quando utilizzi bmctl per eseguire l'upgrade di un cluster, l'upgrade potrebbe non riuscire e restituire 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 da 1.28.0 a 1.28.500 di bmctl.
Soluzione:
Prima di eseguire il comando bmctl upgrade, imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che punti a un file di chiave dell'account di servizio valido:
L'impostazione delle credenziali predefinite dell'applicazione (ADC) in questo modo garantisce che bmctl disponga delle credenziali necessarie per accedere all'endpoint API di Google.
Installazione
1,29
Problema di Autorizzazione binaria per un 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 del servizio di identità GKE e di altri pod critici è bloccata dal webhook di Autorizzazione binaria.
Per determinare se hai riscontrato questo problema, completa i seguenti
passaggi:
Identifica i pod in stato di errore:
kubectl get pods \
-n anthos-identity-service \
--kubeconfig CLUSTER_KUBECONFIG
Descrivere il pod danneggiato.
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 viene visualizzato il messaggio precedente, significa che il problema è presente nel cluster.
Soluzione:
Per aggirare questo problema, procedi nel seguente modo:
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.
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28 e 1,29
Punti di montaggio con SELinux abilitato che causano problemi
Se hai abilitato SELinux e monta i file system nelle directory correlate a Kubernetes, potresti riscontrare problemi come errori di creazione del cluster, file illeggibili o problemi di autorizzazione.
Per determinare se hai riscontrato questo problema, esegui questo comando:
ls -Z /var/lib/containerd
.
Se vedi
system_u:object_r:unlabeled_t:s0 dove ti aspetti di vedere
un'altra etichetta, ad esempio
system_u:object_r:container_var_lib_t:s0, è interessato.
Soluzione:
Se di recente hai montato file system nelle directory, assicurati che queste
directory siano aggiornate con la configurazione SELinux.
Devi anche eseguire i comandi seguenti su ogni macchina prima di eseguire bmctl create cluster:
restorecon -R -v /var
restorecon -R -v /etc
Questa correzione una tantum persisterà dopo il riavvio, ma è obbligatoria ogni volta che viene aggiunto un nuovo nodo con gli stessi punti di montaggio. Per ulteriori informazioni, consulta la sezione Mounting File Systems nella documentazione di Red Hat.
Ripristino/eliminazione
1.29.0
La reimpostazione del cluster utente non riesce a eliminare lo spazio dei nomi
Durante l'esecuzione di bmctl reset cluster -c ${USER_CLUSTER}, al termine di tutti i job correlati, il comando non riesce a eliminare lo spazio dei nomi del cluster utente. Lo spazio dei nomi del cluster utente è bloccato nello stato Terminating. Alla fine, la reimpostazione del cluster scade e restituisce un errore.
Soluzione:
Per rimuovere lo spazio dei nomi e completare la reimpostazione del cluster utente, segui questi passaggi:
Elimina il pod metrics-server dal cluster di amministrazione:
Una volta rimosso il finalizzatore, lo spazio dei nomi del cluster viene rimosso e la reimpostazione del cluster è stata completata.
Configurazione, installazione, sicurezza
Da 1.16.0 a 1.16.7 e da 1.28.0 a 1.28.400
Nel deployment di Autorizzazione binaria manca un nodeSelector
Se hai abilitato Autorizzazione binaria per Google Distributed Cloud e utilizzi una versione da 1.16.0 a 1.16.7 o da 1.28.0 a 1.28.400, potresti riscontrare un problema relativo alla pianificazione dei pod per la funzionalità. In queste versioni, al deployment di Autorizzazione binaria manca un nodeSelector, quindi i pod per la funzionalità possono essere pianificati sui nodi worker anziché sui nodi del piano di controllo. Questo comportamento non causa errori, ma non è intenzionale.
Soluzione:
Per tutti i cluster interessati, completa questi passaggi:
Apri il file del deployment di Autorizzazione binaria:
Una volta salvata la modifica, viene eseguito nuovamente il deployment dei pod solo nei nodi del piano di controllo. Questa correzione deve essere applicata dopo ogni upgrade.
Upgrade e aggiornamenti
1.28.0, 1.28.100, 1.28.200, 1.28.300
Errore durante l'upgrade di un cluster a 1.28.0-1.28.300
L'upgrade dei cluster creati prima della versione 1.11.0 alle versioni 1.28.0-1.28.300 potrebbe causare l'ingresso in uno stato di errore del pod del deployment del controller del controller del ciclo di vita durante l'upgrade. In questo caso, i log del pod di deployment del controller del ciclo di vita presentano 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:
Questo problema è stato risolto nella versione 1.28.400. Esegui l'upgrade alla versione 1.28.400 o successiva per risolvere il problema.
Se non riesci a eseguire l'upgrade, esegui questi comandi per risolvere il
problema:
A volte i log dei cluster o dei container sono contrassegnati con un ID progetto diverso in resource.labels.project_id di Esplora log.
Ciò può accadere quando il cluster è configurato per utilizzare l'osservabilità PROJECT_ONE, impostata nel campo clusterOperations.projectID nella configurazione del cluster.
Tuttavia, cloudOperationsServiceAccountKeyPath nella configurazione ha una chiave dell'account di servizio del progetto PROJECT_TWO.
In questi casi, tutti i log vengono instradati a PROJECT_ONE, ma resource.labels.project_id ha l'etichetta PROJECT_TWO.
Soluzione:
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 dell'account di servizio con il progetto attuale.
Modifica il project_id direttamente nel filtro dei log da Esplora log.
Networking
1.29.0
Riduzione delle prestazioni per i cluster che utilizzano il bilanciamento del carico in bundle con BGP
Per i cluster della versione 1.29.0 che utilizzano il bilanciamento del carico in bundle con BGP, le prestazioni del bilanciamento del carico possono peggiorare man mano che il numero totale di servizi di tipo LoadBalancer si avvicina a 2000. Con il peggioramento delle prestazioni, i servizi appena creati richiedono molto tempo per connettersi o non possono essere connessi da un client. I servizi esistenti continuano a funzionare, ma non gestiscono in modo efficace le modalità di errore, come la perdita di un nodo del bilanciatore del carico. Questi problemi dei servizi si verificano quando il deployment ang-controller-manager viene terminato per esaurimento della memoria.
Se il tuo cluster è interessato da questo problema, i servizi nel cluster sono
irraggiungibili e non in stato integro e il deployment ang-controller-manager
è in un CrashLoopBackOff. La risposta quando
elenchi i deployment ang-controller-manager è simile alla
seguente:
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:
NAME CPU_LIMITS MEMORY_LIMITS
ang-controller-manager <none> 400Mi
Installazione, upgrade, backup e ripristino
1.28.0, 1.28.100
I problemi di connettività dell'endpoint gcr.io di Container Registry possono bloccare le operazioni del cluster
Più operazioni per i cluster di amministrazione creano un cluster di bootstrap. Prima di creare un cluster di bootstrap, bmctl esegue un controllo della connettività Google Cloud dalla workstation di amministrazione.
Questo controllo potrebbe non riuscire a causa di problemi di connettività con l'endpoint di Container Registry, gcr.io e potresti visualizzare un messaggio di errore come il 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 alternativa
Per risolvere il problema, riprova a eseguire l'operazione con il flag
--ignore-validation-errors.
Networking
1,15, 1,16
GKE Dataplane V2 non è compatibile con alcuni driver di archiviazione
I cluster Distributed Cloud utilizzano GKE Dataplane V2, che non è compatibile con alcuni provider di archiviazione. Potresti riscontrare problemi con volumi o pod NFS bloccati. Ciò è particolarmente probabile se hai carichi di lavoro che utilizzano volumi ReadWriteMany supportati da driver di archiviazione soggetti a questo problema:
Robin.io
Portworx (sharedv4 volumi di servizio)
csi-nfs
L'elenco non è esaustivo.
Soluzione alternativa
È disponibile una correzione per questo problema per le seguenti versioni di Ubuntu:
20.04 LTS: usa un'immagine del kernel 5.4.0 successiva a
linux-image-5.4.0-166-generic
22.04 LTS: usa 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 un cluster di grandi dimensioni
Potresti notare che kube-state-metrics o il pod gke-metrics-agent esistente sullo stesso nodo di kube-state-metrics ha esaurito la memoria (OOM).
Questo può accadere in cluster con più di 50 nodi o con molti oggetti Kubernetes.
Soluzione alternativa
Per risolvere il problema, aggiorna la definizione della risorsa personalizzata stackdriver per utilizzare la porta di funzionalità ksmNodePodMetricsOnly. Questa limitazione delle funzionalità garantisce l'esposizione solo di un numero limitato di metriche critiche.
Per utilizzare questa soluzione alternativa, completa i seguenti passaggi:
Controlla la definizione di risorsa personalizzata stackdriver per le
porte di funzionalità disponibili:
Il controllo preflight non riesce su RHEL 9.2 a causa di iptables mancanti
Durante l'installazione di un cluster sul sistema operativo Red Hat Enterprise Linux (RHEL) 9.2, potrebbe verificarsi un errore a causa del pacchetto iptables mancante. 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 alternativa
Bypassa l'errore del controllo preflight impostando
spec.bypassPreflightCheck su true sulla
risorsa cluster.
Operazione
1,10, 1,11, 1,12, 1,13, 1,14, 1,15 e 1,16
Failover MetalLB lento su larga scala
Quando MetalLB gestisce un numero elevato di servizi (oltre 10.000), il failover può richiedere oltre un'ora. Questo accade perché MetalLB utilizza una coda di frequenza limitata che, se è scalata su larga scala, può impiegare un po' di tempo per raggiungere il servizio che deve eseguire il failover.
Soluzione alternativa
Esegui l'upgrade del cluster alla versione 1.28 o successiva. Se non puoi eseguire l'upgrade, la modifica manuale del servizio (ad esempio, l'aggiunta di un'annotazione) comporta un 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ò generare un errore a causa di errori del proxy se non hai definito le variabili di ambiente HTTPS_PROXY e NO_PROXY nella workstation di amministrazione. Il comando bmctl segnala un messaggio di errore relativo alla mancata chiamata di alcuni servizi Google, come nell'esempio seguente:
Imposta manualmente HTTPS_PROXY e NO_PROXY sulla workstation di amministrazione.
Upgrade e aggiornamenti
1.28.0-gke.435
Gli upgrade alla versione 1.28.0-gke.435 potrebbero non riuscire se audit.log ha una proprietà errata
In alcuni casi, per il file /var/log/apiserver/audit.log nei nodi del piano di controllo la proprietà dei gruppi e degli utenti è impostata su root.
Questa impostazione di proprietà dei file causa errori di upgrade per i nodi del piano di controllo durante l'upgrade di un cluster dalla versione 1.16.x alla versione 1.28.0-gke.435.
Questo problema si applica solo ai cluster creati prima della versione 1.11 e in cui Cloud Audit Logs è disabilitato. Cloud Audit Logs è abilitato per impostazione predefinita per i cluster con versione 1.9 e successive.
Soluzione alternativa
Se non riesci a eseguire l'upgrade del cluster alla versione 1.28.100-gke.146, segui questi passaggi come soluzione alternativa per completare l'upgrade del cluster alla versione 1.28.0-gke.435:
Se Cloud Audit Logs è abilitato, rimuovi il file /var/log/apiserver/audit.log.
Se Cloud Audit Logs è disabilitato, modifica la proprietà di /var/log/apiserver/audit.log in modo che corrisponda alla 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, viene eseguito l'upgrade del bundle MetalLB 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 elemento 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. Di conseguenza, i servizi che utilizzano
metallb.universe.tf/address-pool come annotazione per selezionare
il pool di indirizzi per un indirizzo IP non ricevono più un indirizzo IP dal
controller MetalLB.
Questo problema è stato risolto in Google Distributed Cloud versione 1.28.100-gke.146.
Soluzione alternativa
Se non riesci a eseguire l'upgrade del cluster alla versione 1.28.100-gke.146, attieniti alla seguente procedura:
Ottieni 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 è permanente.
Upgrade e aggiornamenti
1,14; 1,15; 1,16; 1,28; 1,29
Pod orfani dopo l'upgrade alla versione 1.14.x
Quando esegui l'upgrade dei cluster Google Distributed Cloud alla versione 1.14.x, alcune risorse della versione precedente non vengono eliminate. In particolare, potresti vedere un insieme di pod orfani come il seguente:
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 all'output
di esempio che segue:
"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:
Rimuovi il membro etcd obsoleto che causa l'errore
del job machine-init. Completa i seguenti passaggi su un nodo del piano di controllo funzionante:
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 che segue:
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 con errori. Nell'output di esempio precedente, questo ID è
bd1949bcb70e2cb5.
Il seguente output di esempio mostra che il membro è stato rimosso:
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
Networking
1.28.0
In Cilium-operator mancano le autorizzazioni di nodo list e
watch
In Cilium 1.13, le autorizzazioni ClusterRole cilium-operator non sono corrette. Autorizzazioni Nodo list e
watch mancanti. cilium-operator non riesce ad avviare i garbage collection, causando i seguenti problemi:
Perdita di risorse Cilium.
Le identità inattive non vengono rimosse dalle mappe dei criteri di BP.
Le mappe di criteri potrebbero raggiungere il limite di 16.000.
Impossibile aggiungere nuove voci.
Applicazione NetworkPolicy non corretta.
Le identità potrebbero raggiungere il limite di 64.000.
Non è possibile creare nuovi pod.
Un operatore privo delle autorizzazioni per i nodi segnala il seguente messaggio di log di esempio:
2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s
L'agente Cilium segnala un messaggio di errore quando non riesce a inserire una voce in una mappa dei criteri, come nell'esempio seguente:
level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint
Soluzione:
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 in modo dinamico la modifica delle autorizzazioni. 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à kubeadm eseguita durante il controllo preflight
dell'upgrade potrebbe non riuscire con il seguente messaggio di errore:
[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found
Questo errore può essere ignorato. Se si verifica questo errore che blocca l'upgrade, esegui nuovamente il comando di upgrade.
Se noti questo errore quando esegui il preflight utilizzando il comando bmctl preflightcheck, non viene bloccato nulla da questo errore. Puoi eseguire di nuovo il controllo preflight per ottenere informazioni accurate
preflight.
Soluzione:
Esegui di nuovo il comando di upgrade o, se riscontrato durante il giorno bmctl preflightcheck, esegui nuovamente il comando preflightcheck.
Operazione
1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0
Il controllo di integrità della rete periodico non riesce quando un nodo viene sostituito o rimosso
Questo problema riguarda i cluster che eseguono controlli di integrità di rete periodici dopo che un nodo è stato sostituito o rimosso. Se il cluster viene sottoposto a controlli di integrità periodici, il controllo di integrità della rete periodico determina un errore in seguito alla sostituzione o alla rimozione di un nodo, perché il ConfigMap dell'inventario di rete non viene aggiornato una volta creato.
Soluzione:
La soluzione alternativa consigliata è eliminare il ConfigMap dell'inventario e il controllo di integrità periodico della rete. L'operatore del cluster li ricrea automaticamente con le informazioni più aggiornate.
Il gateway di rete per GDC non può applicare la tua configurazione se 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 per GDC considera il punto come un percorso nella directory quando esegue sysctl per apportare modifiche. Quando
Network Gateway for GDC verifica se è abilitato il rilevamento di indirizzi duplicati (DAD), il controllo potrebbe non riuscire e pertanto non verrà riconciliato.
Il comportamento è diverso tra le versioni del cluster:
1.14 e 1.15: questo errore esiste solo quando utilizzi indirizzi IP mobili IPv6. Se non utilizzi indirizzi IP mobili IPv6, non noterai questo problema se i nomi dei tuoi dispositivi contengono un punto.
1.16.0 - 1.16.2: questo errore esiste sempre quando i nomi dei dispositivi contengono un punto.
Soluzione:
Esegui l'upgrade del cluster alla versione 1.16.3 o successiva.
Come soluzione alternativa fino a quando 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 è disabilitato
Se seccomp è disabilitato per il tuo cluster
(spec.clusterSecurity.enableSeccomp impostato su false),
gli upgrade alla versione 1.16.0 non andranno a buon fine.
Google Distributed Cloud versione 1.16 utilizza Kubernetes versione 1.27.
In Kubernetes 1.27.0 e versioni successive, la funzionalità per impostare i profili seccomp è GA e non utilizza più una limitazione di funzionalità.
Questa modifica a Kubernetes causa l'esito negativo degli upgrade alla versione 1.16.0 quando
seccomp è disabilitato nella configurazione del cluster. Questo problema è stato risolto nella versione 1.16.1 e nei cluster successivi. Se il campo cluster.spec.clusterSecurity.enableSeccomp è impostato su false, puoi eseguire l'upgrade alla versione 1.16.1 o successive.
I cluster con spec.clusterSecurity.enableSeccomp non configurato o impostato su true non sono interessati.
I metadati containerd potrebbero danneggiarsi dopo il riavvio quando viene montato /var/lib/containerd
Se hai montato facoltativamente /var/lib/containerd, i metadati containerd potrebbero danneggiarsi dopo un riavvio. I metadati danneggiati potrebbero causare un errore dei pod, compresi quelli critici per il sistema.
Per verificare se questo problema ti riguarda, verifica se in /etc/fstab è definito un montaggio facoltativo
per /var/lib/containerd/ e se è presente
nofail nelle opzioni di montaggio.
Soluzione:
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
Esegui la pulizia dei pod inattivi nel cluster
Potresti vedere i pod gestiti da un deployment (ReplicaSet) in stato Failed e con lo stato TaintToleration. Questi pod non utilizzano risorse cluster, ma devono essere eliminati.
Puoi utilizzare questo comando kubectl per elencare i pod di cui è possibile eseguire la pulizia:
kubectl get pods –A | grep TaintToleration
L'output di esempio seguente mostra un pod con lo
stato TaintToleration:
Per ogni pod con i sintomi descritti, controlla il ReplicaSet a cui appartiene il pod. Se il ReplicaSet è soddisfatto, puoi eliminare i pod:
Ottieni il ReplicaSet che gestisce il pod e trova il valore ownerRef.Kind:
kubectl get pod POD_NAME -n NAMESPACE -o yaml
Scarica 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
Gli eventi etcd possono bloccarsi quando viene eseguito l'upgrade alla versione 1.16.0
Quando esegui l'upgrade di un cluster esistente alla versione 1.16.0, gli errori dei pod relativi a etcd-events possono bloccare l'operazione. In particolare, il job del nodo di upgrade non va a buon fine per il passaggio TASK [etcd_events_install : Run etcdevents].
Se si verifica questo problema, vengono visualizzati errori dei pod come i seguenti:
Il pod kube-apiserver non si avvia con il seguente errore:
Il pod etcd-events non si avvia con il seguente errore:
Error: error syncing endpoints with etcd: context deadline exceeded
Soluzione:
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 piano di controllo 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 e, di conseguenza, orderPolicy viene ignorato.
Soluzione:
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, operazione
1,10; 1,11; 1,12; 1,13; 1,14
Gateway di rete per i componenti GDC rimossi o in attesa a causa di una classe di priorità mancante
I pod del gateway di rete in kube-system potrebbero mostrare lo stato Pending o Evicted, come mostrato nel seguente output di esempio ridotto:
Questi errori indicano eventi di eliminazione o l'impossibilità di pianificare i pod a causa delle risorse dei nodi. Poiché il gateway di rete per i pod GDC non ha PriorityClass, ha la stessa priorità predefinita degli altri carichi di lavoro.
Quando i nodi sono vincolati alle risorse, i pod del gateway di rete potrebbero essere rimossi. Questo comportamento è particolarmente negativo per il DaemonSet ang-node, poiché i pod devono essere pianificati su un nodo specifico e non possono essere migrati.
Soluzione:
Esegui l'upgrade alla versione 1.15 o successiva.
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 un processo di riconciliazione, ad esempio durante l'upgrade del cluster.
Assegna il valore PriorityClass system-cluster-critical ai deployment del controller del cluster ang-controller-manager e autoscaler.
Assegna il valore PriorityClass system-node-critical al nodo
ang-daemon DaemonSet.
Installazione, upgrade e aggiornamenti
1.15.0, 1.15.1, 1.15.2
La creazione e gli upgrade del cluster non sono riusciti a causa della lunghezza del nome del cluster
La creazione dei cluster delle versioni 1.15.0, 1.15.1 o 1.15.2 o l'upgrade
dei cluster alla versione 1.15.0, 1.15.1 o 1.15.2 non riesce quando il nome del cluster
supera i 48 caratteri (versione 1.15.0) o i 45 caratteri (versione
1.15.1 o 2). Durante le operazioni di creazione e upgrade del cluster, Google Distributed Cloud crea una risorsa di controllo di integrità con un nome che incorpora il nome e la versione del cluster:
Per i cluster della versione 1.15.0, il nome della risorsa del controllo di integrità è
CLUSTER_NAME-add-ons-CLUSTER_VER.
Per i cluster versione 1.15.1 o 1.15.2, il nome della risorsa del controllo di integrità è
CLUSTER_NAME-kubernetes-CLUSTER_VER.
Per i nomi di cluster lunghi, il nome della risorsa per il controllo di integrità supera la limitazione di 63 caratteri di Kubernetes sulla lunghezza dei nomi delle etichette, il che impedisce la creazione della risorsa per il controllo di integrità.
Senza un controllo di integrità riuscito, l'operazione del cluster non va a buon fine.
Per verificare se hai riscontrato questo problema, utilizza kubectl describe per controllare la risorsa con errore:
Se questo problema ti riguarda, la risposta contiene un avviso relativo a 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 alternativa
Per sbloccare l'upgrade o la creazione del cluster, puoi ignorare il controllo di integrità. Utilizza il seguente comando per applicare una patch alla risorsa personalizzata per il controllo di integrità con stato superato: (status: {pass: true})
Non è possibile eseguire l'upgrade ai cluster delle versioni 1.14.0 e 1.14.1 con funzionalità di anteprima alla versione 1.15.x
Se nei cluster delle versioni 1.14.0 e 1.14.1 è abilitata una funzionalità di anteprima, l'upgrade alla versione 1.15.x viene bloccato. Questo
si applica alle funzionalità di anteprima come la possibilità di creare un cluster senza
kube-proxy, che è abilitata con la seguente annotazione nel file di configurazione
del cluster:
Se si verifica questo problema, durante l'upgrade del cluster viene visualizzato 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 della versione 1.14.2 e successive.
Soluzione:
Se non riesci a eseguire l'upgrade dei cluster alla versione 1.14.2 o successiva prima di eseguire l'upgrade alla versione 1.15.x, puoi eseguire l'upgrade alla versione 1.15.x direttamente utilizzando un cluster di bootstrap:
bmctl upgrade cluster --use-bootstrap=true
Operazione
1,15
I cluster della versione 1.15 non accettano indirizzi IP mobili duplicati
Il gateway di rete per GDC non consente di creare nuove risorse personalizzate NetworkGatewayGroup contenenti indirizzi IP in spec.floatingIPs che sono già utilizzate nelle risorse personalizzate di NetworkGatewayGroup esistenti. Questa regola viene applicata da un webhook nei cluster Google Distributed Cloud 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 la sta già utilizzando:
IP address exists in other gateway with name default
La documentazione iniziale per le funzionalità di networking avanzate, ad esempio il gateway NAT in uscita, non prescrive la presenza di indirizzi IP duplicati.
Inizialmente, il riconciliatore ha riconosciuto solo la risorsa NetworkGatewayGroup denominata
default. Il gateway di rete per GDC ora riconosce tutte le risorse personalizzate NetworkGatewayGroup nello spazio dei nomi di sistema. Le risorse personalizzate NetworkGatewayGroup
esistenti sono rispettate così come sono.
Soluzione:
Gli errori si verificano solo durante la creazione di una nuova risorsa personalizzata NetworkGatewayGroup.
Per risolvere l'errore:
Utilizza il comando seguente per elencare NetworkGatewayGroups
risorse personalizzate:
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):
Per applicare le modifiche, chiudi e salva le risorse personalizzate modificate.
Runtime VM su GDC
1.13.7
Le VM potrebbero non avviarsi su cluster 1.13.7 che utilizzano un registro privato
Quando abiliti il runtime VM su GDC su un cluster della versione 1.13.7 nuovo o con upgrade eseguito che utilizza un registro privato, le VM che si connettono alla rete di nodi o che utilizzano una GPU potrebbero non avviarsi correttamente. Questo problema è dovuto al fatto che alcuni pod di sistema nello spazio dei nomi vm-system ricevono errori di pull delle immagini. Ad esempio, se la tua VM utilizza la rete di nodi, alcuni pod potrebbero segnalare errori di pull delle immagini come i seguenti:
macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m
Questo problema è stato risolto nella versione 1.14.0 e nelle versioni successive dei cluster Google Distributed Cloud.
Soluzione alternativa
Se non puoi eseguire subito l'upgrade dei cluster, puoi eseguire il pull delle immagini manualmente. I seguenti comandi eseguono il pull dell'immagine del plug-in CNI di macvtap per la tua VM e ne eseguono il push nel registro privato:
Sostituisci REG_HOST con il nome di dominio di un host di cui esegui il mirroring localmente.
Installazione
1,11, 1,12
Durante la creazione del cluster type, il pod gke-metric-agent non viene avviato
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 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"
Visualizzerai il seguente errore di tipo "Impossibile eseguire il pull" nel pod:
gcr.io/gke-on-prem-staging/gke-metrics-agent
Soluzione alternativa
Nonostante gli errori, il processo di creazione del cluster non viene bloccato perché lo scopo del pod gke-metrics-agent nel cluster in natura è facilitare la percentuale di successo della creazione del cluster nonché per il monitoraggio e il monitoraggio interni.
Pertanto, puoi ignorare questo errore.
Soluzione alternativa
Nonostante gli errori, il processo di creazione del cluster non viene bloccato perché lo scopo del pod gke-metrics-agent nel cluster in natura è facilitare la percentuale di successo della creazione del cluster nonché 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 che include endpoint IPv4 e IPv6) e utilizzi l'endpoint IPv6, il nodo LoadBalancer che gestisce il servizio potrebbe arrestarsi in modo anomalo. Questo problema riguarda i clienti che utilizzano servizi a doppio stack con CentOS o RHEL e una versione del kernel precedente a kernel-4.18.0-372.46.1.el8_6.
Se ritieni che questo problema ti riguardi, controlla la versione del kernel sul nodo LoadBalancer utilizzando il comando uname -a.
Soluzione:
Aggiorna il nodo LoadBalancer alla versione del kernel kernel-4.18.0-372.46.1.el8_6 o successiva. Questa versione del kernel è disponibile per impostazione predefinita in CentOS e RHEL 8.6 e versioni successive.
Networking
1,11, 1,12, 1,13 e 1.14.0
Problemi di connettività intermittenti dopo il riavvio del nodo
Dopo aver riavviato un nodo, potresti riscontrare problemi di connettività intermittenti per un servizio NodePort o LoadBalancer. Ad esempio, potresti riscontrare errori di handshake TLS intermittente o di reimpostazione della connessione. Questo problema è stato risolto per i cluster con versione 1.14.1 e successive.
Per verificare se questo problema ti riguarda, consulta le iptables
regole di forwarding sui nodi in cui è in esecuzione il pod di backend per il servizio
interessato:
sudo iptables -L FORWARD
Se vedi la regola KUBE-FORWARD prima della
regola CILIUM_FORWARD in iptables, 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:
Riavvia il pod anetd sul nodo non configurato correttamente. Dopo aver riavviato il pod anetd, la regola di forwarding in iptables dovrebbe essere configurata correttamente.
L'output di esempio seguente mostra che ora la regola CILIUM_FORWARD è 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 sul proprietario e sull'autorizzazione
La funzionalità di anteprima del cluster 1.9.x che utilizza bmctl 1.9.x non conserva le informazioni originali sul proprietario e sull'autorizzazione. Per verificare se questa funzionalità ti riguarda, estrai il file di cui hai eseguito il backup utilizzando questo comando:
tar -xzvf BACKUP_FILE
Soluzione alternativa
Verifica che sia presente metadata.json e che bmctlVersion sia 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.
Upgrade e creazioni
1.14.2
clientconfig-operator bloccato in stato di attesa con CreateContainerConfigError
Se hai eseguito l'upgrade o creato un cluster alla versione 1.14.2 con una configurazione OIDC/LDAP, potresti vedere il pod clientconfig-operator bloccato in stato di attesa. Con questo problema, sono presenti due pod clientconfig-operator, uno in esecuzione e l'altro in stato In attesa.
Questo problema si applica solo ai 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, tra cui 1.15.0 e successive.
Soluzione:
Come soluzione alternativa, puoi applicare patch al deployment clientconfig-operator
per aggiungere 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:
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 non rispondere e non riuscire più con il seguente errore: x509: certificate signed by unknown authority.
Se hai riscontrato questo problema, il comando bmctl potrebbe restituire il seguente messaggio prima di non rispondere:
Signing CA completed in 3/0 control-plane nodes
In questo caso, alla fine il comando ha esito negativo. La rotazione del log dell'autorità di certificazione per un cluster con tre piani di controllo può includere voci come le seguenti:
[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")
ipam-controller-manager di arresti anomali in cluster a doppio stack
Quando esegui il deployment di un cluster a doppio stack (un cluster con indirizzi sia IPv4 che IPv6), i pod di ipam-controller-manager potrebbero arrestarsi in modo anomalo. Questo comportamento causa il ciclo dei nodi tra gli stati Ready e NotReady e l'installazione del cluster potrebbe non riuscire. Questo problema può verificarsi quando il server API è sottoposto a un carico elevato.
Per capire se questo problema ti riguarda, controlla se i pod di ipam-controller-manager non funzionano con errori CrashLoopBackOff:
kubectl -n kube-system get pods | grep ipam-controller-manager
L'output di esempio seguente mostra i pod in stato CrashLoopBackOff:
I cluster che eseguono etcd versione 3.4.13 o precedenti potrebbero riscontrare l'indisponibilità degli smartwatch e smartwatch di risorse non operative, il che può causare i seguenti problemi:
La pianificazione dei pod è interrotta
Impossibile registrare i nodi
kubelet non osserva le modifiche ai pod
Questi problemi possono rendere il cluster non funzionante.
Questo problema è stato risolto in Google Distributed Cloud versione 1.12.9, 1.13.6,
1.14.3 e versioni successive. Queste release più recenti utilizzano la versione etcd 3.4.21. Tutte le versioni precedenti di Google Distributed Cloud sono interessate da questo problema.
Soluzione alternativa
Se non puoi eseguire l'upgrade immediatamente, puoi mitigare il rischio di errore del cluster riducendo il numero di nodi nel cluster. Rimuovi
i nodi fino a quando la metrica etcd_network_client_grpc_sent_bytes_total
è inferiore a 300 Mbps.
Per visualizzare questa metrica in Metrics Explorer:
Vai a Metrics Explorer nella console Google Cloud:
Espandi Seleziona una metrica, inserisci Kubernetes Container
nella barra dei filtri e utilizza i sottomenu per selezionare la metrica:
Nel menu Risorse attive, seleziona Container Kubernetes.
Nel menu Categorie 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'elemento syncStatus dell'oggetto SriovNetworkNodeState
può segnalare il valore "Non riuscito" per un nodo configurato. Per visualizzare lo stato di un nodo e determinare se il problema ti riguarda, esegui questo comando:
kubectl -n gke-operators get \
sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
-o jsonpath='{.status.syncStatus}'
Sostituisci NODE_NAME con il nome del nodo da
verificare.
Soluzione:
Se lo stato dell'oggetto SriovNetworkNodeState è "Non riuscito", 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 e 1.14.1
Alcuni nodi worker non sono in stato Pronto dopo l'upgrade
Al termine dell'upgrade, la condizione Pronto per alcuni nodi worker potrebbe essere impostata su false. Nella risorsa Node, verrà visualizzato un errore accanto alla condizione Pronto, simile all'esempio seguente:
container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
Quando accedi alla macchina bloccata, la configurazione CNI sulla macchina è vuota:
sudo ls /etc/cni/net.d/
Soluzione alternativa
Riavvia il pod anetd del nodo eliminandolo.
Upgrade e aggiornamenti, Sicurezza
1,1
La rotazione di più certificati da Gestore certificati causa incoerenze
Dopo più rotazioni manuali o automatiche dei certificati, il pod webhook, come anthos-cluster-operator, non viene aggiornato con i nuovi certificati emessi da cert-manager. Qualsiasi aggiornamento alla 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 gestore certificati su un cluster più vecchio di 180 giorni e non hai mai riavviato anthos-cluster-operator.
Se hai eseguito manualmente la rotazione di certificati emesso da cert-manager su un cluster più vecchio di 90 giorni o più e non hai mai riavviato anthos-cluster-operator.
Soluzione alternativa
Riavvia il pod terminando anthos-cluster-operator.
Upgrade e aggiornamenti
1.14.0
Pod del deploymenter del controller del ciclo di vita obsoleti creati durante l'upgrade del cluster utente
Nei cluster di amministrazione della versione 1.14.0, durante gli upgrade del cluster utente potrebbero essere creati uno o più pod del deploymenter del controller del ciclo di vita obsoleti.
Questo problema si applica ai cluster utente inizialmente creati 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 versione 1.14.1.
Soluzione:
Per rimuovere i pod del deploymenter del controller del ciclo di vita obsoleti:
Elenca le risorse per i controlli preflight:
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A
L'output avrà 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:
1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16 e 1,28
Lo stato di BGPSession cambia costantemente a causa dell'elevato numero di route in entrata
Il networking avanzato di Google Distributed Cloud non riesce a gestire correttamente le sessioni BGP quando i peer esterni pubblicizzano un elevato numero di route (circa 100 o più). Con un numero elevato di route in entrata, il controller BGP locale del nodo impiega troppo tempo per riconciliare le sessioni BGP e non riesce ad aggiornare lo stato. La mancanza di aggiornamenti dello stato o di un controllo di integrità determina l'eliminazione della sessione
perché non aggiornata.
I comportamenti indesiderati nelle sessioni BGP che potresti notare e indicare un problema includono quanto segue:
Eliminazione e ricreazione continue di bgpsession.
bgpsession.status.state non diventa mai
Established
Route che non vengono pubblicizzate o vengono ripetutamente pubblicizzate e ritirate.
I problemi di bilanciamento del carico di BGP potrebbero essere evidenti con problemi di
connettività ai servizi LoadBalancer.
Il problema FlatIP di BGP potrebbe essere evidente con problemi di
connettività ai pod.
Per determinare se i problemi di BGP sono causati da peer remoti che pubblicizzano troppe route, utilizza i comandi seguenti 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'ultima durata del report viene conteggiata continuamente fino a circa 10-12 secondi prima che venga visualizzato zero.
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 è in corso l'eliminazione di sessioni BGP inattive:
kubectl logs ang-controller-manager-POD_NUMBER
Sostituisci POD_NUMBER con il pod leader nel cluster.
Soluzione:
Riduci o elimina il numero di route annunciate dal peer remoto al cluster con un criterio di esportazione.
Nel cluster Google Distributed Cloud versione 1.14.2 e successive, puoi anche disabilitare la funzionalità che elabora le route ricevute utilizzando un AddOnConfiguration. Aggiungi l'argomento --disable-received-routes al container bgpd del daemonset ang-daemon.
Networking
1,14; 1,15; 1,16; 1,28
Timeout dell'applicazione causati da errori di inserimento della tabella di connessione
I cluster in esecuzione su un sistema operativo Ubuntu che utilizza kernel 5.15 o
versioni successive sono soggetti a errori di inserimento delle tabelle di
tracciamento delle connessioni netfilter (conntrack). Gli errori di inserimento possono verificarsi anche quando la tabella di connessione ha spazio per nuove voci. Gli errori sono causati da modifiche nel kernel 5.15 e versioni successive che limitano gli inserimenti delle tabelle in base alla lunghezza della catena.
Per verificare se questo problema ti riguarda, puoi controllare le statistiche del sistema di monitoraggio delle connessioni nel kernel con il seguente comando:
Se un valore chaintoolong nella risposta è un numero diverso da zero, hai riscontrato questo problema.
Soluzione alternativa
La mitigazione a breve termine è l'aumento delle dimensioni sia della tabella hash netfiler (nf_conntrack_buckets) sia della tabella di monitoraggio delle connessioni netfilter (nf_conntrack_max). Usa i seguenti comandi su ciascun nodo cluster per aumentare le dimensioni delle tabelle:
Sostituisci TABLE_SIZE con la nuova dimensione in byte. Il
valore predefinito per le dimensioni della tabella è 262144. Ti suggeriamo di impostare un valore uguale a 65.536 volte il numero di core sul nodo. Ad esempio, se il nodo ha otto core, imposta le dimensioni della tabella su 524288.
Impossibile ripristinare i backup del cluster con bmctl per alcune versioni
Ti consigliamo di eseguire il backup dei cluster prima di eseguire l'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 per gli upgrade, in cui ripristini un backup di una versione precedente.
Se il cluster è interessato, il log bmctl restore cluster
contiene il seguente errore:
Error: failed to extract image paths from profile: anthos version VERSION not supported
Soluzione:
Finché il problema non verrà risolto, ti consigliamo di seguire le istruzioni in Eseguire il backup e il ripristino dei cluster per eseguire il backup manuale dei cluster e ripristinarli manualmente, se necessario.
Networking
1,10, 1,11, 1,12, 1,13, 1.14.0-1.14.2
NetworkGatewayGroup si arresta in modo anomalo se non è presente alcun indirizzo IP nell'interfaccia
NetworkGatewayGroup non riesce a creare daemon per i nodi che non hanno interfacce sia IPv4 che IPv6. Questo fa sì che funzionalità come
BGP LB e OutboundNAT non vadano a buon fine. Se controlli i log del pod ang-node in errore nello spazio dei nomi kube-system, vengono visualizzati errori simili all'esempio seguente quando manca un indirizzo IPv6:
ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}
Nell'esempio precedente, non è presente alcun indirizzo IPv6
nell'interfaccia ens192. Errori ARP simili vengono visualizzati se nel nodo manca un indirizzo IPv4.
NetworkGatewayGroup tenta di stabilire una connessione ARP e
una connessione NDP all'indirizzo IP locale del link. Se l'indirizzo IP non esiste (IPv4 per ARP, IPv6 per NDP), la connessione non riesce e il daemon non continua.
Questo problema è stato risolto nella versione 1.14.3.
Soluzione:
Connettiti al nodo tramite SSH e aggiungi un indirizzo IPv4 o IPv6 al
link che contiene l'IP del nodo. Nell'esempio di voce di log precedente, questa interfaccia era ens192:
ip address add dev INTERFACE scope link ADDRESS
Sostituisci quanto segue:
INTERFACE: l'interfaccia del nodo, ad esempio ens192.
ADDRESS: l'indirizzo IP e la subnet mask
da applicare all'interfaccia.
Ripristino/eliminazione
1,10, 1,11, 1,12, 1.13.0-1.13.2
anthos-cluster-operator loop di arresto anomalo durante la rimozione di un nodo del piano di controllo
Quando provi a rimuovere un nodo del piano di controllo rimuovendo l'indirizzo IP
da Cluster.Spec, anthos-cluster-operator
entra in uno stato di loop di arresto anomalo che blocca qualsiasi altra operazione.
Soluzione:
Il problema è stato risolto nelle versioni 1.13.3 e 1.14.0 e successive. Sono interessate tutte le altre versioni. Esegui l'upgrade a una delle versioni corrette
Come soluzione alternativa, esegui questo comando:
IP_ADDRESS: l'indirizzo IP del nodo in 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
Errore di kubeadm join in cluster di grandi dimensioni a causa della mancata corrispondenza dei token
Quando installi cluster Google Distributed Cloud con un numero elevato di nodi, potresti
visualizzare un messaggio di errore kubeadmin join simile all'esempio seguente:
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:
Il 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, quindi ridimensiona il cluster in modo da aggiungerne altri al termine dell'installazione.
Logging e monitoraggio
1,10, 1,11, 1,12 e 1.13.0
Limite di CPU basso per metrics-server nei cluster Edge
Nei cluster Google Distributed Cloud Edge, bassi limiti di CPU per metrics-server possono causare frequenti riavvii di metrics-server. La scalabilità automatica orizzontale dei pod (HPA) non funziona
perché metrics-server non è integro.
Se il limite di CPU metrics-server è inferiore a 40m,
i cluster potrebbero essere interessati. Per controllare i metrics-server
limiti di CPU, esamina uno dei seguenti file:
Cluster Google Distributed Cloud versione 1.x-1.12:
Questo problema è stato risolto nei cluster Google Distributed Cloud versione 1.13.1 o successive. Per risolvere il problema, esegui l'upgrade dei cluster.
Una soluzione alternativa a breve termine prima di poter eseguire l'upgrade dei cluster è aumentare manualmente i limiti di CPU per metrics-server, come descritto di seguito:
Rimuovi la riga --config-dir=/etc/config e aumenta i limiti di 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 e 1,16
La connessione diretta NodePort al pod hostNetwork non funziona
La connessione a un pod abilitato con hostNetwork utilizzando il servizio NodePort non riesce quando il pod di backend si trova sullo stesso nodo di NodePort di destinazione. Questo problema interessa i servizi LoadBalancer quando vengono utilizzati con pod hostNetwork. In presenza di più backend, potrebbe verificarsi un errore di connessione sporadico.
Questo problema è causato da un bug nel programma eBPF.
Soluzione:
Quando utilizzi un servizio Nodeport, non scegliere come target il nodo su cui viene eseguito il pod di backend. Quando utilizzi il servizio LoadBalancer, assicurati che i pod hostNetwork non vengano eseguiti su nodi LoadBalancer.
Upgrade e aggiornamenti
1.12.3, 1.13.0
I cluster di amministrazione 1.13.0 non possono gestire i cluster utente 1.12.3
I cluster di amministrazione che eseguono la versione 1.13.0 non possono gestire i cluster utente che
eseguono la versione 1.12.3. Le operazioni su un cluster utente versione 1.12.3 hanno esito negativo.
Soluzione:
Esegui l'upgrade del cluster di amministrazione alla versione 1.13.1 o esegui l'upgrade 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 pool di nodi worker.
Gli upgrade alla versione 1.13.0 o successive per i cluster di amministrazione con pool di nodi worker sono bloccati. Se l'upgrade del cluster di amministrazione è bloccato, puoi verificare
se la causa sono i pool di nodi worker controllando il seguente errore nel
file upgrade-cluster.log all'interno della cartella bmctl-workspace:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.
Soluzione:
Prima di eseguire l'upgrade, sposta tutti i pool di nodi worker nei cluster utente. Per istruzioni su come aggiungere e rimuovere i pool di nodi, consulta Gestire i pool di nodi in un cluster.
Upgrade e aggiornamenti
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16 e 1,28
Errori durante l'aggiornamento delle risorse utilizzando kubectl apply
Se aggiorni risorse esistenti, come le risorse personalizzate ClientConfig o Stackdriver utilizzando kubectl apply, il controller potrebbe restituire un errore o ripristinare l'input e le modifiche pianificate.
Ad esempio, potresti provare a modificare la risorsa personalizzata Stackdriver
come segue, recuperando prima la risorsa e poi applicando una versione aggiornata:
Abilita le funzionalità o aggiorna la configurazione nel file YAML.
Applica nuovamente il file YAML aggiornato:
kubectl apply -f stackdriver.yaml
Il passaggio finale per kubectl apply è quello in cui potresti riscontrare problemi.
Soluzione:
Non utilizzare kubectl apply per apportare modifiche alle risorse
esistenti. Utilizza invece kubectl edit o kubectl patch
come mostrato nei seguenti esempi:
I blocchi di backlog danneggiati causano
un arresto anomalo di stackdriver-log-forwarder
L'arresto anomalo di stackdriver-log-forwarder in loop se tenta di elaborare un blocco di backlog danneggiato. Nei log dei container vengono mostrati i seguenti errori di esempio:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
Quando si verifica questo arresto anomalo, non puoi visualizzare i log in Cloud Logging.
Soluzione:
Per risolvere questi errori, completa i seguenti passaggi:
Identifica i blocchi del 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/ è errato. Devi rimuovere ogni file *.flb con un controllo del formato non riuscito.
Termina i pod in esecuzione per stackdriver-log-forwarder:
Il riavvio di Dataplane V2 (anetd) sui cluster può causare l'impossibilità di collegare le VM esistenti a una rete non pod
Nei cluster con più NIC, il riavvio di Dataplane V2 (anetd) può impedire alle macchine virtuali di collegarsi alle reti. Nei log dei pod anetd potrebbe essere osservato un errore simile al seguente:
could not find an allocator to allocate the IP of the multi-nic endpoint
Soluzione:
Come soluzione rapida, puoi riavviare la VM. Per evitare che il problema si ripeta, esegui l'upgrade del cluster alla versione 1.14.1 o successiva.
Operazione
1.13, 1.14.0 e 1.14.1
gke-metrics-agent non ha limiti di memoria sui cluster del profilo perimetrale
A seconda del carico di lavoro del cluster, gke-metrics-agent potrebbe utilizzare più di 4608 MiB di memoria. Questo problema riguarda solo i cluster di profili Google Distributed Cloud Edge. I cluster del profilo predefinito non sono interessati.
Soluzione:
Esegui l'upgrade del cluster alla versione 1.14.2 o successiva.
Installazione
1,12, 1,13
La creazione del cluster potrebbe non riuscire a causa di condizioni di gara
Quando crei cluster utilizzando kubectl, a causa delle condizioni di gara, il controllo preflight potrebbe non terminare. Di conseguenza, in alcuni casi la creazione del cluster potrebbe non riuscire.
Il riconciliatore dei controlli preflight crea un SecretForwarder
per copiare il secret ssh-key predefinito nello spazio dei nomi di destinazione.
In genere, il controllo preflight si avvale dei riferimenti del proprietario e delle riconciliazioni una volta completato SecretForwarder. Tuttavia, in rari casi, il riferimento del proprietario dell'oggetto SecretForwarder può perdere il riferimento al controllo preflight, causando il blocco del controllo preflight. Di conseguenza, la creazione del cluster non va a buon fine. Per continuare la riconciliazione per il controllo preflight basato su controller, elimina il pod dell'operatore del cluster o la risorsa preflight-check. Quando elimini la risorsa preflight-check, ne viene creata un'altra e la riconciliazione continua. In alternativa, puoi eseguire l'upgrade dei cluster esistenti (creati con una versione precedente) a una versione fissa.
Networking
1,9, 1,10, 1,11, 1,12, 1,13, 1,14 e 1,15
Gli indirizzi IP riservati non vengono rilasciati quando si utilizza il plug-in di località con la funzionalità multi-NIC
Nella funzionalità multi-Nic, se utilizzi il plug-in di localizzazione di CNI e l'operazione DEL CNI per eliminare un'interfaccia di rete per un pod, alcuni indirizzi IP riservati potrebbero non essere rilasciati correttamente. Questo accade quando l'operazione CNI DEL viene interrotta.
Puoi verificare le prenotazioni degli indirizzi IP inutilizzati dei pod eseguendo questo comando:
kubectl get ippools -A --kubeconfig KUBECONFIG_PATH
Soluzione:
Elimina manualmente gli indirizzi IP (ippool) che non vengono utilizzati.
Installazione
1.10; 1.11.0; 1.11.1; 1.11.2
Il rilevatore dei problemi del nodo non funziona nel cluster utente 1.10.4
Il rilevatore di problemi relativi ai nodi potrebbe non riuscire nei cluster utente versione 1.10.x,
mentre i cluster di amministrazione versione 1.11.0, 1.11.1 o 1.11.2
gestiscono i cluster utente 1.10.x. Quando si verifica un errore del rilevatore di problemi con i nodi, il log viene aggiornato con il seguente messaggio di errore:
Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.
Soluzione alternativa
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 dimensione di maschera CIDR pod di 24
Nella release 1.14, l'impostazione maxPodsPerNode non viene presa in considerazione per i cluster in modalità Isola, pertanto ai nodi viene assegnata una dimensione di maschera CIDR pod di 24 (256 indirizzi IP).nQuesto potrebbe causare l'esaurimento degli indirizzi IP dei pod nel cluster prima del previsto. Ad esempio, se il cluster ha una dimensione della maschera CIDR dei pod pari a 22; a ogni nodo verrà assegnata una maschera CIDR pod di 24 e il cluster potrà supportare solo fino a quattro nodi. Il cluster potrebbe inoltre riscontrare instabilità della rete in un periodo di abbandono dei pod elevato quando maxPodsPerNode è impostato su 129 o su un valore superiore e l'overhead non è sufficiente nel CIDR dei pod per ciascun nodo.
Se il tuo cluster è interessato, il pod anetd segnala il seguente errore quando aggiungi un nuovo nodo al cluster e non è disponibile podCIDR:
error="required IPv4 PodCIDR not available"
Soluzione alternativa
Per risolvere il problema:
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 piano di controllo e aggiungili di nuovo, preferibilmente uno alla volta, per evitare tempi di inattività del cluster.
Upgrade e aggiornamenti
1.14.0, 1.14.1
Errore di rollback dell'upgrade del cluster
Il rollback di un upgrade potrebbe non riuscire per i cluster della versione 1.14.0 o 1.14.1.
Se esegui l'upgrade di un cluster dalla versione 1.14.0 alla versione 1.14.1 e poi provi a eseguire il rollback alla versione 1.14.0 utilizzando il comando bmctl restore cluster, potrebbe essere restituito un errore come nell'esempio seguente:
I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable
Soluzione:
Elimina tutte le risorse healthchecks.baremetal.cluster.gke.io nello spazio dei nomi del cluster ed esegui nuovamente il comando bmctl restore
cluster:
Elenca tutte le healthchecks.baremetal.cluster.gke.io
risorse:
kubectl get healthchecks.baremetal.cluster.gke.io \
--namespace=CLUSTER_NAMESPACE \
--kubeconfig=ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster.
ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
Elimina tutte le healthchecks.baremetal.cluster.gke.io
risorse elencate nel passaggio precedente:
Sostituisci HEALTHCHECK_RESOURCE_NAME con
il nome delle risorse del 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 dai loro
indirizzi IP esterni.
Questo problema è stato risolto nella versione 1.12.1.
Soluzione:
In cilium-config ConfigMap, imposta enable-415 su "true", quindi riavvia i pod anetd.
Upgrade e aggiornamenti
1.13.0, 1.14
Gli upgrade sul posto dalla versione 1.13.0 alla versione 1.14.x non terminano mai
Quando provi a eseguire un upgrade in loco da 1.13.0 a 1.14.x utilizzando bmctl 1.14.0 e il flag
--use-bootstrap=false, l'upgrade non termina mai.
Un errore 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:
Esegui l'upgrade alla versione 1.13.1 prima di eseguire l'upgrade alla versione 1.14.x. Un upgrade in loco da 1.13.0 a 1.13.1 dovrebbe funzionare. In alternativa, esegui l'upgrade da 1.13.0 a 1.14.x senza il flag --use-bootstrap=false.
Upgrade e aggiornamenti, Sicurezza
1.13 e 1.14
I cluster aggiornati alla versione 1.14.0 perdono le incompatibilità principali
I nodi del piano di controllo richiedono una delle due incompatibilità specifiche per impedire la pianificazione dei pod dei carichi di lavoro al loro interno. Quando esegui l'upgrade dei cluster GKE dalla versione 1.13 alla versione 1.14.0, i nodi del piano di controllo perdono le seguenti incompatibilità obbligatorie:
node-role.kubernetes.io/master:NoSchedule
node-role.kubernetes.io/master:PreferNoSchedule
Questo problema non causa errori di upgrade, ma potrebbero iniziare i pod che non dovrebbero essere eseguiti sui nodi del piano di controllo. Questi pod dei carichi di lavoro possono sovraccaricare i nodi del piano di controllo e portare all'instabilità del cluster.
Determinare se il problema ti riguarda
Per trovare i nodi del piano di controllo, utilizza il seguente comando:
kubectl get node -l 'node-role.kubernetes.io/control-plane' \
-o name --kubeconfig KUBECONFIG_PATH
Per controllare l'elenco delle incompatibilità su un nodo, utilizza il seguente comando:
Se nessuna delle incompatibilità richieste è elencata, significa che sei interessato.
Soluzione alternativa
Per ripristinare la funzione corretta, segui questi passaggi per ciascun nodo del piano di controllo del cluster della versione 1.14.0 interessato. Questi passaggi si riferiscono all'incompatibilità
node-role.kubernetes.io/master:NoSchedule e ai pod correlati. Se prevedi che i nodi del piano di controllo utilizzino l'incompatibilità PreferNoSchedule, modifica i passaggi di conseguenza.
Visualizza i passaggi per la soluzione alternativa
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 VM su GDC
1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28; 1,29
La creazione della VM non riesce a intermittenza con errori di caricamento
La creazione di una nuova macchina virtuale (VM) con il comando kubectl virt create vm
ha esito negativo con minore frequenza durante il caricamento delle immagini. Il problema riguarda sia le VM Linux che le VM 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 alternativa
Riprova a utilizzare 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 manualmente il deployment dei componenti della raccolta gestita nello spazio dei nomi gmp-system dei tuoi cluster della versione 1.11, le risorse associate non vengono conservate quando esegui l'upgrade alla versione 1.12.
A partire dai cluster della versione 1.12.0, i componenti di Managed Service
per Prometheus nello spazio dei nomi gmp-system e
le relative definizioni delle risorse personalizzate vengono gestiti da
stackdriver-operator con il campo enableGMPForApplications. Per impostazione predefinita, il campo enableGMPForApplications è true, quindi se esegui manualmente il deployment dei componenti Managed Service per Prometheus nello spazio dei nomi prima di eseguire l'upgrade alla versione 1.12, le risorse vengono eliminate da stackdriver-operator.
Soluzione alternativa
Per conservare le risorse di raccolta gestite manualmente:
Esegui il backup di tutte le risorse personalizzate di PodMonitoring esistenti.
Esegui di nuovo il deployment delle risorse personalizzate di PodMonitoring sul cluster di cui è stato eseguito l'upgrade.
Upgrade e aggiornamenti
1,13
Alcuni cluster della versione 1.12 con il runtime del container Docker non possono eseguire l'upgrade alla versione 1.13
Se in un cluster della versione 1.12 che utilizza il runtime del container Docker manca la seguente annotazione, non può eseguire l'upgrade alla versione 1.13:
Se questo 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.
È più probabile che questo si verifichi con i cluster Docker della versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11, poiché l'upgrade non richiede l'annotazione per mantenere il runtime dei container Docker. In questo caso, i cluster non dispongono dell'annotazione quando viene eseguito l'upgrade alla versione 1.13. Tieni presente che a partire dalla versione 1.13, containerd è l'unico runtime del container consentito.
Soluzione:
Se riscontri questo problema, aggiorna la risorsa del cluster con l'annotazione mancante. Puoi aggiungere l'annotazione mentre
l'upgrade è in esecuzione o dopo l'annullamento e prima di riprovare.
Installazione
1,11
bmctl viene chiuso 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 si chiude in anticipo e scrive nei log errori simili ai seguenti:
Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster
Soluzione alternativa
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:
Visualizza i passaggi per la soluzione alternativa
Per eliminare gli artefatti del cluster e reimpostare la macchina nodo, esegui questo comando:
bmctl reset -c USER_CLUSTER_NAME
Per avviare l'operazione di creazione del cluster, esegui questo comando:
Il flag --keep-bootstrap-cluster è importante in caso di errore del comando.
Se il comando di creazione del cluster ha esito positivo, puoi saltare i passaggi rimanenti. In caso contrario, continua.
Esegui questo comando per ottenere la versione del cluster di bootstrap:
Questo errore è benigno e puoi tranquillamente ignorarlo.
Installazione
1,10, 1,11 e 1,12
La creazione del cluster non riesce quando si utilizzano più NIC, containerd e proxy HTTPS
La creazione del cluster non va a buon fine quando si ha la seguente combinazione di condizioni:
Il cluster è configurato in modo da utilizzare containerd come
runtime del container (nodeConfig.containerRuntime impostato su
containerd nel file di configurazione del cluster, l'impostazione predefinita
per Google Distributed Cloud versione 1.13 e successive).
Il cluster è configurato in modo da fornire più interfacce di rete, con più NIC, per i pod (clusterNetwork.multipleNetworkInterfaces impostato su true nel file di configurazione del cluster).
Il cluster è configurato per l'utilizzo di un proxy (spec.proxy.url è specificato nel file di configurazione del cluster). Anche se la creazione del cluster non riesce, questa impostazione viene propagata quando tenti di creare un cluster. Potresti visualizzare questa impostazione del proxy come una variabile di ambiente HTTPS_PROXY o nella configurazione di containerd
(/etc/systemd/system/containerd.service.d/09-proxy.conf).
Soluzione alternativa
Aggiungi i CIDR del servizio (clusterNetwork.services.cidrBlocks)
alla variabile di ambiente NO_PROXY su tutte le macchine nodo.
Installazione
1,10, 1,11 e 1,12
Errore sui sistemi con impostazione umask restrittiva
Con la release 1.10.0 di Google Distributed Cloud è stata introdotta 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 può causare errori di installazione o upgrade su sistemi con un'impostazione umask più restrittiva di 0077.
Soluzione alternativa
Reimposta i nodi del piano di controllo e modifica l'impostazione umask
in 0022 su tutte le macchine del piano di controllo. Dopo aver aggiornato le macchine, riprova a eseguire l'installazione.
In alternativa, puoi modificare le autorizzazioni della directory e dei file di /etc/kubernetes sulle macchine del piano di controllo per l'installazione o l'upgrade per procedere.
Rendi leggibili /etc/kubernetes e tutte le relative sottodirectory: chmod o+rx.
Rendi leggibili da tutto il mondo tutti i file di proprietà dell'utente root nella
directory (in modo ricorsivo) /etc/kubernetes (chmod o+r). Escludi i file di chiavi privati (.key) da queste modifiche perché sono già stati creati con proprietà e autorizzazioni corrette.
Il
gruppo di controllo v2 (cgroup v2) non è supportato nei cluster Google Distributed Cloud 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 alternativa
Se il sistema utilizza cgroup v2, esegui l'upgrade del cluster alla versione 1.14.
Installazione
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28 e 1,29
Controlli preflight e credenziali dell'account di servizio
Per le installazioni attivate da cluster di amministrazione o ibridi (in altre parole, cluster non creati con bmctl, come i cluster utente), il controllo preflight non verifica le credenziali dell'account di servizio Google Cloud o le autorizzazioni associate.
Installazione
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28 e 1,29
Installazione su vSphere
Quando installi i cluster Google Distributed Cloud sulle VM vSphere, devi disattivare i flag
tx-udp_tnl-segmentation e
tx-udp_tnl-csum-segmentation. Questi flag sono
relativi all'offload della segmentazione hardware eseguita dal driver vSphere
VMXNET3 e non funzionano con il tunnel GENEVE dei cluster Google Distributed Cloud.
Soluzione alternativa
Esegui questo comando su ciascun nodo per verificare i valori attuali di questi flag:
ethtool -k NET_INTFC | grep segm
Sostituisci NET_INTFC con l'interfaccia di rete associata all'indirizzo IP del nodo.
La risposta deve contenere voci 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, attivali e disattivali 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 applicata durante i riavvii. Configura gli script di avvio in modo da impostare esplicitamente questi flag all'avvio del sistema.
Upgrade e aggiornamenti
1,1
bmctl non può creare, aggiornare o reimpostare i cluster utente con versioni precedenti
L'interfaccia a riga di comando bmctl non può creare, aggiornare o reimpostare un cluster utente con una versione secondaria inferiore, indipendentemente dalla versione del cluster di amministrazione. Ad esempio, non puoi utilizzare bmctl con una versione di
1.N.X per reimpostare un cluster utente con versione
1.N-1.Y, anche se anche il cluster di amministrazione ha la versione
1.N.X.
Se hai riscontrato questo problema, dovresti vedere log simili ai seguenti 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:
Utilizza kubectl per creare, modificare o eliminare la risorsa personalizzata del cluster utente all'interno del cluster di amministrazione.
La possibilità di eseguire l'upgrade dei cluster utente non è interessata.
Upgrade e aggiornamenti
1,12
Gli upgrade del cluster alla versione 1.12.1 potrebbero bloccarsi
L'upgrade dei cluster alla versione 1.12.1 a volte si blocca perché il server API non è più disponibile. Questo problema riguarda tutti i tipi di cluster e tutti i sistemi operativi supportati. Quando si verifica questo problema, il comando bmctl
upgrade cluster può avere esito negativo in più punti, anche durante la seconda fase dei controlli preflight.
Soluzione alternativa
Puoi controllare i log dell'upgrade per capire se questo problema ti riguarda. I log dell'upgrade si trovano in
/baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP per impostazione predefinita.
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 (errori ripetuti
indicano che il problema ti riguarda):
Prima di ritentare di eseguire l'upgrade del cluster alla versione 1.12.1, HAProxy e KeepaLive devono essere in esecuzione su ciascun nodo del piano di controllo. Utilizza l'
interfaccia a riga di comando crictl su ciascun nodo per verificare se i container haproxy e keepalived sono in esecuzione:
Se HAProxy o KeepaLive non è in esecuzione su un nodo, riavvia
kubelet sul nodo:
systemctl restart kubelet
Upgrade e aggiornamenti, runtime VM su GDC
1,11, 1,12
L'upgrade dei cluster alla versione 1.12.0 o successiva non riesce quando
è abilitato il runtime VM su GDC
Nella versione 1.12.0 dei cluster Google Distributed Cloud, viene eseguita la migrazione di tutte le risorse relative al runtime VM su GDC nello spazio dei nomi vm-system per supportare meglio la release GA di VM Runtime su GDC. Se hai abilitato il runtime VM su GDC in un cluster della versione 1.11.x o precedente, l'upgrade alla versione 1.12.0 o successiva non riesce a meno che non disabiliti prima il runtime VM in GDC. Se si verifica 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
L'upgrade è bloccato a error during manifests operations
In alcune situazioni, gli upgrade del cluster non vengono completati e l'interfaccia a riga di comando bmctl non risponde. Questo problema può essere causato da un aggiornamento errato della risorsa. Per determinare se il problema ti riguarda e per correggerlo, controlla i log di 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 sintomo di una risorsa aggiornata in modo errato, dove
{RESOURCE_NAME} è il nome della risorsa del problema.
Soluzione alternativa
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 e 1,12
Gli upgrade sono bloccati per i cluster con funzionalità che utilizzano il gateway di rete per GDC
Gli upgrade dei cluster da 1.10.x a 1.11.x non riescono per i cluster che utilizzano
il gateway NAT in uscita o il
bilanciamento del carico in bundle con BGP. Entrambi queste funzionalità utilizzano Network Gateway per GDC. Gli upgrade del cluster
si bloccano al messaggio della riga di comando Waiting for upgrade to complete...
e agli errori dei log anthos-cluster-operator
come i seguenti:
apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...
Soluzione alternativa
Per sbloccare l'upgrade, esegui questi comandi sul cluster di cui stai eseguendo l'upgrade:
Nodi contrassegnati come non pianificabili se non utilizzi la procedura in modalità di manutenzione
Se esegui cluster della versione 1.12.0 (anthosBareMetalVersion: 1.12.0) o versioni precedenti e utilizzi manualmente kubectl cordon su un nodo, Google Distributed Cloud potrebbe annullare il contrassegno del nodo prima di tutto ciò di cui hai bisogno, nel tentativo di riconciliare lo stato previsto.
Soluzione alternativa
Per i cluster della versione 1.12.0 e precedenti, utilizza la
modalità di manutenzione per
contrassegnare e svuotare i nodi in modo sicuro.
Nella versione 1.12.1 (anthosBareMetalVersion: 1.12.1) o successive, Google Distributed Cloud non contrassegna inaspettatamente i 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 la versione del cluster di amministrazione è 1.11 e utilizza un mirror del registro, non può gestire i cluster utente che si trovano in una versione secondaria inferiore. Questo problema riguarda le operazioni di reimpostazione, aggiornamento ed upgrade sul cluster utente.
Per determinare se questo problema ti riguarda, controlla nei log le operazioni del cluster, come creazione, upgrade o reimpostazione. Questi log si trovano nella cartella bmctl-workspace/CLUSTER_NAME/ per impostazione predefinita. Se hai riscontrato questo problema, i log contengono il seguente messaggio di errore:
flag provided but not defined: -registry-mirror-host-to-endpoints
Operazione
1,10, 1,11
Secret kubeconfig sovrascritto
Il comando bmctl check cluster, se eseguito sui cluster utente, sovrascrive il secret kubeconfig del cluster utente con il cluster di amministrazione kubeconfig. Se sovrascrivi il file, le operazioni standard del cluster, come l'aggiornamento e l'upgrade, non vanno a buon fine per i cluster utente interessati. Questo problema si applica alle versioni 1.11.1 e precedenti del cluster Google Distributed Cloud.
Per determinare se questo problema interessa un cluster utente, esegui questo comando:
ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
USER_CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi dei cluster Google Distributed Cloud 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 verificare.
Se il nome del cluster nell'output (vedi contexts.context.cluster nel seguente output di esempio) è il nome del cluster di amministrazione, il cluster utente specificato è interessato.
I passaggi seguenti ripristinano la funzione in un cluster utente interessato (USER_CLUSTER_NAME):
Individua il file kubeconfig del cluster utente. Google Distributed Cloud 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 cluster utente kubeconfig corretto:
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 per il 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:
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28 e 1,29
Acquisizione di uno snapshot come utente di accesso non root
Se utilizzi containerd come runtime del container, l'esecuzione di snapshot come
utente non root richiede che /usr/local/bin si trovi nel PATH dell'utente.
In caso contrario, l'operazione non andrà a buon fine e verrà visualizzato un errore crictl: command not found.
Se non hai eseguito l'accesso come utente root, viene utilizzato sudo per eseguire i comandi degli snapshot. Il PATH sudo può essere diverso dal
profilo principale e non può contenere /usr/local/bin.
Soluzione alternativa
Aggiorna secure_path in /etc/sudoers per
includere /usr/local/bin. In alternativa, crea un link simbolico
per crictl in un'altra directory /bin.
Logging e monitoraggio
1,1
stackdriver-log-forwarder ha [parser:cri] invalid
time format log degli avvisi
[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:
Visualizza i passaggi per la soluzione alternativa
Esegui l'upgrade del cluster alla versione 1.11.0 o successiva.
Se non riesci a eseguire immediatamente l'upgrade dei cluster, segui questi passaggi per aggiornare l'espressione regolare di analisi CRI:
Per evitare il ripristino delle seguenti modifiche, fare lo scale down di
stackdriver-operator:
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
Per le versioni dei cluster Google Distributed Cloud dalla 1.10 alla 1.15, alcuni clienti hanno riscontrato una fatturazione inaspettatamente elevata per Metrics volume nella pagina Fatturazione. Questo problema ti riguarda solo quando si applicano tutte le seguenti circostanze:
Il monitoraggio delle applicazioni è abilitato (enableStackdriverForApplications=true)
I pod di applicazione hanno l'annotazione prometheus.io/scrap=true
Per confermare se questo problema ti riguarda,
elenca le
metriche definite dall'utente. Se visualizzi la fatturazione per metriche indesiderate, questo problema riguarda il tuo caso.
Soluzione alternativa
Se riscontri questo problema, ti consigliamo di eseguire l'upgrade dei cluster alla versione 1.12 e di passare alla nuova soluzione di monitoraggio delle applicazioni managed-service-for-prometheus che risolvono il problema:
Flag separati per controllare la raccolta dei log dell'applicazione rispetto alle metriche dell'applicazione
Google Cloud Managed Service in bundle per Prometheus
Se non puoi eseguire l'upgrade alla versione 1.12, segui questi passaggi:
Trova i pod e i servizi di origine che hanno 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 rese persistenti
In casi estremi, un'elevata densità di pod può generare 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 e 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.
Il server delle metriche non viene subito interessato, ma al successivo riavvio riprende il ConfigMap ripristinato ed è di nuovo vulnerabile a un overhead eccessivo.
Soluzione alternativa
Per 1.11.x, puoi creare uno script per la modifica di ConfigMap ed eseguirla insieme
ad aggiornamenti o upgrade al cluster. Per la versione 1.12 e versioni successive, contatta l'assistenza.
Logging e monitoraggio
1,11, 1,12
Le metriche deprecate influiscono sulla dashboard di Cloud Monitoring
Diverse metriche di Google Distributed Cloud sono state deprecate e, a partire dalla release 1.11 di Google Distributed Cloud, i dati per queste metriche deprecate non vengono più raccolti. Se utilizzi queste metriche in uno dei criteri di avviso, non saranno disponibili dati per attivare la condizione di avviso.
La seguente tabella elenca le singole metriche che sono state
deprecate e la metrica che le sostituisce.
Nelle versioni dei cluster Google Distributed Cloud precedenti alla 1.11, il file di definizione dei criteri per l'avviso Anthos on baremetal node cpu usage exceeds
80 percent (critical) consigliato utilizza le metriche deprecate. Il file di definizione JSON node-cpu-usage-high.json viene aggiornato per le release 1.11.0 e successive.
Soluzione alternativa
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 dello stato del nodo del cluster Anthos.
Fai clic sulla scheda Libreria di esempio e reinstalla la dashboard dello stato dei nodi cluster Anthos.
stackdriver-log-forwarder ha CrashloopBackOff
errori
In alcune situazioni, l'agente di logging fluent-bit può bloccarsi durante l'elaborazione di blocchi danneggiati. Quando l'agente Logging non è in grado di bypassare i blocchi danneggiati, potresti notare che stackdriver-log-forwarder continua ad arrestarsi in modo anomalo con un errore CrashloopBackOff. Se riscontri questo problema, i 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:
Eseguire la pulizia dei blocchi del buffer per Stackdriver Log Forwarder.
Nota: nei comandi seguenti, sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.
Questi log degli errori possono essere ignorati tranquillamente in quanto le metriche a cui fanno riferimento 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 Google Distributed Cloud potrebbero riscontrare interruzioni nell'esportazione normale e continua delle metriche oppure metriche mancanti su alcuni nodi. Se questo problema riguarda i tuoi cluster, potresti notare (almeno) lacune nei dati per le seguenti metriche:
Il comando trova cpu: 50m se le modifiche sono state
applicate.
Networking
1,1
Più gateway predefiniti interrompono la connettività agli endpoint esterni
Avere più gateway predefiniti in un nodo può causare l'interruzione della
connettività dall'interno di un pod a endpoint esterni, come
google.com.
Per determinare se hai riscontrato questo problema, esegui questo comando sul nodo:
ip route show
Più istanze di default nella risposta indicano
che il problema ti riguarda.
Networking
1,12
Le modifiche alle risorse personalizzate di networking sui cluster utente vengono sovrascritte
I cluster Google Distributed Cloud versione 1.12.x non ti impediscono di modificare manualmente le risorse personalizzate di networking nel tuo cluster utente. Google Distributed Cloud riconcilia le risorse personalizzate nei cluster utente con quelle personalizzate nel tuo cluster di amministrazione durante gli upgrade del cluster. Questa riconciliazione sovrascrive eventuali modifiche apportate direttamente alle risorse personalizzate di networking nel cluster utente. Le risorse personalizzate di networking devono essere modificate solo nel cluster di amministrazione, ma i cluster della versione 1.12.x non applicano questo requisito.
Puoi modificare queste risorse personalizzate nel cluster di amministrazione e il passaggio di riconciliazione applica le modifiche ai cluster utente.
Soluzione alternativa
Se hai modificato una qualsiasi 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 1.13.0 e successive dei cluster Google Distributed Cloud non ti consentono di modificare direttamente le risorse personalizzate di networking sui tuoi cluster utente.
Networking
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16 e 1,28
Errori di connettività dei pod e filtro del percorso inverso
Google Distributed Cloud configura il filtro del percorso inverso sui nodi per disabilitare la convalida dell'origine (net.ipv4.conf.all.rp_filter=0). Se l'impostazione rp_filter viene modificata in 1 o 2, i pod avranno esito negativo a causa di timeout delle comunicazioni fuori nodo.
Il filtro del percorso inverso è impostato su rp_filter nella cartella di configurazione IPv4 (net/ipv4/conf/all). Questo valore può anche essere sostituito da sysctl, che archivia le impostazioni di filtro del percorso inverso in un file di configurazione della sicurezza di rete, come /etc/sysctl.d/60-gce-network-security.conf.
Soluzione alternativa
Puoi ripristinare la connettività dei pod eseguendo una delle seguenti soluzioni alternative:
Imposta di nuovo il valore per net.ipv4.conf.all.rp_filter su
0 manualmente, quindi esegui sudo sysctl -p per applicare
la modifica.
Oppure
Riavvia il pod anetd per reimpostare
net.ipv4.conf.all.rp_filter su 0. Per riavviare il pod anetd, utilizza i seguenti comandi per individuare ed eliminare il pod anetd e al suo posto verrà avviato un nuovo pod anetd:
Dopo aver eseguito una delle due soluzioni alternative, verifica che il valore net.ipv4.conf.all.rp_filter sia impostato su 0 eseguendo sysctl net.ipv4.conf.all.rp_filter su ciascun nodo.
Networking
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28 e 1,29
Indirizzi IP del cluster di bootstrap (kind) e indirizzi IP dei nodi cluster che si sovrappongono
192.168.122.0/24 e 10.96.0.0/27 sono i
CIDR predefiniti di pod e servizi utilizzati dal cluster di bootstrap (kind).
I controlli preflight non andranno a buon fine se si sovrappongono agli indirizzi IP delle macchine dei nodi cluster.
Soluzione alternativa
Per evitare il conflitto, puoi passare i flag
--bootstrap-cluster-pod-cidr e
--bootstrap-cluster-service-cidr a bmctl
per specificare valori diversi.
Sistema operativo
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16 e 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. A causa dell'EOL, yum repository hanno smesso di funzionare per CentOS, il che causa la mancata riuscita delle operazioni di creazione e upgrade del cluster. Questo vale per tutte le versioni supportate di CentOS e
interessa tutte le versioni dei cluster Google Distributed Cloud.
Soluzione alternativa
Visualizza i passaggi per la soluzione alternativa
Come soluzione alternativa, esegui i comandi seguenti 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 e 1,28
Il container non può scrivere in VOLUME definito in Dockerfile
con containerd e SELinux
Se utilizzi containerd come runtime dei container e SELinux nel sistema operativo è abilitato, il valore 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 hai riscontrato questo problema, esegui questo comando sul nodo che ospita il container problematico:
ausearch -m avc
Se hai riscontrato questo problema, viene visualizzato un errore denied come il seguente:
Per risolvere il problema, apporta una delle seguenti modifiche:
Disattiva SELinux.
Non utilizzare la funzionalità VOLUME in Dockerfile.
Upgrade e aggiornamenti
1,10, 1,11 e 1,12
Il rilevatore di problemi con i nodi non viene abilitato per impostazione predefinita dopo gli upgrade del cluster
Quando esegui l'upgrade dei cluster Google Distributed Cloud, il rilevatore di problemi dei nodi non è abilitato per impostazione predefinita. Questo problema riguarda gli upgrade dalla release 1.10 alla
1.12.1 ed è stato risolto nella release 1.12.2.
Soluzione:
Per abilitare il rilevatore di problemi dei nodi:
Verifica che il servizio node-problem-detector systemd sia 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, significa che il rilevatore di problemi del nodo non è in esecuzione sul nodo.
Per abilitare il rilevatore di problemi dei nodi, utilizza il comando kubectl edit e modifica il ConfigMap node-problem-detector-config. Per maggiori
informazioni, consulta
Rilevamento dei problemi
dei nodi.
Operazione
1,9, 1,10
Il backup del cluster non riesce quando si utilizza un accesso non root
Il comando bmctl backup cluster non riesce se
nodeAccess.loginUser è impostato su un nome utente non root.]
Soluzione:
Questo problema si applica alle versioni 1.9.x, 1.10.0 e 1.10.1 ed è stato risolto nella versione 1.10.2 e successive.
Networking
1,10, 1,11 e 1,12
I servizi del bilanciatore del carico non funzionano con i container sulla rete host del piano di controllo
In anetd esiste un bug per cui i pacchetti vengono eliminati per i servizi LoadBalancer se i pod di backend sono entrambi in esecuzione sul nodo del piano di controllo e utilizzano il campo hostNetwork: true nella specifica del container.
Il bug non è presente nella versione 1.13 o successive.
Soluzione:
Le seguenti soluzioni alternative possono essere utili se utilizzi un servizio LoadBalancer
supportato dai pod hostNetwork:
Eseguile sui nodi worker (non sui nodi del piano di controllo).
Il pod anthos-version-$version$ orfano non riesce a eseguire il pull dell'immagine
L'upgrade del cluster da 1.12.x a 1.13.x potrebbe osservare un pod anthos-version-$version$ non riuscito con errore ImagePullBackOff.
Ciò accade perché viene eseguito l'upgrade della race condition di anthos-cluster-operator e non dovrebbe influire sulle normali funzionalità del cluster.
Il bug non è presente dopo la versione 1.13 o successive.
Soluzione:
Elimina il job del programma di installazione dinamico della versione entro il giorno
kubectl delete job anthos-version-$version$ -n kube-system
Upgrade e aggiornamenti
1,13
Non è possibile eseguire l'upgrade dei cluster 1.12 dalla versione 1.11 alla versione 1.13.0
Non è possibile eseguire l'upgrade dei cluster della versione 1.12 dalla versione 1.11 alla versione 1.13.0. Questo problema di upgrade non si applica ai cluster creati con la 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 viene visualizzato il seguente messaggio di errore, significa che sei interessato.
Utilizzo elevato della CPU per stackdriver-operator
Si è verificato un problema in stackdriver-operator che causa un consumo di tempo di CPU più elevato del normale. L'utilizzo normale della CPU è inferiore a 50
milliCPU (50m) per stackdriver-operator in stato
inattivo. La causa è una mancata corrispondenza delle risorse dei certificati che
stackdriver-operator applica con le aspettative di
cert-manager. Questa mancata corrispondenza causa una race condition tra
cert-manager e stackdriver-operator
nell'aggiornamento di queste risorse.
Questo problema potrebbe comportare una riduzione delle prestazioni sui cluster con disponibilità della CPU limitata.
Soluzione:
Finché non potrai eseguire l'upgrade a una versione che ha corretto il bug, utilizza la seguente soluzione alternativa:
Per fare lo scale down temporaneo di stackdriver-operator a 0 repliche, applica una risorsa personalizzata AddonConfiguration:
Lo scraping delle metriche basate sulle annotazioni non funziona
Nella release secondaria Google Distributed Cloud 1.16, il campo enableStackdriverForApplications nella specifica della risorsa personalizzata stackdriver è deprecato. Questo campo è sostituito da due campi, enableCloudLoggingForApplications e enableGMPForApplications, nella risorsa personalizzata Stackdriver.
Ti consigliamo di utilizzare Google Cloud Managed Service per Prometheus per monitorare i carichi di lavoro. Utilizza il campo enableGMPForApplications per abilitare questa funzionalità.
Se ti affidi alla raccolta di metriche attivata dalle annotazioni prometheus.io/scrape sui tuoi carichi di lavoro, puoi utilizzare il flag di gate delle funzionalità annotationBasedApplicationMetrics per mantenere il comportamento precedente. Tuttavia, esiste un problema che
impedisce a annotationBasedApplicationMetrics di funzionare
correttamente, impedendo la raccolta delle metriche dalle applicazioni in
Cloud Monitoring.
Soluzione:
Per risolvere questo problema, esegui l'upgrade del cluster alla versione 1.16.2 o successiva.
La raccolta delle metriche dei carichi di lavoro basata sulle annotazioni abilitata dalla
porta delle funzionalità annotationBasedApplicationMetrics raccoglie
le metriche per gli oggetti che hanno l'annotazione
prometheus.io/scrape. Molti sistemi software con origini 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 sorpresi dagli addebiti delle metriche in Cloud Monitoring.
Dashboard ed elimina la dashboard dello stato del nodo del cluster Anthos.