Questa pagina elenca tutti i problemi noti relativi a Google Distributed Cloud Virtual for Bare Metal. Per filtrare i problemi noti per una versione o una categoria di prodotto, seleziona i filtri dai seguenti menu a discesa.
Seleziona la versione di GDCV per Bare Metal:
Seleziona la categoria del problema:
In alternativa, cerca il problema:
Categoria
Versioni identificate
Problema e soluzione alternativa
Ripristino/eliminazione
1.29.0
La reimpostazione del cluster utente non riesce a eliminare lo spazio dei nomi
Durante l'esecuzione di bmctl reset cluster -c ${USER_CLUSTER},
dopo il completamento di tutti i job correlati, il comando non riesce a eliminare
lo spazio dei nomi del cluster utente. Lo spazio dei nomi del cluster utente è bloccato nello stato Terminating. Al termine, il timeout della reimpostazione del cluster viene restituito e restituisce un errore.
Soluzione alternativa:
Per rimuovere lo spazio dei nomi e completare la reimpostazione del cluster utente, segui questi passaggi:
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 è completa.
Configurazione, installazione, sicurezza
Da 1.16.0 a 1.16.7 e da 1.28.0 a 1.28.400
Nel deployment di Autorizzazione binaria manca un nodeSelector
Se hai abilitato Autorizzazione binaria per GKE su Bare Metal e utilizzi una versione da 1.16.0 a 1.16.7 o da 1.28.0 a 1.28.400, potresti riscontrare un problema con la pianificazione dei pod per la funzionalità. In queste versioni, al deployment di Autorizzazione binaria manca un nodeSelector, quindi i pod per la funzionalità possono essere pianificati sui nodi worker anziché sui nodi del piano di controllo. Questo comportamento non causa alcun errore, ma non è previsto.
Soluzione alternativa:
Per tutti i cluster interessati, completa i seguenti passaggi:
Apri il file di 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 far sì che il pod del deployment del controller del ciclo di vita entri in uno stato di errore durante l'upgrade. In questo caso, i log del pod del deployment del controller del ciclo di vita visualizzano un messaggio di errore simile al seguente:
"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions
Soluzione alternativa:
Questo problema è stato risolto nella versione 1.28.400. Esegui l'upgrade alla versione 1.28.400 o successive per risolvere il problema.
Se non riesci a eseguire l'upgrade, esegui i comandi seguenti per risolvere il problema:
A volte i log del cluster o del container sono contrassegnati con un ID progetto diverso in resource.labels.project_id in Esplora log.
Questo può accadere quando il cluster è configurato per utilizzare l'osservabilità PROJECT_ONE, impostata nel campo clusterOperations.projectID nella configurazione del cluster.
Tuttavia, cloudOperationsServiceAccountKeyPath nella configurazione ha una chiave dell'account di servizio del progetto PROJECT_TWO.
In questi casi, tutti i log vengono instradati a PROJECT_ONE,
ma resource.labels.project_id è etichettato come
PROJECT_TWO.
Soluzione alternativa:
Utilizza una delle seguenti opzioni per risolvere il problema:
Utilizza un account di servizio dello stesso progetto di destinazione.
Modifica il project_id nel file JSON della chiave dell'account di servizio nel progetto corrente.
Modifica project_id direttamente nel filtro dei log da Esplora log.
Networking
1.29.0
Degrado delle prestazioni per i cluster che utilizzano il bilanciamento del carico in bundle con BGP
Per i cluster della versione 1.29.0 che utilizzano il bilanciamento del carico in bundle con BGP, le prestazioni del bilanciamento del carico possono diminuire quando il numero totale di servizi di tipo LoadBalancer si avvicina a 2000. Man mano che le prestazioni si riducono,
i servizi appena creati richiedono molto tempo per connettersi o
non possono essere connessi da un client. I servizi esistenti continuano a funzionare, ma non gestiscono modalità di errore, come la perdita di un nodo del bilanciatore del carico, in modo efficace. Questi problemi relativi ai servizi si verificano quando il deployment di ang-controller-manager viene arrestato a causa dell'esaurimento della memoria.
Se il cluster è interessato da questo problema, i servizi nel cluster non sono raggiungibili e non sono integri e il deployment ang-controller-manager si trova in un CrashLoopBackOff. La risposta quando vengono elencati i deployment ang-controller-manager è simile alla seguente:
Come soluzione alternativa, puoi aumentare di 100 MiB il limite di risorse di memoria del deployment ang-controller-manager e rimuovere il limite di CPU:
NAME CPU_LIMITS MEMORY_LIMITS
ang-controller-manager <none> 400Mi
Installazione, upgrade, backup e ripristino
1.28.0, 1.28.100
I problemi di connettività dell'endpoint gcr.io di Container Registry possono bloccare le operazioni del cluster
Più operazioni del cluster per i cluster di amministrazione creano un cluster di bootstrap. Prima di creare un cluster di bootstrap, bmctl esegue un controllo della connettività Google Cloud dalla workstation di amministrazione.
Questo controllo potrebbe non riuscire a causa di problemi di connettività con l'endpoint di Container Registry, gcr.io, e potresti visualizzare un messaggio di errore simile al seguente:
system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Soluzione
Per risolvere il problema, riprova l'operazione con il flag --ignore-validation-errors.
Networking
1,15, 1,16
GKE Dataplane V2 non compatibile con alcuni driver di archiviazione
I cluster GKE su Bare Metal utilizzano GKE Dataplane V2, che non è compatibile con alcuni provider di archiviazione. Potresti riscontrare problemi con volumi o pod NFS bloccati. Ciò è particolarmente probabile se hai carichi di lavoro che utilizzano volumi ReadWriteMany supportati da driver di archiviazione soggetti a questo problema:
Robin.io
Portworx (sharedv4 volume di servizio)
csi-nfs
Questo elenco non è completo.
Soluzione
Una correzione per questo problema è disponibile per le seguenti versioni di Ubuntu:
20.04 LTS: utilizza un'immagine del kernel 5.4.0 successiva a linux-image-5.4.0-166-generic
22.04 LTS: utilizza un'immagine del kernel 5.15.0 successiva a linux-image-5.15.0-88-generic o il kernel HWE 6.5.
Se non utilizzi una di queste versioni, contatta
l'Assistenza Google.
Logging e monitoraggio
1,15; 1,16; 1,28
kube-state-metrics OOM in cluster di grandi dimensioni
Potresti notare che kube-state-metrics o il pod gke-metrics-agent esistente sullo stesso nodo di kube-state-metrics ha esaurito la memoria (OOM).
Questo può accadere in cluster con più di 50 nodi o con molti oggetti Kubernetes.
Soluzione
Per risolvere il problema, aggiorna la definizione della risorsa personalizzata stackdriver in modo da utilizzare la porta delle funzionalità ksmNodePodMetricsOnly. Questa limitazione delle funzionalità garantisce che venga esposto solo un numero limitato di metriche critiche.
Per utilizzare questa soluzione alternativa, procedi nel seguente modo:
Controlla la definizione della risorsa personalizzata stackdriver per conoscere le
porte di funzionalità disponibili:
Il controllo preflight non va a buon fine su RHEL 9.2 a causa di iptables mancanti
Durante l'installazione di un cluster sul sistema operativo Red Hat Enterprise Linux (RHEL) 9.2, potresti riscontrare un errore a causa della mancanza del pacchetto iptables. L'errore si verifica durante i controlli preflight e attiva un messaggio di errore simile al seguente:
'check_package_availability_pass': "The following packages are not available: ['iptables']"
RHEL 9.2 è in Anteprima
per GKE su Bare Metal versione 1.28.
Soluzione
Ignora l'errore del controllo preflight impostando spec.bypassPreflightCheck su true nella risorsa cluster.
Operazione
1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16
Failover MetalLB lento su larga scala
Quando MetalLB gestisce un numero elevato di servizi (oltre 10.000), il failover può richiedere più di un'ora. Questo accade perché MetalLB utilizza una coda con limitazioni di frequenza che, se in condizioni di scalabilità elevata, può richiedere del tempo per raggiungere il servizio per il quale è necessario eseguire il failover.
Soluzione
Esegui l'upgrade del cluster alla versione 1.28 o successive. Se non riesci a eseguire l'upgrade, la modifica manuale del servizio (ad esempio l'aggiunta di un'annotazione) causa un failover più rapido del servizio.
Operazione
1.16.0-1.16.6, 1.28.0-1.28.200
Se il proxy è abilitato, è necessario impostare le variabili di ambiente sulla workstation di amministrazione
Se non hai definito le variabili di ambiente HTTPS_PROXY e NO_PROXY sulla workstation di amministrazione, bmctl check cluster potrebbe non riuscire a causa di errori del proxy. Il comando bmctl segnala un messaggio di errore relativo alla mancata chiamata di alcuni servizi Google, come nell'esempio seguente:
Imposta manualmente HTTPS_PROXY e NO_PROXY sulla workstation di amministrazione.
Upgrade e aggiornamenti
1.28.0-gke.435
Gli upgrade alla versione 1.28.0-gke.435 potrebbero non riuscire se audit.log ha una proprietà errata
In alcuni casi, per il file /var/log/apiserver/audit.log sui nodi del piano di controllo la proprietà del gruppo e degli utenti è impostata su root.
Questa impostazione relativa alla proprietà dei file causa errori di upgrade per i nodi del piano di controllo quando esegui l'upgrade di un cluster dalla versione 1.16.x alla versione 1.28.0-gke.435.
Questo problema si applica solo ai cluster creati prima della versione 1.11 e per cui Cloud Audit Logs è disabilitato. Cloud Audit Logs è abilitato per impostazione predefinita per i cluster versione 1.9 e successive.
Soluzione
Se non riesci a eseguire l'upgrade del cluster alla versione 1.28.100-gke.146, segui questi passaggi come soluzione alternativa per completare l'upgrade del cluster alla versione 1.28.0-gke.435:
Se Cloud Audit Logs è abilitato, rimuovi il file /var/log/apiserver/audit.log.
Se Cloud Audit Logs è disabilitato, cambia la proprietà di /var/log/apiserver/audit.log in modo che corrisponda alla directory padre, /var/log/apiserver.
Networking, upgrade e aggiornamenti
1.28.0-gke.435
MetalLB non assegna indirizzi IP ai servizi VIP
GKE su Bare Metal utilizza MetalLB per il bilanciamento del carico in bundle. Nella release 1.28.0-gke.435 di GKE su Bare Metal, viene eseguito l'upgrade del bundle MetalLB in bundle alla versione 0.13, che introduce il supporto CRD per IPAddressPools. Tuttavia, poiché ConfigMaps consente qualsiasi nome per un IPAddressPool, i nomi dei pool dovevano essere convertiti in un nome conforme a Kubernetes aggiungendo un hash alla fine del nome dell'elemento IPAddressPool.
Ad esempio, un IPAddressPool con nome default
viene convertito in un nome come default-qpvpd quando esegui l'upgrade
del cluster alla versione 1.28.0-gke.435.
Poiché MetalLB richiede un nome specifico di IPPool per la selezione, la conversione del nome impedisce a MetalLB di selezionare un pool e assegnare indirizzi IP. Di conseguenza, i servizi che utilizzano metallb.universe.tf/address-pool come annotazione per selezionare il pool di indirizzi per un indirizzo IP non ricevono più un indirizzo IP dal controller MetalLB.
Questo problema è stato risolto in GKE su Bare Metal versione 1.28.100-gke.146.
Soluzione
Se non riesci a eseguire l'upgrade del cluster alla versione 1.28.100-gke.146, segui questi passaggi come soluzione alternativa:
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 di GKE su cluster Bare Metal alla versione 1.14.x, alcune risorse della versione precedente non vengono eliminate. In particolare, potresti vedere un insieme di pod orfani come il seguente:
Questo problema è stato risolto in GKE su Bare Metal versione 1.15.0 e successive.
Installazione
1,14
Creazione del cluster bloccata sul job machine-init
Se provi a installare Google Distributed Cloud Virtual for Bare Metal versione 1.14.x, potresti riscontrare un errore a causa dei job machine-init, simile al seguente output di esempio:
"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference
Soluzione alternativa:
Rimuovi il membro etcd obsoleto che causa l'errore del job machine-init. Completa i seguenti passaggi su un nodo del piano di controllo funzionante:
Elenca i membri etcd esistenti:
etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/peer.crt \
member list
Cerca i membri con stato unstarted, come mostrato nel seguente output di esempio:
Rimuovi il membro etcd che non ha superato il controllo:
etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/peer.crt \
member remove MEMBER_ID
Sostituisci MEMBER_ID con l'ID del membro etcd che non ha superato il controllo. Nell'output di esempio precedente, questo ID è
bd1949bcb70e2cb5.
Il seguente output di esempio mostra che il membro è stato rimosso:
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
Networking
1.28.0
Cilium-operator non dispone delle autorizzazioni list e
watch per i nodi
In Cilium 1.13, le autorizzazioni ClusterRole cilium-operator non sono corrette. Mancano le autorizzazioni Nodo list e
watch. cilium-operator non riesce ad avviare i garbage collector, causando i seguenti problemi:
Perdita di risorse Cilium.
Le identità inattive non vengono rimosse dalle mappe di criteri IAB.
Le mappe di criteri potrebbero raggiungere il limite di 16.000.
Impossibile aggiungere nuove voci.
Applicazione non corretta di NetworkPolicy.
Le identità potrebbero raggiungere il limite di 64.000.
Non è possibile creare nuovi pod.
Un operatore a cui mancano le autorizzazioni per i nodi segnala il seguente messaggio di log di esempio:
2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s
L'agente Cilium segnala un messaggio di errore quando non riesce a inserire una voce in una mappa dei criteri, come nell'esempio seguente:
level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint
Soluzione alternativa:
Rimuovi le identità Cilium, quindi aggiungi le autorizzazioni ClusterRole mancanti all'operatore:
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 dell'autorizzazione. Non è necessario riavviare manualmente l'operatore.
Upgrade e aggiornamenti
1,15,0-1,15,7, 1,16,0-1,16,3
Si è verificato un problema temporaneo durante il controllo preflight
Una delle attività di controllo di integrità di kubeadm che viene eseguita durante il controllo preflight dell'upgrade potrebbe non riuscire con il seguente messaggio di errore:
[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found
Questo errore può essere ignorato. Se si verifica questo errore che blocca l'upgrade, esegui nuovamente il comando di upgrade.
Se noti questo errore quando esegui il preflight utilizzando il comando bmctl preflightcheck, non viene bloccato nulla da questo errore. Puoi eseguire di nuovo il controllo preflight per ottenere informazioni preflight accurate.
Soluzione alternativa:
Esegui di nuovo il comando di upgrade oppure, se rilevato durante bmctl preflightcheck, esegui nuovamente il comando preflightcheck.
Operazione
1,14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0
Il controllo di integrità della rete periodico non va a buon fine quando un nodo viene sostituito o rimosso
Questo problema riguarda i cluster che eseguono controlli di integrità della rete periodici dopo che un nodo è stato sostituito o rimosso. Se il cluster viene sottoposto a controlli di integrità periodici, il controllo di integrità periodico della rete determina un errore dopo la sostituzione o la rimozione di un nodo, poiché l'inventario di rete ConfigMap non viene aggiornato dopo la creazione.
Soluzione alternativa:
La soluzione consigliata è eliminare il ConfigMap dell'inventario e il controllo di integrità periodico della rete. L'operatore di cluster li ricrea automaticamente con le informazioni più aggiornate.
Il gateway di rete per GDC non può applicare la tua configurazione quando il nome del dispositivo contiene un punto
Se hai un dispositivo di rete che include un punto
(.) nel nome, ad esempio bond0.2,
Gateway di rete per GDC tratta il punto come un percorso nella
directory quando viene eseguito sysctl per apportare modifiche. Quando il gateway di rete per GDC controlla se il rilevamento di indirizzi duplicati (DAD) è abilitato, il controllo potrebbe non riuscire e pertanto non verrà riconciliato.
Il comportamento è diverso tra le versioni dei cluster:
1.14 e 1.15: questo errore esiste solo quando utilizzi indirizzi IP mobili IPv6. Se non utilizzi indirizzi IP mobili IPv6, non noterai questo problema se i nomi dei dispositivi contengono un punto.
1.16.0 - 1.16.2: questo errore esiste sempre quando i nomi dei dispositivi contengono un punto.
Soluzione alternativa:
Esegui l'upgrade del cluster alla versione 1.16.3 o successive.
Come soluzione alternativa fino a quando non potrai eseguire l'upgrade dei cluster, rimuovi il punto
(.) dal nome del dispositivo.
Upgrade e aggiornamenti, networking, sicurezza
1.16.0
Gli upgrade a 1.16.0 non riescono se seccomp è disabilitato
Se seccomp è disabilitato per il tuo cluster
(spec.clusterSecurity.enableSeccomp impostato su false),
gli upgrade alla versione 1.16.0 non andranno a buon fine.
GKE su Bare Metal versione 1.16 utilizza Kubernetes versione 1.27.
In Kubernetes 1.27.0 e versioni successive, la funzionalità per impostare i profili seccomp è in disponibilità generale e non utilizza più una gate delle funzionalità.
Questa modifica a Kubernetes causa errori degli upgrade alla versione 1.16.0 quando
seccomp è disabilitato nella configurazione del cluster. Questo problema è stato risolto nella versione 1.16.1 e nei cluster successivi. Se il campo cluster.spec.clusterSecurity.enableSeccomp è impostato su false, puoi eseguire l'upgrade alla versione 1.16.1 o successive.
I cluster con spec.clusterSecurity.enableSeccomp non impostato o
impostato su true non sono interessati.
i metadati containerd potrebbero danneggiarsi dopo il riavvio quando
viene montato /var/lib/containerd
Se hai montato facoltativamente /var/lib/containerd, i
metadati containerd potrebbero danneggiarsi dopo un riavvio. I metadati danneggiati
potrebbero causare errori dei pod, inclusi i pod critici del sistema.
Per verificare se questo problema ti riguarda, controlla se in /etc/fstab è stato definito un montaggio facoltativo per /var/lib/containerd/ e se è presente nofail nelle opzioni di montaggio.
Soluzione alternativa:
Rimuovi l'opzione di montaggio nofail in /etc/fstab oppure esegui l'upgrade del cluster alla versione 1.15.6 o successive.
Operazione
1,13; 1,14; 1,15; 1,16; 1,28
Pulisci i pod inattivi nel cluster
Potresti vedere pod gestiti da un Deployment (ReplicaSet) in stato Failed e con lo stato TaintToleration. Questi pod non utilizzano risorse del cluster, ma devono essere eliminati.
Puoi usare il seguente comando kubectl per elencare i pod di cui puoi eseguire la pulizia:
kubectl get pods –A | grep TaintToleration
Il seguente output di esempio mostra un pod con lo stato TaintToleration:
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
etcd-events possono bloccarsi quando si esegue l'upgrade alla versione 1.16.0
Quando esegui l'upgrade di un cluster esistente alla versione 1.16.0, gli errori dei pod relativi ad etcd-events possono bloccare l'operazione. In particolare, il job di upgrade del nodo non va a buon fine per il passaggio TASK [etcd_events_install : Run etcdevents].
Se questo problema ti riguarda, vedrai errori dei pod come il seguente:
Il pod kube-apiserver non si avvia con il
seguente errore:
Il pod etcd-events non si avvia con il seguente errore:
Error: error syncing endpoints with etcd: context deadline exceeded
Soluzione alternativa:
Se non riesci a eseguire l'upgrade del cluster a una versione che presenta la correzione, utilizza la seguente soluzione alternativa temporanea per risolvere gli errori:
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. GKE su Bare Metal utilizza sempre Random.
Questo problema si verifica perché il modello CoreDNS non è stato aggiornato e, di conseguenza, viene ignorato orderPolicy.
Soluzione alternativa:
Aggiorna il modello CoreDNS e applica la correzione. Questa correzione persiste fino a un upgrade.
Modifica il modello esistente:
kubectl edit cm -n kube-system coredns-template
Sostituisci i contenuti del modello con quanto segue:
coredns-template: |-
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
{{- if .PrivateGoogleAccess }}
import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
import zones/restricted.Corefile
{{- end }}
prometheus :9153
forward . {{ .UpstreamNameservers }} {
max_concurrent 1000
{{- if ne .OrderPolicy "" }}
policy {{ .OrderPolicy }}
{{- end }}
}
cache 30
{{- if .DefaultDomainQueryLogging }}
log
{{- end }}
loop
reload
loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
errors
{{- if $stubdomain.QueryLogging }}
log
{{- end }}
cache 30
forward . {{ $stubdomain.Nameservers }} {
max_concurrent 1000
{{- if ne $.OrderPolicy "" }}
policy {{ $.OrderPolicy }}
{{- end }}
}
}
{{- end }}
Networking, operazione
1,10; 1,11; 1,12; 1,13; 1,14
Gateway di rete per componenti GDC rimossi o in attesa a causa di una classe di priorità mancante
I pod del gateway di rete in kube-system potrebbero mostrare uno stato
Pending o Evicted, come mostrato nel seguente
output di esempio ridotto:
Questi errori indicano eventi di rimozione o l'impossibilità di pianificare i pod a causa delle risorse dei nodi. Poiché il gateway di rete per i pod GDC non ha PriorityClass, hanno la stessa priorità predefinita degli altri carichi di lavoro.
Quando i nodi sono vincolati dalle risorse, i pod del gateway di rete potrebbero essere rimossi. Questo comportamento è particolarmente negativo per il DaemonSet ang-node, poiché questi pod devono essere pianificati su un nodo specifico e non possono essere sottoposti a migrazione.
Soluzione alternativa:
Esegui l'upgrade alla versione 1.15 o successive.
Come soluzione a breve termine, puoi assegnare manualmente un elemento
PriorityClass
ai componenti Gateway di rete per i componenti GDC. Il controller GKE su Bare Metal
sovrascrive queste modifiche manuali durante un processo di riconciliazione, ad esempio
durante l'upgrade di un cluster.
Assegna il valore PriorityClass system-cluster-critical ai deployment dei controller di cluster
ang-controller-manager e autoscaler.
Assegna il PriorityClass system-node-critical al
nodo ang-daemon DaemonSet.
Installazione, upgrade e aggiornamenti
1,15.0, 1.15.1, 1.15.2
Creazione e upgrade del cluster non riusciti a causa della lunghezza del nome del cluster
La creazione di cluster della versione 1.15.0, 1.15.1 o 1.15.2 o l'upgrade dei cluster alla versione 1.15.0, 1.15.1 o 1.15.2 non riesce quando il nome del cluster ha più di 48 caratteri (versione 1.15.0) o 45 caratteri (versione 1.15.1 o 1.15.2). Durante le operazioni di creazione e upgrade del cluster, GKE su Bare Metal crea una risorsa di controllo di integrità con un nome che incorpora il nome e la versione del cluster:
Per i cluster della versione 1.15.0, il nome della risorsa per il controllo di integrità è CLUSTER_NAME-add-ons-CLUSTER_VER.
Per i cluster versione 1.15.1 o 1.15.2, il nome della risorsa di controllo di integrità è CLUSTER_NAME-kubernetes-CLUSTER_VER.
Per i nomi dei cluster lunghi, il nome della risorsa di controllo di integrità supera la limitazione di 63 caratteri di Kubernetes per i nomi delle etichette, il che impedisce la creazione della risorsa di controllo di integrità.
Senza un controllo di integrità riuscito, l'operazione del cluster ha esito negativo.
Per verificare se questo problema ti riguarda, usa kubectl describe per controllare la risorsa con errori:
Se questo problema ti riguarda, la risposta contiene un avviso per ReconcileError come il seguente:
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileError 77s (x15 over 2m39s) healthcheck-controller Reconcile error, retrying: 1 error occurred:
* failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]
Soluzione
Per sbloccare l'upgrade o la creazione del cluster, puoi ignorare il controllo di integrità. Utilizza il comando seguente per applicare una patch alla risorsa personalizzata del controllo di integrità in modo che venga superato lo stato: (status: {pass: true})
I cluster della versione 1.14.0 e 1.14.1 con funzionalità di anteprima non possono eseguire l'upgrade alla versione 1.15.x
Se nei cluster delle versioni 1.14.0 e 1.14.1 è abilitata una funzionalità di anteprima, non sarà possibile eseguire correttamente l'upgrade alla versione 1.15.x. Questo
si applica a funzionalità in anteprima come la possibilità di creare un cluster senza
kube-proxy, che è abilitato con la seguente annotazione nel file
di configurazione del cluster:
Se questo problema ti riguarda, durante l'upgrade del cluster viene visualizzato un errore come il seguente:
[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:
Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version
Questo problema è stato risolto nella versione 1.14.2 e nei cluster successivi.
Soluzione alternativa:
Se non riesci a eseguire l'upgrade dei cluster alla versione 1.14.2 o successive prima di eseguire l'upgrade alla versione 1.15.x, puoi eseguire direttamente l'upgrade alla versione 1.15.x utilizzando un cluster di bootstrap:
bmctl upgrade cluster --use-bootstrap=true
Operazione
1,15
I cluster della versione 1.15 non accettano indirizzi IP mobili duplicati
Il gateway di rete per GDC non consente di creare nuove risorse personalizzate NetworkGatewayGroup
contenenti indirizzi IP in spec.floatingIPs
già utilizzati nelle risorse personalizzate NetworkGatewayGroup
esistenti. Questa regola viene applicata da un webhook in GKE su cluster Bare Metal versione 1.15.0 e successive. Gli indirizzi IP mobili duplicati preesistenti non causano errori. Il webhook impedisce solo la creazione di nuove
risorse personalizzate NetworkGatewayGroups che contengono indirizzi IP
duplicati.
Il messaggio di errore relativo al webhook identifica l'indirizzo IP in conflitto e la risorsa personalizzata esistente che lo utilizza già:
IP address exists in other gateway with name default
La documentazione iniziale per le funzionalità di networking avanzate, ad esempio il gateway NAT in uscita, non mette in guardia contro gli indirizzi IP duplicati.
Inizialmente, lo strumento di riconciliazione ha riconosciuto solo la risorsa NetworkGatewayGroup denominata
default. Il gateway di rete per GDC ora riconosce tutte le risorse personalizzate NetworkGatewayGroup nello spazio dei nomi del sistema. Le risorse personalizzate NetworkGatewayGroup
esistenti verranno rispettate così come sono.
Soluzione alternativa:
Gli errori si verificano solo per la creazione di una nuova risorsa personalizzata NetworkGatewayGroup.
Per correggere l'errore:
Utilizza questo comando 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 essere avviate su cluster 1.13.7 che utilizzano un registro privato
Quando abiliti il runtime VM su GDC su un cluster della versione 1.13.7 nuova o aggiornata che utilizza un registro privato, le VM che si connettono alla rete di nodi o utilizzano una GPU potrebbero non avviarsi correttamente. Questo problema è dovuto al fatto che alcuni pod di sistema nello spazio dei nomi vm-system ricevono errori di pull dell'immagine. Ad esempio, se la VM utilizza la rete di nodi, alcuni pod potrebbero segnalare errori di pull delle immagini come i seguenti:
macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m
Questo problema è stato risolto nella versione 1.14.0 e successive di GKE su cluster Bare Metal.
Soluzione
Se non riesci a eseguire immediatamente l'upgrade dei cluster, puoi eseguire il pull delle immagini manualmente. I seguenti comandi eseguono il pull dell'immagine del plug-in CNI macvtap per la tua VM ed esegue il push al tuo registro privato:
Sostituisci REG_HOST con il nome di dominio di un host di cui esegui il mirroring localmente.
Installazione
1,11, 1,12
Durante la creazione del cluster nel cluster di tipo, il pod gke-metric-agent non si avvia
Durante la creazione del cluster nel cluster di tipo, il pod gke-metrics-agent non si avvia a causa di un errore di pull dell'immagine come segue:
error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
Inoltre, nel log containerd del cluster di bootstrap, vedrai la voce seguente:
Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
Nel pod viene visualizzato il seguente errore "impossibile eseguire il pull":
gcr.io/gke-on-prem-staging/gke-metrics-agent
Soluzione
Nonostante gli errori, il processo di creazione del cluster non è bloccato perché lo scopo del pod gke-metrics-agent nel cluster tipo è facilitare la percentuale di successo della creazione del cluster e il monitoraggio e il monitoraggio interni.
Pertanto, puoi ignorare questo errore.
Soluzione
Nonostante gli errori, il processo di creazione del cluster non è bloccato perché lo scopo del pod gke-metrics-agent nel cluster tipo è facilitare la percentuale di successo della creazione del cluster e il monitoraggio e il monitoraggio interni.
Pertanto, puoi ignorare questo errore.
Operazione, networking
1,12; 1,13; 1,14; 1,15; 1,16; 1,28
L'accesso a un endpoint di servizio IPv6 ha un arresto anomalo del nodo LoadBalancer su CentOS o RHEL
Quando accedi a un servizio a doppio stack (un servizio che ha endpoint IPv4 e IPv6) e utilizzi l'endpoint IPv6, il nodo LoadBalancer che gestisce il servizio potrebbe arrestarsi in modo anomalo. Questo problema riguarda i clienti che utilizzano servizi a doppio stack con CentOS o RHEL e una versione del kernel precedente a kernel-4.18.0-372.46.1.el8_6.
Se ritieni che questo problema ti riguardi, controlla la versione del kernel sul nodo LoadBalancer utilizzando il comando uname -a.
Soluzione alternativa:
Aggiorna il nodo LoadBalancer alla versione del kernel
kernel-4.18.0-372.46.1.el8_6 o successiva. Questa versione del kernel è disponibile per impostazione predefinita in CentOS e RHEL versione 8.6 e successive.
Networking
1,11; 1,12; 1,13; 1,14,0
Problemi di connettività intermittenti dopo il riavvio del nodo
Dopo aver riavviato un nodo, potresti riscontrare problemi di connettività intermittente per un servizio NodePort o LoadBalancer. Ad esempio, potresti riscontrare errori di handshake TLS intermittente o di reimpostazione della connessione. Questo problema è stato risolto per i cluster 1.14.1 e versioni successive.
Per verificare se questo problema ti riguarda, controlla le iptables regole di forwarding sui nodi in cui è in esecuzione il pod di backend per il servizio interessato:
sudo iptables -L FORWARD
Se vedi la regola KUBE-FORWARD prima della
regola CILIUM_FORWARD in iptables, questo problema potrebbe
essere interessato da questo problema. Il seguente output di esempio mostra un Nodo in cui si verifica il problema:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
Soluzione alternativa:
Riavvia il pod anetd sul nodo configurato in modo errato. Dopo aver riavviato il pod anetd, la regola di forwarding in iptables dovrebbe essere configurata correttamente.
Il seguente output di esempio mostra che la regola CILIUM_FORWARD è ora configurata correttamente prima della regola KUBE-FORWARD:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
Upgrade e aggiornamenti
1,9, 1,10
La funzionalità di anteprima non conserva l'autorizzazione originale e le informazioni sul proprietario
La funzionalità di anteprima del cluster 1.9.x che utilizza bmctl 1.9.x non conserva le autorizzazioni originali e le informazioni sul proprietario. Per verificare se questa funzionalità ti riguarda, estrai il file di cui hai eseguito il backup utilizzando il seguente comando:
tar -xzvf BACKUP_FILE
Soluzione
Verifica se metadata.json è presente e se bmctlVersion è 1.9.x. Se metadata.json non è presente, esegui l'upgrade al cluster 1.10.x e utilizza bmctl 1.10.x per eseguire il backup e il ripristino.
Upgrade e creazioni
1.14.2
clientconfig-operator bloccato nello stato di attesa con CreateContainerConfigError
Se hai creato o eseguito l'upgrade a un cluster versione 1.14.2 con una configurazione OIDC/LDAP, potresti vedere il pod clientconfig-operator bloccato in stato In sospeso. Con questo problema sono presenti due pod clientconfig-operator, uno in stato in esecuzione e l'altro in stato In attesa.
Questo problema si applica solo ai cluster della versione 1.14.2. Le versioni precedenti dei cluster, come 1.14.0 e 1.14.1, non sono interessate. Questo problema è stato risolto nella versione 1.14.3 e in tutte le release successive, inclusa la versione 1.15.0 e successive.
Soluzione alternativa:
Come soluzione alternativa, puoi applicare una patch al deployment di clientconfig-operator per aggiungere ulteriore contesto di sicurezza e assicurarti che il deployment sia pronto.
Usa questo comando per applicare la patch a clientconfig-operator nel cluster di destinazione:
CLUSTER_KUBECONFIG: il percorso del file kubeconfig
per il cluster di destinazione.
Operazione
1,11; 1,12; 1,13; 1,14; 1,15
La rotazione dell'autorità di certificazione non riesce per i cluster senza bilanciamento del carico in bundle
Per i cluster senza bilanciamento del carico in bundle (spec.loadBalancer.mode impostato su manual), il comando bmctl update credentials certificate-authorities rotate può non rispondere e non riuscire con il seguente errore: x509: certificate signed by unknown authority.
Se riscontri questo problema, il comando bmctl potrebbe restituire il seguente messaggio prima di non rispondere:
Signing CA completed in 3/0 control-plane nodes
In questo caso, il comando non riesce. Il log di rotazione dell'autorità di certificazione per un cluster con tre piani di controllo può includere voci come le seguenti:
[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")
ipam-controller-manager arresto anomalo in cluster a doppio stack
Quando esegui il deployment di un cluster a doppio stack (un cluster con indirizzi IPv4 e IPv6), i pod ipam-controller-manager potrebbero arrestarsi in modo anomalo. Questo comportamento causa il ciclo dei nodi tra gli stati Ready e NotReady e potrebbe causare la mancata installazione del cluster. Questo problema può verificarsi quando il server API è sottoposto a un carico elevato.
Per verificare se questo problema ti riguarda, controlla se
i pod ipam-controller-manager presentano errori e
CrashLoopBackOff:
kubectl -n kube-system get pods | grep ipam-controller-manager
Il seguente output di esempio mostra i pod in stato CrashLoopBackOff:
I cluster che eseguono etcd versione 3.4.13 o precedenti potrebbero riscontrare problemi di chiusura dell'attività e di monitoraggio delle risorse non operative, che possono causare i seguenti problemi:
La pianificazione dei pod è interrotta
Impossibile registrare i nodi
kubelet non osserva le modifiche ai pod
Questi problemi possono rendere il cluster non funzionante.
Questo problema è stato risolto in GDCV per Bare Metal versione 1.12.9, 1.13.6, 1.14.3 e versioni successive. Queste release più recenti utilizzano etcd la versione 3.4.21. Tutte le versioni precedenti di GDCV per Bare Metal sono interessate da questo problema.
Soluzione
Se non puoi eseguire l'upgrade immediatamente, puoi ridurre il rischio di errore del cluster riducendo il numero di nodi nel cluster. Rimuovi
i nodi fino a quando la metrica etcd_network_client_grpc_sent_bytes_total
non è inferiore a 300 MBps.
Per visualizzare questa metrica in Metrics Explorer:
Vai a Metrics Explorer nella console Google Cloud:
Espandi Seleziona una metrica, inserisci Kubernetes Container nella barra dei filtri, poi utilizza i sottomenu per selezionare la metrica:
Nel menu Risorse attive, seleziona Container Kubernetes.
Nel menu Categorie di metriche attive, seleziona Anthos.
Nel menu Metriche attive, seleziona etcd_network_client_grpc_sent_bytes_total.
Fai clic su Applica.
Networking
1.11.6, 1.12.3
Stato "Non riuscito " della modalità vfio-pci dell'operatore SR-IOV
L'elemento syncStatus dell'oggetto SriovNetworkNodeState
può segnalare il valore "Non riuscito" per un nodo configurato. Per visualizzare lo stato di un nodo e determinare se il problema ti riguarda, esegui questo comando:
kubectl -n gke-operators get \
sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
-o jsonpath='{.status.syncStatus}'
Sostituisci NODE_NAME con il nome del nodo da controllare.
Soluzione alternativa:
Se lo stato dell'oggetto SriovNetworkNodeState è "Non riuscito", esegui l'upgrade del cluster alla versione 1.11.7 o successiva o alla versione 1.12.4 o successiva.
Upgrade e aggiornamenti
1,10; 1,11; 1,12; 1,13; 1,14,0; 1,14,1
Alcuni nodi worker non sono in stato Pronto dopo l'upgrade
Al termine dell'upgrade, la condizione Pronto di alcuni nodi worker potrebbe essere impostata su false. Nella risorsa Nodo, vedrai un errore accanto alla condizione Pronto simile all'esempio seguente:
container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
Quando accedi alla macchina bloccata, la configurazione CNI sulla macchina è vuota:
sudo ls /etc/cni/net.d/
Soluzione
Riavvia il pod anetd del nodo eliminandolo.
Upgrade e aggiornamenti, Sicurezza
1,1
Più rotazioni di certificati da cert-manager generano incoerenze
Dopo più rotazioni manuali o automatiche dei certificati, il pod webhook, ad esempio anthos-cluster-operator, non viene aggiornato con i nuovi certificati emessi da cert-manager. Qualsiasi aggiornamento della risorsa personalizzata del cluster non riesce e genera un errore simile al seguente:
Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")
Questo problema può verificarsi nelle seguenti circostanze:
Se hai eseguito due rotazioni manuali dei certificati rilasciate dal gestore dei certificati su un cluster più vecchio di 180 giorni e non hai mai riavviato anthos-cluster-operator.
Se hai eseguito manualmente un cert-manager, hai emesso rotazioni di certificati su un cluster più vecchio di 90 giorni o più e non ha mai riavviato anthos-cluster-operator.
Soluzione
Riavvia il pod arrestando anthos-cluster-operator.
Upgrade e aggiornamenti
1.14.0
Pod del deployment del controller del ciclo di vita obsoleti creati durante l'upgrade del cluster utente
Nei cluster di amministrazione della versione 1.14.0, durante gli upgrade del cluster utente potrebbero essere creati uno o più pod del deployer del controller del ciclo di vita obsoleti.
Questo problema si applica ai cluster utente creati inizialmente con versioni precedenti alla 1.12. I pod creati involontariamente non ostacolano le operazioni di upgrade, ma potrebbero trovarsi in uno stato imprevisto. Ti consigliamo di rimuovere i pod obsoleti.
Questo problema è stato risolto nella release 1.14.1.
Soluzione alternativa:
Per rimuovere i pod obsoleti del deployment del controller del ciclo di vita:
Elenca le risorse per i controlli preflight:
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A
L'output sarà simile al seguente:
NAMESPACE NAME PASS AGE
cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31c true 20d
cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31cd6jv6 false 20d
dove ci-87a021b9dcbb31c è il nome del cluster.
Elimina le risorse il cui valore nella colonna PASS è true o false.
Ad esempio, per eliminare le risorse nell'output di esempio precedente, utilizza i comandi seguenti:
Lo stato BGPSession cambia costantemente a causa dell'elevato numero di route in entrata
Il networking avanzato GKE su Bare Metal non è in grado di gestire correttamente le sessioni BGP quando peer esterni pubblicizzano un numero elevato di route (circa 100 o più). Con un numero elevato di route in entrata, il controller BGP locale del nodo impiega troppo tempo per riconciliare le sessioni BGP e non riesce ad aggiornare lo stato. La mancanza di aggiornamenti dello stato o di un controllo di integrità causa l'eliminazione della sessione perché non aggiornata.
Ecco i comportamenti indesiderati delle sessioni BGP che potresti notare e indicare un problema:
Eliminazione e ricreazione continua di bgpsession.
bgpsession.status.state non diventa mai Established
Mancata pubblicità o ripetutamente pubblicizzate e ritirate.
I problemi di bilanciamento del carico BGP potrebbero essere evidenti con problemi di connettività ai servizi LoadBalancer.
Il problema FlatIP BGP potrebbe essere evidente in caso di problemi di connettività ai pod.
Per determinare se i problemi BGP sono causati dai peer remoti che pubblicizzano troppe route, utilizza i seguenti comandi per esaminare gli stati e l'output associati:
Usa kubectl get bgpsessions sul cluster interessato.
L'output mostra bgpsessions con lo stato "Non stabilita" e l'orario dell'ultimo report conta fino a circa 10-12 secondi prima che sembri azzerato.
L'output di kubectl get bgpsessions indica che le sessioni interessate vengono ricreate ripetutamente:
kubectl get bgpsessions \
-o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
I messaggi di log indicano che le sessioni BGP inattive vengono eliminate:
kubectl logs ang-controller-manager-POD_NUMBER
Sostituisci POD_NUMBER con il pod leader nel tuo cluster.
Soluzione alternativa:
Riduci o elimina il numero di route annunciate dal peer remoto al cluster con un criterio di esportazione.
Nel cluster GKE su Bare Metal versione 1.14.2 e successive, puoi anche disabilitare la
funzionalità che elabora le route ricevute utilizzando un
AddOnConfiguration. Aggiungi l'argomento --disable-received-routes al container bgpd del daemonset ang-daemon.
Networking
1,14; 1,15; 1,16; 1,28
Timeout dell'applicazione causati da errori di inserimento della tabella Conntrack
I cluster in esecuzione su un sistema operativo Ubuntu che utilizza il kernel 5.15 o versioni successive sono soggetti a errori di inserimento della tabella di monitoraggio delle connessioni di netfilter (conntrack). Gli errori di inserimento possono verificarsi anche quando la tabella conntrack ha spazio per nuove voci. Gli errori sono causati da modifiche nel kernel 5.15 e nelle versioni successive che limitano gli inserimento delle tabelle in base alla lunghezza della catena.
Per verificare se questo problema ti riguarda, puoi controllare le statistiche di sistema di monitoraggio delle connessioni nel kernel con il seguente comando:
Se un valore chaintoolong nella risposta è un numero diverso da zero, sei interessato da questo problema.
Soluzione
La mitigazione a breve termine prevede l'aumento delle dimensioni della tabella di hash netfiler (nf_conntrack_buckets) e della tabella di monitoraggio delle connessioni netfilter (nf_conntrack_max). Utilizza i seguenti comandi su ciascun nodo cluster per aumentare le dimensioni delle tabelle:
Sostituisci TABLE_SIZE con la nuova dimensione in byte. Il valore predefinito per le dimensioni della tabella è 262144. Ti suggeriamo di impostare un valore pari a 65.536 volte il numero di core sul nodo. Ad esempio,
se il nodo ha otto core, imposta la dimensione della tabella su 524288.
Impossibile ripristinare i backup del cluster con bmctl per alcune versioni
Ti consigliamo di eseguire il backup dei cluster prima dell'upgrade, in modo da poter ripristinare la versione precedente in caso di esito negativo.
Un problema con il comando bmctl restore cluster ne impedisce il ripristino dei backup dei cluster con le versioni identificate. Questo problema riguarda in modo specifico gli upgrade, in cui stai ripristinando un backup di una versione precedente.
Se il cluster è interessato, il log bmctl restore cluster contiene il seguente errore:
Error: failed to extract image paths from profile: anthos version VERSION not supported
Soluzione alternativa:
Finché il problema non sarà risolto, ti consigliamo di seguire le istruzioni riportate in
Effettuare il backup e il ripristino dei cluster
per eseguire il backup manuale dei cluster e ripristinarli manualmente, se necessario.
Networking
1,10, 1,11, 1,12, 1,13, 1,14,0-1,14,2
NetworkGatewayGroup si arresta in modo anomalo se non è presente alcun indirizzo IP
nell'interfaccia
NetworkGatewayGroup non riesce a creare daemon per i nodi
che non hanno interfacce IPv4 e IPv6. Questo causa l'errore di funzionalità come BGP LB e OutboundNAT. Se controlli i log del pod ang-node con errori nello spazio dei nomi kube-system, vengono visualizzati errori simili all'esempio seguente quando manca un indirizzo IPv6:
ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}
Nell'esempio precedente, non è presente un indirizzo IPv6 nell'interfaccia di ens192. Errori ARP simili vengono visualizzati se nel nodo manca un indirizzo IPv4.
NetworkGatewayGroup tenta di stabilire una connessione ARP e una connessione NDP all'indirizzo IP locale del collegamento. Se l'indirizzo IP non esiste (IPv4 per ARP, IPv6 per NDP), la connessione non riesce e il daemon non continua.
Questo problema è stato risolto nella release 1.14.3.
Soluzione alternativa:
Connettiti al nodo utilizzando SSH e aggiungi un indirizzo IPv4 o IPv6 al link che contiene l'IP del nodo. Nella voce di log di esempio precedente, questa
interfaccia era ens192:
ip address add dev INTERFACE scope link ADDRESS
Sostituisci quanto segue:
INTERFACE: l'interfaccia del nodo, ad esempio ens192.
ADDRESS: l'indirizzo IP e la subnet mask da applicare all'interfaccia.
Ripristino/eliminazione
1,10, 1,11, 1,12, 1,13,0-1,13,2
Loop di arresto anomalo di anthos-cluster-operator durante la rimozione di un nodo del piano di controllo
Quando provi a rimuovere un nodo del piano di controllo rimuovendo l'indirizzo IP da Cluster.Spec, anthos-cluster-operator entra in uno stato di loop di arresto anomalo che blocca qualsiasi altra operazione.
Soluzione alternativa:
Il problema è stato risolto nelle versioni 1.13.3 e 1.14.0 e successive. Sono interessate tutte le altre versioni. Esegui l'upgrade a una delle versioni corrette
Come soluzione alternativa, esegui questo comando:
IP_ADDRESS: l'indirizzo IP del nodo in uno stato di loop di arresto anomalo.
CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.
Installazione
1.13.1, 1.13.2 e 1.13.3
kubeadm join errore nei cluster di grandi dimensioni a causa di una mancata corrispondenza dei token
Quando installi GKE su cluster Bare Metal con un numero elevato di nodi, potresti visualizzare un messaggio di errore kubeadmin join simile al seguente esempio:
TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}
Soluzione alternativa:
Questo problema è stato risolto in GDCV per Bare Metal versione 1.13.4 e successive.
Se devi utilizzare una versione interessata, crea prima un cluster con meno di 20 nodi, quindi ridimensiona il cluster in modo da aggiungere altri nodi al termine dell'installazione.
Logging e monitoraggio
1,10; 1,11; 1,12; 1,13,0
Limite di CPU basso per metrics-server nei cluster perimetrali
Nei cluster GKE su Bare Metal Edge, i limiti bassi di CPU per metrics-server possono causare riavvii frequenti di metrics-server. Scalabilità automatica orizzontale dei pod (HPA) non funziona
perché metrics-server non è integro.
Se il limite di metrics-server CPU è inferiore a 40m, i cluster possono essere interessati. Per verificare i limiti della CPU metrics-server, esamina uno dei seguenti file:
Questo problema è stato risolto in GKE su cluster Bare Metal versione 1.13.1 o successive. Per risolvere il problema, esegui l'upgrade dei cluster.
Una soluzione alternativa a breve termine fino a quando non puoi eseguire l'upgrade dei cluster consiste nell'aumentare manualmente i limiti della CPU per metrics-server come segue:
Rimuovi la riga --config-dir=/etc/config e aumenta i
limiti della CPU, come mostrato nell'esempio seguente:
[...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- Remove this line
- --container=metrics-server
- --cpu=50m # <--- Increase CPU, such as to 50m
- --extra-cpu=0.5m
- --memory=35Mi
- --extra-memory=4Mi
- --threshold=5
- --deployment=metrics-server
- --poll-period=30000
- --estimator=exponential
- --scale-down-delay=24h
- --minClusterSize=5
- --use-metrics=true
[...]
Salva e chiudi metrics-server per applicare le modifiche.
Networking
1,14; 1,15; 1,16
La connessione NodePort diretta al pod hostNetwork non funziona
La connessione a un pod abilitato con hostNetwork tramite il servizio NodePort
non riesce quando il pod di backend si trova sullo stesso nodo della NodePort
di destinazione. Questo problema interessa i servizi LoadBalancer quando vengono utilizzati con pod hostNetwork. In presenza di più backend, si possono verificare sporadi errori di connessione.
Questo problema è causato da un bug del programma eBPF.
Soluzione alternativa:
Quando utilizzi un servizio Nodeport, non scegliere come target il nodo su cui viene eseguito il pod di backend. Quando utilizzi il servizio LoadBalancer, assicurati che i pod hostNetwork non vengano eseguiti su nodi LoadBalancer.
Upgrade e aggiornamenti
1.12.3, 1.13.0
I cluster di amministrazione 1.13.0 non possono gestire i cluster utente 1.12.3
I cluster di amministrazione che eseguono la versione 1.13.0 non possono gestire i cluster utente che eseguono la versione 1.12.3. Le operazioni su un cluster utente della versione 1.12.3 non riescono.
Soluzione alternativa:
Esegui l'upgrade del cluster di amministrazione alla versione 1.13.1 oppure del cluster utente alla stessa versione del cluster di amministrazione.
Upgrade e aggiornamenti
1,12
L'upgrade a 1.13.x è bloccato per i cluster di amministrazione con pool di nodi worker
I cluster di amministrazione della versione 1.13.0 e successive non possono contenere pool di nodi worker.
Gli upgrade alla versione 1.13.0 o successive per i cluster di amministrazione con pool di nodi worker sono bloccati. Se l'upgrade del cluster di amministrazione è bloccato, puoi verificare se la causa è costituita dai pool di nodi worker controllando il seguente errore nel file upgrade-cluster.log all'interno della cartella bmctl-workspace:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.
Soluzione alternativa:
Prima di eseguire l'upgrade, sposta tutti i pool di nodi worker nei cluster utente. Per istruzioni su come aggiungere e rimuovere pool di nodi, consulta Gestire i pool di nodi in un cluster.
Upgrade e aggiornamenti
1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28
Errori durante l'aggiornamento delle risorse utilizzando kubectl apply
Se aggiorni risorse esistenti come le risorse personalizzate ClientConfig o Stackdriver utilizzando kubectl apply, il controller potrebbe restituire un errore o ripristinare l'input e le modifiche pianificate.
Ad esempio, potresti provare a modificare la risorsa personalizzata Stackdriver come segue, recuperando prima la risorsa e poi applicando una versione aggiornata:
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 è il punto in cui potresti riscontrare problemi.
Soluzione alternativa:
Non utilizzare kubectl apply per apportare modifiche alle risorse esistenti. Utilizza invece kubectl edit o kubectl patch
come mostrato negli esempi seguenti:
I blocchi di backlog danneggiati causano un arresto anomalo di stackdriver-log-forwarder
L'arresto anomalo di stackdriver-log-forwarder si arresta se tenta di elaborare un blocco di backlog danneggiato. Nei log dei container vengono visualizzati i seguenti errori di esempio:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
Quando si verifica questo arresto anomalo, non puoi visualizzare i log in Cloud Logging.
Soluzione alternativa:
Per risolvere questi errori, completa i seguenti passaggi:
Identifica i blocchi di backlog danneggiati. Esamina i seguenti
messaggi di errore di esempio:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
In questo esempio, il file tail.1/1-1659339894.252926599.flb archiviato in var/log/fluent-bit-buffers/tail.1/ è errore. Ogni file *.flb con un controllo del formato non riuscito deve essere rimosso.
Termina i pod in esecuzione per stackdriver-log-forwarder:
Il riavvio di Dataplane V2 (anetd) sui cluster può comportare l'impossibilità di collegare le VM esistenti a una rete non pod
Nei cluster con più nic, il riavvio di Dataplane V2 (anetd) può comportare l'impossibilità di collegare le macchine virtuali alle reti. Nei log dei pod anetd potrebbe essere osservato un errore simile al seguente:
could not find an allocator to allocate the IP of the multi-nic endpoint
Soluzione alternativa:
Per risolvere rapidamente il problema, puoi riavviare la VM. Per evitare che il problema si ripeta, esegui l'upgrade del cluster alla versione 1.14.1 o successiva.
Operazione
1,13, 1.14.0, 1.14.1
gke-metrics-agent non ha limiti di memoria sui cluster del profilo perimetrale
A seconda del carico di lavoro del cluster, gke-metrics-agent potrebbe utilizzare più di 4608 MiB di memoria. Questo problema riguarda solo i cluster di profilo GKE su Bare Metal Edge. I cluster del profilo predefiniti non sono interessati.
Soluzione alternativa:
Esegui l'upgrade del cluster alla versione 1.14.2 o successive.
Installazione
1,12, 1,13
La creazione del cluster potrebbe non riuscire a causa delle condizioni di gara
Quando crei i cluster utilizzando kubectl, a causa delle condizioni di gara, il controllo preflight potrebbe non terminare. Di conseguenza, in alcuni casi la creazione del cluster potrebbe non riuscire.
Lo strumento di riconciliazione dei controlli preflight crea un SecretForwarder
per copiare il secret ssh-key predefinito nello spazio dei nomi di destinazione.
In genere, il controllo preflight si basa sui riferimenti del proprietario e si riconcilia una volta completato il criterio SecretForwarder. Tuttavia, in rari casi il proprietario fa riferimento a SecretForwarder può
perdere il riferimento al controllo preflight, causando il blocco
di quest'ultimo. Di conseguenza, la creazione del cluster non riesce. Per continuare la riconciliazione per il controllo preflight basato su controller, elimina il pod dell'operatore del cluster o la risorsa del controllo preflight. Quando elimini la risorsa di controllo preflight, ne viene creata un'altra e la riconciliazione continua. In alternativa, puoi eseguire l'upgrade dei cluster esistenti
(creati con una versione precedente) a una versione fissa.
Networking
1,9; 1,10; 1,11; 1,12; 1,13; 1,14; 1,15
Gli indirizzi IP riservati non vengono rilasciati quando si utilizza il plug-in whereabouts con la funzionalità multi-NIC
Nella funzionalità multi-Nic, se utilizzi il plug-in CNI whereabouts e l'operazione CNI DEL per eliminare un'interfaccia di rete per un pod, alcuni indirizzi IP riservati potrebbero non essere rilasciati correttamente. Questo accade quando l'operazione CNI DEL viene interrotta.
Puoi verificare le prenotazioni di indirizzi IP inutilizzati dei pod eseguendo questo comando:
kubectl get ippools -A --kubeconfig KUBECONFIG_PATH
Soluzione alternativa :
Elimina manualmente gli indirizzi IP (ippool) che non vengono utilizzati.
Installazione
1,10, 1.11.0, 1.11.1, 1.11.2
Il rilevatore dei problemi dei nodi non funziona nel cluster utente 1.10.4
Il rilevatore di problemi dei nodi potrebbe non funzionare nei cluster utente della versione 1.10.x, quando i cluster di amministrazione della versione 1.11.0, 1.11.1 o 1.11.2 gestiscono i cluster utente 1.10.x. In caso di errore del rilevatore di problemi dei nodi, il log viene aggiornato con il seguente messaggio di errore:
Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.
Soluzione
Esegui l'upgrade del cluster di amministrazione alla versione 1.11.3 per risolvere il problema.
Operazione
1,14
1.14 nodi cluster IPv4 in modalità isola hanno una dimensione della maschera CIDR dei pod di 24
Nella release 1.14, l'impostazione maxPodsPerNode non viene presa in considerazione per i cluster in modalità isola, pertanto ai nodi viene assegnata una dimensione della maschera CIDR dei pod di 24
(256 indirizzi IP).nQuesto potrebbe causare l'esaurimento degli indirizzi IP dei pod da parte del cluster prima del previsto. Ad esempio, se il cluster ha una dimensione della maschera CIDR del pod pari a 22, a ogni nodo verrà assegnata una maschera CIDR dei pod di 24, mentre il cluster potrà supportare solo un massimo di quattro nodi. Il cluster potrebbe anche riscontrare instabilità della rete in un periodo di elevato tasso di abbandono dei pod quando il valore di maxPodsPerNode è impostato su 129 o superiore e non è previsto un overhead sufficiente nel CIDR del pod per ogni nodo.
Se il cluster è interessato, il pod anetd segnala il seguente errore quando aggiungi un nuovo nodo al cluster. Inoltre, non è disponibile podCIDR:
error="required IPv4 PodCIDR not available"
Soluzione
Per risolvere il problema:
Esegui l'upgrade alla versione 1.14.1 o 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à dei cluster.
Upgrade e aggiornamenti
1.14.0, 1.14.1
Errore di rollback dell'upgrade del cluster
Il rollback di un upgrade potrebbe non riuscire per i cluster di versione 1.14.0 o 1.14.1.
Se esegui l'upgrade di un cluster dalla versione 1.14.0 alla versione 1.14.1 e poi provi a eseguire il rollback alla versione 1.14.0 utilizzando il comando bmctl restore cluster, potrebbe essere restituito un errore come nell'esempio seguente:
I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable
Soluzione alternativa:
Elimina tutte le risorse healthchecks.baremetal.cluster.gke.io sotto lo spazio dei nomi del cluster, quindi esegui nuovamente il comando bmctl restore
cluster:
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 risorse healthchecks.baremetal.cluster.gke.io
elencate nel passaggio precedente:
Sostituisci HEALTHCHECK_RESOURCE_NAME con il nome delle risorse per il controllo di integrità.
Esegui nuovamente il comando bmctl restore cluster.
Networking
1.12.0
L'indirizzo IP esterno del servizio non funziona in modalità flat
In un cluster in cui flatIPv4 è impostato su true, i servizi di tipo LoadBalancer non sono accessibili dai relativi indirizzi IP esterni.
Questo problema è stato risolto nella versione 1.12.1.
Soluzione alternativa:
In ConfigMap cilium-config, imposta enable-415 su "true", quindi riavvia i pod anetd.
Upgrade e aggiornamenti
1,13,0, 1,14
Gli aggiornamenti in loco da 1.13.0 a 1.14.x non terminano mai
Quando provi a eseguire un upgrade in loco da 1.13.0 a
1.14.x utilizzando bmctl 1.14.0 e il
flag --use-bootstrap=false, l'upgrade non termina mai.
Un errore nell'operatore preflight-check fa sì che il cluster non pianifichi mai i controlli richiesti, perciò il controllo preflight non termina mai.
Soluzione alternativa:
Esegui l'upgrade alla versione 1.13.1 prima di passare alla versione 1.14.x. Un upgrade in loco da 1.13.0 a 1.13.1 dovrebbe funzionare. In alternativa, esegui l'upgrade dalla versione 1.13.0 alla versione 1.14.x senza il flag --use-bootstrap=false.
Upgrade e aggiornamenti, Sicurezza
1,13 e 1,14
I cluster aggiornati alla versione 1.14.0 perdono le incompatibilità master
I nodi del piano di controllo richiedono una delle due incompatibilità specifiche per impedire la pianificazione dei pod dei carichi di lavoro su questi nodi. Quando esegui l'upgrade dei cluster GKE dalla versione 1.13 alla versione 1.14.0, i nodi del piano di controllo perdono le seguenti incompatibilità richieste:
node-role.kubernetes.io/master:NoSchedule
node-role.kubernetes.io/master:PreferNoSchedule
Questo problema non causa errori di upgrade, ma i pod che non dovrebbero essere eseguiti sui nodi del piano di controllo potrebbero iniziare a farlo. Questi pod dei carichi di lavoro possono sovraccaricare i nodi del piano di controllo e causare l'instabilità dei cluster.
Determinare se il problema ti riguarda
Trova i nodi del piano di controllo, utilizza il comando seguente:
kubectl get node -l 'node-role.kubernetes.io/control-plane' \
-o name --kubeconfig KUBECONFIG_PATH
Per controllare l'elenco delle incompatibilità su un nodo, utilizza il seguente comando:
Se nessuna delle incompatibilità richieste è elencata, significa che il problema ti riguarda.
Soluzione
Per ripristinare il funzionamento corretto, segui questi passaggi per ciascun nodo del piano di controllo del cluster versione 1.14.0 interessato. Questi passaggi si riferiscono all'incompatibilità node-role.kubernetes.io/master:NoSchedule e ai pod correlati. Se vuoi che i nodi del piano di controllo utilizzino l'incompatibilità PreferNoSchedule, modifica i passaggi di conseguenza.
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 non riesce spesso durante il caricamento delle immagini. Questo problema riguarda le VM Linux e Windows. L'errore è simile al seguente esempio:
PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51
2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------] 0.42% 0s
fail to upload image: unexpected return value 500, ...
Soluzione
Riprova a utilizzare il comando kubectl virt create vm per creare la VM.
Upgrade e aggiornamenti, Logging e monitoraggio
1,11
I componenti delle raccolte gestite nei cluster 1.11 non vengono conservati negli upgrade alla versione 1.12
I componenti della raccolta gestita fanno parte di Managed Service per Prometheus.
Se hai eseguito manualmente il deployment dei componenti della raccolta gestita nello spazio dei nomi gmp-system dei tuoi cluster della versione 1.11, le risorse associate non vengono conservate quando esegui l'upgrade alla versione 1.12.
A partire dai cluster della versione 1.12.0, i componenti di Managed Service per Prometheus nello spazio dei nomi gmp-system e le relative definizioni di risorse personalizzate sono gestiti da stackdriver-operator con il campo enableGMPForApplications. Per impostazione predefinita, il campo enableGMPForApplications è impostato su true, quindi se esegui manualmente il deployment dei componenti di Managed Service per Prometheus nello spazio dei nomi prima di eseguire l'upgrade alla versione 1.12, le risorse vengono eliminate da stackdriver-operator.
Soluzione
Per preservare le risorse di raccolta gestite manualmente:
Esegui il backup di tutte le risorse personalizzate PodMonitoring esistenti.
Esegui di nuovo il deployment delle risorse personalizzate PodMonitoring nel cluster di cui è stato eseguito l'upgrade.
Upgrade e aggiornamenti
1,13
Alcuni cluster di versione 1.12 con il runtime del container Docker non possono eseguire l'upgrade alla versione 1.13
Se in un cluster versione 1.12 che utilizza il runtime del container Docker manca la seguente annotazione, non è possibile eseguire l'upgrade alla versione 1.13:
Se questo problema riguarda questo problema, bmctl scrive il
seguente errore nel file upgrade-cluster.log all'interno della
cartella bmctl-workspace:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.
Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.
È molto probabile che questo problema si verifichi con i cluster Docker della versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11, in quanto questo upgrade non richiede l'annotazione per mantenere il runtime del container Docker. In questo caso, i cluster non hanno l'annotazione quando esegui l'upgrade alla versione 1.13. Tieni presente che a partire dalla versione 1.13, containerd è l'unico runtime dei container consentito.
Soluzione alternativa:
Se riscontri questo problema, aggiorna la risorsa cluster con l'annotazione mancante. Puoi aggiungere l'annotazione mentre l'upgrade è in esecuzione o dopo l'annullamento e prima di riprovare.
Installazione
1,11
bmctl si chiude prima del completamento della creazione del cluster
La creazione del cluster potrebbe non riuscire per GDCV per Bare Metal versione 1.11.0 (questo problema è stato risolto in GDCV per la release Bare Metal 1.11.1). In alcuni casi, il comando bmctl create cluster esce in anticipo e scrive errori come quelli indicati di seguito nei log:
Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster
Soluzione
L'operazione non riuscita produce artefatti, ma il cluster non è operativo. Se questo problema ti riguarda, segui questi passaggi per eseguire la pulizia degli artefatti e creare un cluster:
Visualizza le procedure alternative
Per eliminare gli artefatti del cluster e reimpostare la macchina del nodo, esegui questo comando:
bmctl reset -c USER_CLUSTER_NAME
Per avviare l'operazione di creazione del cluster, esegui questo comando:
Il flag --keep-bootstrap-cluster è importante se questo comando ha esito negativo.
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 per il cluster di bootstrap:
Questo errore non è valido e puoi tranquillamente ignorarlo.
Installazione
1,10, 1,11, 1,12
La creazione del cluster non riesce quando si utilizzano più NIC, containerd e proxy HTTPS
La creazione del cluster non riesce quando hai la seguente combinazione di condizioni:
Il cluster è configurato per utilizzare containerd come runtime del container (nodeConfig.containerRuntime impostato su containerd nel file di configurazione del cluster, predefinito per GDCV per Bare Metal versione 1.13 e successive).
Il cluster è configurato per fornire più interfacce di rete,
multi-NIC, per i pod (clusterNetwork.multipleNetworkInterfaces
impostato su true nel file di configurazione del cluster).
Il cluster è configurato per utilizzare un proxy (spec.proxy.url è specificato nel file di configurazione del cluster). Anche se la creazione del cluster non riesce, questa impostazione viene propagata quando tenti di creare un cluster. Potresti visualizzare questa impostazione proxy come variabile di ambiente HTTPS_PROXY o nella configurazione di containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).
Soluzione
Aggiungi i CIDR del servizio (clusterNetwork.services.cidrBlocks) alla variabile di ambiente NO_PROXY su tutte le macchine nodo.
Installazione
1,10, 1,11, 1,12
Errore su sistemi con impostazioni umask
restrittive
La release 1.10.0 di GDCV per Bare Metal ha introdotto una funzionalità del piano di controllo senza root che esegue tutti i componenti del piano di controllo come utente non root. L'esecuzione di tutti i componenti come utente non root può causare errori di installazione o upgrade sui sistemi con un'impostazione umask più restrittiva pari a 0077.
Soluzione
Reimposta i nodi del piano di controllo e modifica l'impostazione umask in 0022 su tutte le macchine del piano di controllo. Dopo aver aggiornato le macchine, riprova a eseguire l'installazione.
In alternativa, puoi modificare le autorizzazioni di directory e file di
/etc/kubernetes sulle macchine del piano di controllo per procedere con
l'installazione o l'upgrade.
Rendi leggibili pubblicamente /etc/kubernetes e tutte le relative sottodirectory: chmod o+rx.
Rendi tutti i file di proprietà dell'utente root sotto la
directory (in modo ricorsivo) /etc/kubernetes leggibili pubblicamente (chmod o+r). Escludi i file di chiavi private (.key) da queste
modifiche poiché vengono già creati con proprietà e autorizzazioni
corrette.
Rendi /usr/local/etc/haproxy/haproxy.cfg leggibile dal mondo.
Rendi /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml leggibile dal mondo.
Installazione
1,10; 1,11; 1,12; 1,13
Incompatibilità del gruppo di controllo v2
Il
gruppo di controllo v2 (cgroup v2) non è supportato in GKE sui cluster Bare Metal versione 1.13 e precedenti di GDCV per Bare Metal. Tuttavia, la versione 1.14 supporta cgroup v2 come funzionalità di anteprima
. La presenza di /sys/fs/cgroup/cgroup.controllers indica che il sistema utilizza cgroup v2.
Soluzione
Se il sistema utilizza cgroup v2, esegui l'upgrade del cluster alla versione 1.14.
Controlli preflight e credenziali dell'account di servizio
Per le installazioni attivate da cluster di amministrazione o ibridi (ovvero, cluster non creati con bmctl, ad esempio cluster utente), il controllo preflight non verifica le credenziali dell'account di servizio Google Cloud o le autorizzazioni associate.
Quando installi GKE su cluster Bare Metal su VM vSphere, devi impostare i flag
tx-udp_tnl-segmentation e
tx-udp_tnl-csum-segmentation su Off. Questi flag sono relativi all'offload della segmentazione hardware effettuato dal driver vSphere VMXNET3 e non funzionano con il tunnel GENEVE dei cluster GKE su Bare Metal.
Soluzione
Esegui questo comando su ciascun nodo per verificare i valori attuali di questi flag:
ethtool -k NET_INTFC | grep segm
Sostituisci NET_INTFC con l'interfaccia di rete associata all'indirizzo IP del nodo.
La risposta deve contenere voci simili alle seguenti:
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
A volte in RHEL 8.4, ethtool mostra che questi flag sono disattivati,
mentre non lo sono. Per disattivare esplicitamente questi flag, attiva e disattiva i flag utilizzando i seguenti comandi:
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
tx-udp_tnl-csum-segmentation off
Questa modifica del flag non viene mantenuta tra i riavvii. Configura gli script di avvio per impostare in modo esplicito questi flag all'avvio del sistema.
Upgrade e aggiornamenti
1,1
bmctl non può creare, aggiornare o reimpostare i cluster utente di versioni precedenti
L'interfaccia a riga di comando bmctl non può creare, aggiornare o reimpostare un cluster utente con una versione secondaria inferiore, indipendentemente dalla versione del cluster di amministrazione. Ad esempio, non puoi utilizzare bmctl con una versione di
1.N.X per reimpostare un cluster utente di versione
1.N-1.Y, anche se anche il cluster di amministrazione è alla versione
1.N.X.
Se questo problema ti riguarda, dovresti vedere log simili al seguente quando usi bmctl:
[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:
* cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported
Soluzione alternativa:
Utilizza kubectl per creare, modificare o eliminare la risorsa personalizzata del cluster utente
all'interno del cluster di amministrazione.
La possibilità di eseguire l'upgrade dei cluster utente non è interessata.
Upgrade e aggiornamenti
1,12
Gli upgrade del cluster alla versione 1.12.1 potrebbero bloccarsi
L'upgrade dei cluster alla versione 1.12.1 a volte si blocca perché il server API non è più disponibile. Questo problema riguarda tutti i tipi di cluster e tutti i sistemi operativi supportati. Quando si verifica questo problema, il comando bmctl
upgrade cluster potrebbe non funzionare in più punti, anche durante la seconda fase dei controlli preflight.
Soluzione
Puoi controllare i log dell'upgrade per determinare se questo problema ti riguarda. I log di upgrade si trovano in /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP per impostazione predefinita.
Il upgrade-cluster.log potrebbe contenere errori come il seguente:
Failed to upgrade cluster: preflight checks failed: preflight check failed
Il log della macchina potrebbe contenere errori come i seguenti (errori ripetuti
indicano che questo problema ti riguarda:
HAProxy e Keepaworthy devono essere in esecuzione su ciascun nodo del piano di controllo prima di tentare nuovamente di eseguire l'upgrade del cluster alla versione 1.12.1. Utilizza l'
interfaccia a riga di comando crictl su ciascun nodo per verificare se i container haproxy e keepalived sono in esecuzione:
Se HAProxy o KeepaDuration non è in esecuzione su un nodo, riavvia kubelet sul nodo:
systemctl restart kubelet
Upgrade e aggiornamenti, runtime VM su GDC
1,11, 1,12
L'upgrade dei cluster alla versione 1.12.0 o successive non riesce se è abilitato il runtime VM su GDC
Nella versione 1.12.0 GKE su cluster Bare Metal viene eseguita la migrazione di tutte le risorse relative al runtime delle VM su GDC nello spazio dei nomi vm-system per supportare meglio la release GA del runtime VM su GDC. Se hai abilitato il runtime VM su GDC in un cluster della versione 1.11.x o precedente, l'upgrade alla versione 1.12.0 o successive non va a buon fine, a meno che non disabiliti prima il runtime VM su GDC. Se questo problema ti riguarda, l'operazione di upgrade segnala il seguente errore:
Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version
Upgrade bloccato a error during manifests operations
In alcune situazioni, gli upgrade del cluster non vengono completati e l'interfaccia a riga di comando bmctl non risponde. Questo problema può essere causato da una risorsa aggiornata in modo errato. Per determinare se questo
problema ti riguarda e per risolverlo, controlla i log anthos-cluster-operator
e cerca errori simili alle seguenti voci:
controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
Queste voci sono un sintomo di una risorsa aggiornata in modo errato, dove {RESOURCE_NAME} è il nome della risorsa problematica.
Soluzione
Se riscontri questi errori nei log, procedi nel seguente modo:
Utilizza kubectl edit per rimuovere l'annotazione kubectl.kubernetes.io/last-applied-configuration dalla risorsa contenuta nel messaggio di log.
Salva e applica le modifiche alla risorsa.
Riprova a eseguire l'upgrade del cluster.
Upgrade e aggiornamenti
1,10, 1,11, 1,12
Gli upgrade sono bloccati per i cluster con funzionalità che utilizzano il gateway di rete per GDC
Gli upgrade dei cluster da 1.10.x a 1.11.x non riescono per i cluster che utilizzano il gateway NAT in uscita o il bilanciamento del carico in bundle con BGP. Entrambi queste funzionalità utilizzano il gateway di rete per GDC. Gli upgrade del cluster si bloccano al messaggio della riga di comando Waiting for upgrade to complete... e agli errori dei log anthos-cluster-operator come il seguente:
apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...
Soluzione
Per sbloccare l'upgrade, esegui questi comandi sul cluster di cui stai eseguendo l'upgrade:
Nodi non contrassegnati se non utilizzi la procedura della modalità di manutenzione
Se esegui cluster della versione 1.12.0
(anthosBareMetalVersion: 1.12.0) o precedente e utilizzi manualmente
kubectl cordon su un nodo, GKE su Bare Metal potrebbe annullare l'impostazione del nodo
prima che tu sia pronto, nel tentativo di riconciliare lo stato previsto.
Soluzione
Per la versione 1.12.0 e i cluster precedenti, utilizza la modalità di manutenzione per contrassegnare e svuotare i nodi in modo sicuro.
Nella versione 1.12.1 (anthosBareMetalVersion: 1.12.1) o successiva, GKE su Bare Metal non contrassegna i nodi in modo imprevisto quando utilizzi kubectl cordon.
Operazione
1,11
I cluster di amministrazione della versione 11 che utilizzano un mirroring del registro non possono gestire i cluster della versione 1.10
Se il cluster di amministrazione è alla versione 1.11 e utilizza un mirroring del registro, non può gestire i cluster utente in una versione secondaria inferiore. Questo problema riguarda le operazioni di reimpostazione, aggiornamento ed upgrade sul cluster utente.
Per determinare se questo problema ti riguarda, controlla i log per le operazioni del cluster, come creazione, upgrade o reimpostazione. Questi log si trovano
nella cartella bmctl-workspace/CLUSTER_NAME/
per impostazione predefinita. Se si verifica il problema, i log contengono il seguente messaggio di errore:
flag provided but not defined: -registry-mirror-host-to-endpoints
Operazione
1,10, 1,11
Il secret kubeconfig viene sovrascritto
Quando viene eseguito sui cluster utente, il comando bmctl check cluster sovrascrive il secret di kubeconfig del cluster utente con kubeconfig del cluster di amministrazione. Se sovrascrivi il file, le operazioni standard del cluster, come l'aggiornamento e l'upgrade, non riescono per i cluster utente interessati. Questo problema si applica ai cluster GKE su Bare Metal versione 1.11.1 e precedenti.
Per determinare se questo problema interessa un cluster utente, esegui questo comando:
ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
USER_CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi per i cluster GKE su Bare Metal sono il nome del cluster preceduto da cluster-. Ad esempio, se assegni al cluster il nome test, lo spazio dei nomi predefinito è cluster-test.
USER_CLUSTER_NAME: il nome del cluster utente da controllare.
Se il nome del cluster nell'output (vedi contexts.context.cluster nel seguente output di esempio) è il nome del cluster di amministrazione, il cluster utente specificato è interessato.
I seguenti passaggi ripristinano la funzione in un cluster utente interessato
(USER_CLUSTER_NAME):
Individua il file kubeconfig del cluster utente. GKE su Bare Metal genera il file kubeconfig sulla workstation di amministrazione quando crei un cluster. Per impostazione predefinita, il file si trova nella directory bmctl-workspace/USER_CLUSTER_NAME.
Verifica che kubeconfig sia corretto nel cluster utente kubeconfig:
kubectl get nodes \
--kubeconfig PATH_TO_GENERATED_FILE
Sostituisci PATH_TO_GENERATED_FILE con il
percorso del file kubeconfig del cluster utente. La risposta restituisce dettagli sui nodi per il cluster utente. Verifica che i nomi delle macchine siano corretti per il cluster.
Esegui questo comando per eliminare il file kubeconfig danneggiato nel cluster di amministrazione:
Creazione di uno snapshot come utente con accesso non root
Se utilizzi containerd come runtime del container, l'esecuzione dello snapshot come utente non root richiede che /usr/local/bin si trovi nel PERCORSO dell'utente.
In caso contrario, l'operazione non andrà a buon fine e verrà visualizzato un errore crictl: command not found.
Se non hai eseguito l'accesso come utente root, viene utilizzato sudo
per eseguire i comandi dello snapshot. Il PERCORSO sudo può essere diverso dal
profilo principale e non può contenere /usr/local/bin.
Soluzione
Aggiorna secure_path in /etc/sudoers per
includere /usr/local/bin. In alternativa, crea un link simbolico per crictl in un'altra directory /bin.
Logging e monitoraggio
1,1
stackdriver-log-forwarder ha [parser:cri] invalid
time format log degli avvisi
[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'
Soluzione alternativa:
Visualizza le procedure alternative
Esegui l'upgrade del cluster alla versione 1.11.0 o successive.
Se non riesci a eseguire immediatamente l'upgrade dei cluster, segui questi passaggi per aggiornare l'espressione regolare di analisi CRI:
Per impedire 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 da 1.10 a 1.15 dei cluster GKE su Bare Metal, alcuni clienti hanno riscontrato una fatturazione inaspettatamente elevata per Metrics volume nella pagina Fatturazione. Questo problema ti riguarda solo quando si applicano tutte le
seguenti circostanze:
Il monitoraggio delle applicazioni è abilitato (enableStackdriverForApplications=true)
I pod di applicazione hanno l'annotazione prometheus.io/scrap=true
Per verificare se questo problema ti riguarda,
elenca le metriche definite dall'utente. Se visualizzi la fatturazione per metriche indesiderate, questo
problema si applica al tuo caso.
Soluzione
Se ti interessa questo problema, ti consigliamo di eseguire l'upgrade dei cluster alla versione 1.12 e di passare alla nuova soluzione di monitoraggio delle applicazioni managed-service-for-prometheus che risolvano questo problema:
Flag separati per controllare la raccolta dei log delle applicazioni rispetto alle metriche dell'applicazione
Google Cloud Managed Service in bundle per Prometheus
Se non riesci a eseguire l'upgrade alla versione 1.12, segui questi passaggi:
Trova i pod e i servizi di origine con fatturazione indesiderata:
kubectl --kubeconfig KUBECONFIG \
get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
services -A -o yaml | grep 'prometheus.io/scrape: "true"'
Rimuovi l'annotazione prometheus.io/scrap=true dal pod o dal servizio.
Logging e monitoraggio
1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28
Le modifiche apportate a metrics-server-config non sono rese persistenti
Un'elevata densità di pod può, in casi estremi, generare un overhead di logging e monitoraggio eccessivo, che può causare l'arresto e il riavvio di Metrics Server. Puoi
modificare il ConfigMap metrics-server-config per allocare più risorse
e mantenere in esecuzione il server delle metriche. Tuttavia, a causa della riconciliazione,
le modifiche apportate a metrics-server-config possono
essere ripristinate al valore predefinito durante un'operazione di aggiornamento o upgrade del cluster.
Metrics Server non viene interessato immediatamente, ma al successivo riavvio riprende il ConfigMap ripristinato ed è vulnerabile a un sovraccarico eccessivo.
Soluzione
Per 1.11.x, puoi creare uno script della modifica di ConfigMap ed eseguirla insieme agli aggiornamenti o agli upgrade al cluster. A partire dalla versione 1.12 e successive, contatta l'assistenza.
Logging e monitoraggio
1,11, 1,12
Le metriche deprecate influiscono sulla dashboard di Cloud Monitoring
Diverse metriche di GKE su Bare Metal sono state deprecate e, a partire da GDCV per Bare Metal release 1.11, i dati per queste metriche deprecate non vengono più raccolti. Se utilizzi queste metriche in uno qualsiasi dei tuoi criteri di avviso, non ci saranno dati per attivare la condizione di avviso.
La seguente tabella elenca le singole metriche deprecate e la metrica che le sostituisce.
Nelle versioni dei cluster GKE su Bare Metal precedenti alla 1.11, il file di definizione dei criteri per l'avviso Anthos on baremetal node cpu usage exceeds
80 percent (critical) consigliato utilizza le metriche deprecate. Il file di definizione JSON node-cpu-usage-high.json viene aggiornato per le release 1.11.0 e successive.
Soluzione
Per eseguire la migrazione alle metriche di sostituzione:
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 Stato del nodo del 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 osservare che stackdriver-log-forwarder continua ad arrestarsi in modo anomalo con un errore CrashloopBackOff. Se si verifica questo problema, i log contengono voci simili alla seguente
[2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0 0x5590aa24bdd5
in validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1 0x5590aa24c502 in stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2 0x5590aa24e509 in cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3 0x5590aa19c0de in output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4 0x5590aa6889a6 in co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5 0xffffffffffffffff in ???() at ???:0
Soluzione alternativa:
Esegui la pulizia dei blocchi del buffer per il forwarding dei log di Stackdriver.
Nota: nei comandi seguenti, sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.
Questi log degli errori possono essere tranquillamente ignorati poiché le metriche a cui fanno riferimento non sono supportate e non sono critiche per scopi di monitoraggio.
Logging e monitoraggio
1,10, 1,11
Interruzioni dell'esportazione delle metriche a intermittenza
I cluster GKE su Bare Metal potrebbero riscontrare interruzioni nell'esportazione normale e continua delle metriche o metriche mancanti su alcuni nodi. Se questo problema interessa i tuoi cluster, potresti notare (almeno) lacune nei dati per le seguenti metriche:
Il comando trova cpu: 50m se le modifiche sono state
applicate.
Networking
1,1
Più gateway predefiniti interrompono la connettività agli endpoint esterni
La presenza di più gateway predefiniti in un nodo può causare interruzioni della connettività dall'interno di un pod a endpoint esterni, ad esempio google.com.
Per determinare se questo problema ti riguarda, esegui questo comando sul nodo:
ip route show
Più istanze di default nella risposta indicano che il problema ti riguarda.
Networking
1,12
Le modifiche alle risorse personalizzate di networking dei cluster utente vengono sovrascritte
I cluster GKE su Bare Metal versione 1.12.x non ti impediscono di modificare manualmente le risorse personalizzate di networking nel tuo cluster utente. GKE su Bare Metal riconcilia le risorse personalizzate nei cluster utente con le risorse personalizzate nel cluster di amministrazione durante gli upgrade del cluster. Questa riconciliazione sovrascrive qualsiasi modifica apportata direttamente alle risorse personalizzate di networking nel cluster utente. Le risorse personalizzate di networking devono essere modificate solo nel cluster di amministrazione, ma i cluster della versione 1.12.x non applicano questo requisito.
Modifica queste risorse personalizzate nel cluster di amministrazione e il passaggio di riconciliazione applica le modifiche ai cluster utente.
Soluzione
Se hai modificato una delle risorse personalizzate menzionate in precedenza su un cluster utente, modifica le risorse personalizzate corrispondenti nel cluster di amministrazione in modo che corrispondano prima dell'upgrade. Questo passaggio garantisce che le modifiche alla configurazione vengano conservate. La versione 1.13.0 e successive del cluster GKE su Bare Metal ti impedisce di modificare le risorse personalizzate di networking direttamente sui tuoi cluster utente.
Networking
1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28
Errori di connettività dei pod e filtraggio del percorso inverso
GKE su Bare Metal configura il filtro del percorso inverso sui nodi per disabilitare la convalida dell'origine (net.ipv4.conf.all.rp_filter=0).
Se l'impostazione rp_filter viene modificata in 1 o
2, i pod avranno esito negativo a causa di timeout della comunicazione
fuori nodo.
Il filtro del percorso inverso è impostato su rp_filter file nella
cartella di configurazione IPv4 (net/ipv4/conf/all). Questo valore
può anche essere sostituito da sysctl, che archivia le impostazioni di filtro del percorso inverso in un file di configurazione della sicurezza di rete, come
/etc/sysctl.d/60-gce-network-security.conf.
Soluzione
La connettività dei pod può essere ripristinata eseguendo una delle seguenti
soluzioni alternative:
Imposta di nuovo il valore di net.ipv4.conf.all.rp_filter su
0 manualmente, quindi esegui sudo sysctl -p per applicare
la modifica.
Oppure
Riavvia il pod anetd per impostare
net.ipv4.conf.all.rp_filter di nuovo su 0. Per riavviare il pod anetd, utilizza i comandi seguenti per individuare ed eliminare il pod anetd; al suo posto verrà avviato un nuovo pod anetd:
Dopo aver eseguito una delle soluzioni alternative, verifica che il valore net.ipv4.conf.all.rp_filter sia impostato su 0 eseguendo sysctl net.ipv4.conf.all.rp_filter su ciascun nodo.
Gli indirizzi IP del cluster di bootstrap (tipo) e gli indirizzi IP dei nodi cluster si sovrappongono
192.168.122.0/24 e 10.96.0.0/27 sono i CIDR predefiniti di pod e servizi utilizzati dal cluster di bootstrap (tipo).
I controlli preflight non andranno a buon fine se si sovrappongono agli indirizzi IP delle macchine dei nodi cluster.
Soluzione
Per evitare il conflitto, puoi passare i flag
--bootstrap-cluster-pod-cidr e
--bootstrap-cluster-service-cidr a bmctl
per specificare valori diversi.
Sistema operativo
1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28
Creazione o upgrade del cluster non riusciti su CentOS
Nel dicembre 2020, la community di CentOS e Red Hat hanno annunciato il ritiro di CentOS. Il 31 gennaio 2022 CentOS 8 ha raggiunto la fine del ciclo di vita
(EOL). A causa della fine del ciclo di vita, i repository yum hanno smesso di funzionare per CentOS, causando un errore delle operazioni di creazione e upgrade del cluster. Questo si applica a tutte le versioni supportate di CentOS e influisce su tutte le versioni di GKE su cluster Bare Metal.
Soluzione
Visualizza le procedure alternative
Come soluzione alternativa, esegui questi comandi per fare in modo che CentOS utilizzi un feed di archivio:
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
/etc/yum.repos.d/CentOS-Linux-*
Come soluzione a lungo termine, valuta la possibilità di eseguire la migrazione a un altro sistema operativo supportato.
Sicurezza
1,10; 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28
Il container non può scrivere in VOLUME definito in Dockerfile
con containerd e SELinux
Se utilizzi containerd come runtime del container e il tuo sistema operativo ha SELinux abilitato, VOLUME definito nel Dockerfile dell'applicazione potrebbe non essere accessibile in scrittura. Ad esempio, i container creati con il seguente Dockerfile non sono in grado di scrivere nella cartella /tmp.
FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp
Per verificare se questo problema ti riguarda, esegui questo comando sul nodo che ospita il container problematico:
ausearch -m avc
Se questo problema ti riguarda, viene visualizzato un errore denied
come il seguente:
Per risolvere il problema, apporta una delle seguenti modifiche:
Disattiva SELinux.
Non utilizzare la funzionalità VOLUME all'interno di Dockerfile.
Upgrade e aggiornamenti
1,10, 1,11, 1,12
Il rilevatore dei problemi dei nodi non è abilitato per impostazione predefinita dopo gli upgrade del cluster
Quando esegui l'upgrade di GKE su cluster Bare Metal, il rilevatore di problemi dei nodi non è abilitato per impostazione predefinita. Questo problema si applica agli upgrade dalle release 1.10 alla 1.12.1 ed è stato risolto nella release 1.12.2.
Soluzione alternativa:
Per abilitare il rilevatore dei problemi dei nodi:
Verifica se il servizio node-problem-detector systemd è in esecuzione sul nodo.
Utilizza il comando SSH e connettiti al nodo.
Controlla se il servizio node-problem-detector systemd è in esecuzione sul nodo:
systemctl is-active node-problem-detector
Se il risultato del comando mostra inactive, significa che node-problem-detector non è in esecuzione sul nodo.
Per abilitare il rilevatore dei problemi dei nodi, utilizza il comando kubectl edit e modifica il ConfigMap di node-problem-detector-config. Per ulteriori
informazioni, consulta la sezione
Rilevatore problemi dei nodi.
Operazione
1,9, 1,10
Il backup del cluster non va a buon fine quando si utilizza un accesso non root
Il comando bmctl backup cluster non riesce se
nodeAccess.loginUser è impostato su un nome utente non root.]
Soluzione alternativa:
Questo problema si applica alle versioni 1.9.x, 1.10.0 e 1.10.1 ed è stato risolto nella versione 1.10.2 e successive.
Networking
1,10, 1,11, 1,12
I servizi di bilanciamento del carico non funzionano con i container sulla rete host del piano di controllo
Esiste un bug in anetd per cui i pacchetti vengono ignorati per i servizi LoadBalancer se i pod di backend sono entrambi in esecuzione sul nodo del piano di controllo e utilizzano il campo hostNetwork: true nelle specifiche del container.
Il bug non è presente nella versione 1.13 o successive.
Soluzione alternativa:
Le seguenti soluzioni alternative possono aiutarti se utilizzi un servizio LoadBalancer supportato dai pod hostNetwork:
Eseguili sui nodi worker (non sui nodi del piano di controllo).
Errore durante il pull dell'immagine per il pod anthos-version-$version$ orfano
L'upgrade dei cluster da 1.12.x a 1.13.x potrebbe osservare un errore nel pod anthos-version-$version$ con errore ImagePullBackOff.
Ciò si verifica a causa della race condition di anthos-cluster-operator in fase di upgrade e non dovrebbe influire sulle normali funzionalità dei cluster.
Il bug non è presente dopo la versione 1.13 o successive.
Soluzione alternativa:
Elimina il job del programma di installazione della versione dinamica entro il giorno kubectl delete job anthos-version-$version$ -n kube-system
Upgrade e aggiornamenti
1,13
Non è possibile eseguire l'upgrade a 1.13.0 dei cluster di 1.12 con upgrade dalla versione 1.11
Non è possibile eseguire l'upgrade alla versione 1.13.0 dei cluster della versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11. Questo problema di upgrade non si applica ai cluster creati nella versione 1.12.
Per determinare se il problema ti riguarda, controlla i log del job di upgrade che contiene la stringa upgrade-first-no* nel cluster di amministrazione.
Se visualizzi il seguente messaggio di errore, il problema ti riguarda.
Utilizzo elevato della CPU per stackdriver-operator
Si è verificato un problema in stackdriver-operator che riduce il consumo di tempo di CPU più elevato del normale. L'utilizzo normale della CPU è inferiore a 50
milliCPU (50m) per stackdriver-operator in stato
inattivo. La causa è una mancata corrispondenza delle risorse dei certificati che
stackdriver-operator si applica con le aspettative di
cert-manager. Questa mancata corrispondenza causa una race condition tra
cert-manager e stackdriver-operator
nell'aggiornamento di queste risorse.
Questo problema potrebbe comportare una riduzione delle prestazioni sui cluster con disponibilità di CPU limitata.
Soluzione alternativa:
Fino a quando non potrai eseguire l'upgrade a una versione che ha risolto questo bug, usa la seguente soluzione alternativa:
Per fare lo scale down temporaneo di stackdriver-operator a 0 repliche, applica una risorsa personalizzata AddonConfiguration:
Lo scraping di metriche basate sulle annotazioni non funziona
Nella release secondaria GDCV per Bare Metal 1.16, il campo enableStackdriverForApplications nella specifica delle risorse personalizzate stackdriver è deprecato. Questo campo è sostituito da due campi, enableCloudLoggingForApplications e enableGMPForApplications, nella risorsa personalizzata Stackdriver.
Ti consigliamo di utilizzare Google Cloud Managed Service per Prometheus per monitorare i carichi di lavoro. Utilizza il campo enableGMPForApplications per abilitare questa funzionalità.
Se fai affidamento sulla raccolta di metriche attivata dalle annotazioni prometheus.io/scrape sui tuoi carichi di lavoro, puoi utilizzare il flag della porta delle funzionalità annotationBasedApplicationMetrics per mantenere il comportamento precedente. Tuttavia, esiste un problema che impedisce a annotationBasedApplicationMetrics di funzionare correttamente, impedendo la raccolta delle metriche dalle applicazioni in Cloud Monitoring.
Soluzione alternativa:
Per risolvere questo problema, esegui l'upgrade del cluster alla versione 1.16.2 o successive.
La raccolta di metriche dei carichi di lavoro basata su annotazioni abilitata
dalla porta di funzionalità annotationBasedApplicationMetrics raccoglie
metriche per gli oggetti che hanno l'annotazione
prometheus.io/scrape. Molti sistemi software con origine open source possono utilizzare questa
annotazione. Se continui a utilizzare questo metodo di raccolta delle metriche, tieni presente questa dipendenza per evitare di sorprenderti dagli addebiti relativi alle metriche in Cloud Monitoring.
Dashboard ed elimina la dashboard dello stato del nodo del cluster Anthos.