Versione 1.11. Questa versione non è più supportata. Per ulteriori informazioni, consulta le norme relative all'assistenza per le versioni. Per informazioni su come eseguire l'upgrade alla versione 1.12, consulta la pagina relativa all'upgrade di Anthos su Bare Metal nella documentazione della versione 1.12.
Questa pagina elenca tutti i problemi noti per Anthos clusters on bare metal. Per filtrare i problemi noti in base a una versione del prodotto o a una categoria, seleziona i filtri desiderati dai seguenti menu a discesa.
Seleziona la versione di Anthos clusters on bare metal:
Seleziona la categoria del problema:
In alternativa, cerca il tuo problema:
Categoria
Versioni identificate
Problema e soluzione alternativa
Networking, operazione
1.10, 1.11, 1.12, 1.13, 1.14
Componenti di Anthos Network Gateway eliminati o in attesa a causa di una classe di priorità mancante
I pod del gateway di rete in kube-system potrebbero mostrare lo stato Pending o Evicted, come mostrato nel seguente output di esempio condensato:
Questi errori indicano eventi di eliminazione o l'impossibilità di pianificare i pod a causa delle risorse del nodo. Poiché i pod del gateway di rete Anthos non hanno
prioritàClasse, hanno la stessa priorità predefinita di altri carichi di lavoro.
Quando i nodi sono limitati dalle risorse, potrebbero essere rimossi i pod del gateway di rete. Questo comportamento è particolarmente negativo per il DaemonSet ang-node, poiché questi pod devono essere pianificati su un nodo specifico e non possono essere migrati.
Soluzione:
Esegui l'upgrade alla versione 1.15 o successive.
Come soluzione a breve termine, puoi assegnare manualmente una PrioritàClasse ai componenti del gateway Anthos di rete. Il controller Anthos clusters on bare metal
sovrascrive queste modifiche manuali durante un processo di riconciliazione, ad esempio
durante un upgrade del cluster.
Assegna la priorità Priority system-cluster-critical ai deployment dei controller di cluster ang-controller-manager e autoscaler.
Assegna la priorità Priority di system-node-critical al
DaemonSet di nodi ang-daemon.
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 dei cluster versione 1.15.0, 1.15.1 o 1.15.2 o l'upgrade dei cluster alla versione 1.15.0, 1.15.1 o 1.15.2 non riesce quando il nome del cluster supera i 48 caratteri (versione 1.15.0) o 45 (versione 1.15.1 o 1). Durante le operazioni di creazione e upgrade dei cluster, Anthos clusters on 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 per il controllo di integrità è CLUSTER_NAME-kubernetes-CLUSTER_VER.
Per i nomi di cluster lunghi, il nome della risorsa di controllo di integrità supera la restrizione di lunghezza dei caratteri Kubernetes 63, che impedisce la creazione della risorsa di controllo di integrità.
Senza un controllo di integrità riuscito, l'operazione del cluster non riesce.
Per verificare se hai riscontrato questo problema, usa kubectl describe per controllare la risorsa in errore:
Se questo problema ti riguarda, la risposta contiene un avviso per un
ReconcileError come il seguente:
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileError 77s (x15 over 2m39s) healthcheck-controller Reconcile error, retrying: 1 error occurred:
* failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]
Soluzione
Per sbloccare l'upgrade o la creazione del cluster, puoi bypassare il controllo di integrità. Utilizza il seguente comando per applicare il patch alla risorsa personalizzata
controllo di integrità con lo stato di superamento: (status: {pass: true})
Impossibile eseguire l'upgrade alla versione 1.15.x per i cluster delle versioni 1.14.0 e 1.14.1 con funzionalità in anteprima
Se per i cluster 1.14.0 e 1.14.1 è abilitata una funzionalità di anteprima, non è possibile eseguire l'upgrade alla versione 1.15.x. Questo
vale per le funzionalità di anteprima, come la possibilità di creare un cluster senza
kube-proxy, abilitato con la seguente annotazione nel file di
configurazione del cluster:
Se hai
riscontrato questo problema, durante l'upgrade del cluster viene visualizzato un errore simile al seguente:
[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:
Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version
Questo problema è stato risolto nei Anthos clusters on bare metal versione 1.14.2 e successive.
Soluzione:
Se non riesci a eseguire l'upgrade dei cluster alla versione 1.14.2 o successive prima di eseguire l'upgrade alla versione 1.15.x, puoi eseguire l'upgrade direttamente alla versione 1.15.x utilizzando un cluster bootstrap:
bmctl upgrade cluster --use-bootstrap=true
Operazione
1,15
I cluster versione 1.15 non accettano indirizzi IP mobili duplicati
Il Anthos Gateway di rete non consente di creare nuove risorse personalizzate NetworkGatewayGroup che contengono indirizzi IP in spec.floatingIPs che sono già utilizzate nelle risorse personalizzate NetworkGatewayGroup esistenti. Questa regola viene applicata da un webhook nei Anthos clusters on bare metal versione 1.15.0 e successive. Gli indirizzi IP mobili duplicati e preesistenti non causano errori. Il webhook impedisce solo la creazione di nuove risorse personalizzate di NetworkGatewayGroups con indirizzi IP duplicati.
Il messaggio di errore del webhook identifica l'indirizzo IP in conflitto e la risorsa personalizzata esistente che lo sta già utilizzando:
IP address exists in other gateway with name default
La documentazione iniziale per le funzionalità di rete avanzate, come il gateway NAT in uscita, non mette in evidenza gli indirizzi IP duplicati.
Inizialmente, solo la risorsa NetworkGatewayGroup denominata default è stata riconosciuta. Il gateway di rete Anthos ora riconosce tutte le NetworkGatewayGroup risorse personalizzate nello spazio dei nomi di sistema. Le risorse personalizzate di NetworkGatewayGroup
vengono rispettate così come sono.
Soluzione:
Si verificano errori per la creazione di una nuova risorsa personalizzata solo
NetworkGatewayGroup.
Per correggere l'errore:
Utilizza il comando seguente per elencare NetworkGatewayGroups risorse personalizzate:
kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
-n kube-system -o yaml
Apri le risorse personalizzate esistenti di NetworkGatewayGroup e rimuovi eventuali indirizzi IP mobili in conflitto (spec.floatingIPs):
Per applicare le modifiche, chiudi e salva le risorse personalizzate modificate.
Runtime VM Anthos
1,13,7
Le VM potrebbero non essere avviate su cluster 1.13.7 che utilizzano un registro privato
Quando abiliti Anthos VM Runtime su un cluster nella versione 1.13.7 nuova o aggiornata che utilizza un registro privato, le VM che si connettono alla rete del nodo 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 tua VM utilizza la rete nodo, alcuni pod potrebbero segnalare errori di pull delle immagini come nel seguente esempio:
macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m
Questo problema è stato risolto nei Anthos clusters on bare metal versione 1.14.0 e successive.
Soluzione
Se non riesci a eseguire l'upgrade dei tuoi cluster immediatamente, puoi estrarre manualmente le immagini. I comandi seguenti estraggono l'immagine del plug-in CNI per macvtap per la tua VM ed eseguono il push al 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 tipo di cluster, il pod gke-metric-agent non si avvia
Durante la creazione del cluster nel tipo di cluster, 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 bootstrap vedrai la seguente voce:
Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
Verrà visualizzato l'errore "Impossibile eseguire il pull" nel pod:
gcr.io/gke-on-prem-staging/gke-metrics-agent
Soluzione
Nonostante gli errori, il processo di creazione del cluster non è bloccato in quanto lo scopo del pod gke-metrics-agent è in genere il cluster di facilitare la percentuale di successo della creazione del cluster e per il monitoraggio e il monitoraggio interni.
Pertanto, puoi ignorare questo errore.
Soluzione
Nonostante gli errori, il processo di creazione del cluster non è bloccato in quanto lo scopo del pod gke-metrics-agent è in genere il cluster di facilitare la percentuale di successo della creazione del cluster e per il monitoraggio e il monitoraggio interni.
Pertanto, puoi ignorare questo errore.
Operazione, networking
1.12, 1.13, 1.14, 1.15
L'accesso a un endpoint di servizio IPv6 causa l'arresto anomalo del nodo LoadBalancer su CentOS o RHEL
Quando accedi a un servizio a doppio stack (un servizio che dispone di endpoint sia IPv4 sia 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 la versione kernel prima della data kernel-4.18.0-372.46.1.el8_6.
Se ritieni che questo problema ti riguardi, controlla la versione del kernel sul nodo LoadBalancer utilizzando il comando uname -a.
Soluzione:
Aggiorna il nodo LoadBalancer alla versione del kernel kernel-4.18.0-372.46.1.el8_6 o successiva. Questa versione del kernel è disponibile per impostazione predefinita in CentOS e RHEL 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 notare problemi di connettività intermittenti per un servizio NodePort o LoadBalancer. Ad esempio, potrebbero verificarsi errori intermittenti di handshake TLS o reimpostazione della connessione. Questo problema è stato risolto per Anthos clusters on bare metal versioni 1.14.1 e successive.
Per verificare se questo problema ti riguarda, guarda le regole di forwarding iptables 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 riguardarti. L'output di esempio seguente mostra un nodo in cui
esiste il problema:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
Soluzione:
Riavvia il pod anetd sul nodo configurato in modo errato. Dopo aver riavviato il pod anetd, la regola di forwarding in iptables deve essere configurata correttamente.
L'output di esempio seguente mostra che la regola CILIUM_FORWARD è ora configurata correttamente prima della regola KUBE-FORWARD:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
Upgrade e aggiornamenti
1.9, 1.10
La funzionalità di anteprima non conserva le informazioni originali su autorizzazione e proprietario
La funzionalità di anteprima del cluster 1.9.x che utilizza bmctl 1.9.x non conserva le informazioni originali sull'autorizzazione e sul proprietario. Per verificare se questa funzionalità ti riguarda, estrai il file di cui hai eseguito il backup utilizzando il comando seguente:
tar -xzvf BACKUP_FILE
Soluzione
Verifica se il metadata.json è presente e se il valore di 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/il ripristino.
Upgrade e creazione
1,14,2
clientconfig-operator bloccato nello stato In attesa con CreateContainerConfigError
Se hai eseguito l'upgrade a un cluster della versione 1.14.2 o ne hai creato una con una configurazione OIDC/LDAP, potresti vedere il pod clientconfig-operator bloccato in stato in attesa. Con questo problema, ci sono due pod clientconfig-operator, uno in stato in esecuzione e l'altro in stato in attesa.
Questo problema si applica solo ai Anthos clusters on bare metal versione 1.14.2. Le versioni precedenti, 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 1.15.0 e versioni successive.
Soluzione:
Come soluzione alternativa, puoi applicare un patch al deployment di clientconfig-operator per aggiungere ulteriore contesto di sicurezza e assicurarti che il deployment sia pronto.
Utilizza il comando seguente 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 avere esito negativo con il seguente errore: x509: certificate signed by unknown authority.
Se riscontri questo problema, il comando bmctl potrebbe restituire il seguente messaggio prima che non risponda:
Signing CA completed in 3/0 control-plane nodes
In questo caso, alla fine il comando non riuscirà. Il log ruota-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 arresti anomali 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 fa sì che i nodi passino da uno stato all'altro tra Ready e NotReady e potrebbe causare un errore di installazione del cluster. Questo problema può verificarsi quando il server API è sotto carico elevato.
Per verificare se questo problema ti riguarda, controlla se
i pod ipam-controller-manager non funzionano con
gli errori CrashLoopBackOff:
kubectl -n kube-system get pods | grep ipam-controller-manager
L'output di esempio seguente mostra i pod in stato CrashLoopBackOff:
I cluster che eseguono etcd 3.4.13 o versioni precedenti potrebbero riscontrare la fame di orologi e risorse non operative, il che può causare i seguenti problemi:
Pianificazione dei pod interrotta
Impossibile registrare i nodi
kubelet non osserva le modifiche ai pod
Questi problemi possono rendere il cluster non funzionale.
Questo problema è stato risolto nei cluster Anthos sulle versioni bare metal 1.12.9, 1.13.6, 1.14.3 e successive. Queste release più recenti utilizzano la versione 3.4.21 di etcd. Tutte le versioni precedenti di Anthos clusters on bare metal sono interessate da questo problema.
Soluzione
Se non puoi eseguire l'upgrade immediatamente, puoi ridurre il rischio di errori del cluster riducendo il numero di nodi nel cluster. Rimuovi i nodi finché la metrica etcd_network_client_grpc_sent_bytes_total non è inferiore a 300 MBps.
Per visualizzare questa metrica in Metrics Explorer:
Vai a Metrics Explorer nella console Google Cloud:
Espandi la sezione Seleziona una metrica, inserisci Kubernetes Container
nella barra dei filtri e utilizza i sottomenu per selezionare la metrica:
Nel menu Risorse attive, seleziona Container Kubernetes.
Nel menu Categorie 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
Il 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:
Se lo stato dell'oggetto SriovNetworkNodeState è "Non riuscito", aggiorna i Anthos clusters on bare metal versione 1.11.7 o successiva o 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 di alcuni nodi worker potrebbe essere impostata su false. Nella risorsa nodo, verrà visualizzato un errore accanto alla condizione Pronto, simile all'esempio seguente:
container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
Quando accedi alla macchina bloccata, la configurazione CNI sulla macchina è vuota:
sudo ls /etc/cni/net.d/
Soluzione
Riavvia il pod anetd del nodo eliminandolo.
Upgrade e aggiornamenti della sicurezza
1,1
Più rotazioni del certificato provenienti dal gestore di certificati generano incoerenze
Dopo più rotazioni manuali o automatiche dei certificati, il pod webhook, come anthos-cluster-operator, non viene aggiornato con i nuovi certificati emessi da cert-manager. Qualsiasi aggiornamento alla risorsa personalizzata del cluster non riesce e genera un errore simile al seguente:
Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")
Questo problema può verificarsi nei seguenti casi:
Se hai eseguito due rotazioni del certificato manuali con gestione dei certificati su un cluster più vecchio di 180 giorni e non hai mai riavviato l'operatore cluster anthos-cluster.
Se hai eseguito un cert-manager manuale di rotazioni del certificato su un cluster più vecchio di 90 giorni e non hai mai riavviato l'operatore cluster anthos-cluster.
Soluzione
Riavvia il pod terminando l'operatore anthos-cluster.
Upgrade e aggiornamenti
1,14,0
Pod di deployment del controller del ciclo di vita obsoleti creati durante l'upgrade del cluster utente
Nei cluster di amministrazione della versione 1.14.0 è possibile creare uno o più pod del deployment del controller del ciclo di vita obsoleti durante gli upgrade del cluster utente.
Questo problema si applica ai cluster utente inizialmente creati nelle versioni precedenti alla 1.12. I pod creati involontariamente non impediscono le operazioni di upgrade, ma potrebbero trovarsi in stato anormale. Ti consigliamo di rimuovere i pod obsoleti.
Questo problema è stato risolto nella versione 1.14.1.
Soluzione:
Per rimuovere i pod del deployer del controller del ciclo di vita obsoleti:
Elenca le risorse del controllo preliminare:
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A
L'output ha il seguente aspetto:
NAMESPACE NAME PASS AGE
cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31c true 20d
cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31cd6jv6 false 20d
dove ci-87a021b9dcbb31c è il nome del cluster.
Elimina le risorse il cui valore nella colonna PASS è true o false.
Ad esempio, per eliminare le risorse nell'output di esempio precedente, utilizza i comandi seguenti:
Lo stato di BGPSession cambia continuamente a causa del numero elevato di route in entrata
I cluster Anthos su una rete avanzata bare metal non riescono a gestire correttamente le sessioni BGP quando i 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à fa sì che la sessione venga eliminata per inattività.
I comportamenti indesiderati nelle sessioni BGP che potresti notare e indicare
un problema includono quanto segue:
Eliminazione e ricreazione continua di bgpsession.
bgpsession.status.state non diventa mai Established
Route che non pubblicizzano o vengono ripetutamente pubblicizzati e
ritirate.
I problemi di bilanciamento del carico BGP potrebbero essere evidenti con problemi di connettività ai servizi LoadBalancer.
Il problema relativo al BGP FlatIP potrebbe essere evidente con problemi di connettività ai pod.
Per determinare se i problemi BGP sono causati da peer
remoti che pubblicizzano troppe route, utilizza i comandi seguenti per esaminare gli
stati e l'output associati:
Utilizza kubectl get bgpsessions sul cluster interessato.
L'output mostra bgpsessions con stato "Non stabilito" e l'ultimo tempo del report conta continuamente fino a circa 10-12 secondi prima che venga reimpostato su zero.
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 sono in fase di eliminazione:
kubectl logs ang-controller-manager-POD_NUMBER
Sostituisci POD_NUMBER con il pod leader nel cluster.
Soluzione:
Riduci o elimina il numero di route annunciate dal peer remoto al cluster con un criterio di esportazione.
Nei Anthos clusters on 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
Timeout dell'applicazione causati da errori di inserimento della tabella di connessione
I cluster in esecuzione su un sistema operativo Ubuntu che utilizza il kernel 5.15 o versioni successive sono suscettibili di errori di inserimento della tabella di connessione netfilter (conntrack). Gli errori di inserzione possono verificarsi anche quando la tabella di monitoraggio ha spazio per nuove voci. Gli errori sono causati da modifiche nel kernel 5.15 e versioni successive che limitano gli inserimenti di tabelle in base alla lunghezza della catena.
Per verificare se hai riscontrato questo problema, puoi controllare le statistiche del sistema di monitoraggio delle connessioni nel kernel con il seguente comando:
Se il valore chaintoolong nella risposta è un numero diverso da zero, questo problema ti riguarda.
Soluzione
La mitigazione a breve termine consiste nell'aumentare le dimensioni sia della tabella hash netfiler (nf_conntrack_buckets) che della tabella di monitoraggio delle connessioni netfilter (nf_conntrack_max). Utilizza i seguenti comandi su ciascun nodo del cluster per aumentare le dimensioni delle tabelle:
Sostituisci TABLE_SIZE con una nuova dimensione in byte. Il valore predefinito della dimensione 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 di eseguire l'upgrade in modo da poter ripristinare la versione precedente se l'upgrade non va a buon fine.
Un problema con il comando bmctl restore cluster causa un errore nel ripristino dei backup dei cluster con le versioni identificate. Questo problema riguarda in modo specifico gli upgrade, in cui ripristini un backup di una versione precedente.
Se il cluster è interessato, il log bmctl restore cluster contiene il seguente errore:
Error: failed to extract image paths from profile: anthos version VERSION not supported
Soluzione:
Fino a quando il problema non sarà risolto, ti consigliamo di seguire le istruzioni in Backup e ripristino dei cluster per eseguirne manualmente il backup e, se necessario, ripristinarli.
Networking
1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2
NetworkGatewayGroup si arresta in modo anomalo se non sono presenti indirizzi IP nell'interfaccia
NetworkGatewayGroup non riesce a creare daemon per i nodi che non dispongono di interfacce IPv4 e IPv6. In questo modo si verificano errori in funzionalità come
Bilanciatore del carico BGP e NANA in uscita. Se controlli i log del pod ang-node in errore nello spazio dei nomi kube-system, vengono visualizzati errori simili al seguente esempio quando manca un indirizzo IPv6:
ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}
Nell'esempio precedente, non è presente alcun indirizzo IPv6 nell'interfaccia di ens192. Gli errori ARP simili vengono visualizzati se nel nodo manca un indirizzo IPv4.
NetworkGatewayGroup tenta di stabilire una connessione ARP e una connessione NDP all'indirizzo IP locale del link. Se l'indirizzo IP non esiste (IPv4 per ARP, IPv6 per NDP), la connessione non riesce e il daemon non continua.
Questo problema è stato risolto nella versione 1.14.3.
Soluzione:
Connettiti al nodo tramite SSH e aggiungi un indirizzo IPv4 o IPv6 al link che contiene l'IP del nodo. Nell'esempio di voce di log precedente, questa interfaccia era ens192:
ip address add dev INTERFACE scope link ADDRESS
Sostituisci quanto segue:
INTERFACE: l'interfaccia del tuo nodo, ad esempio ens192.
ADDRESS: indirizzo IP e subnet mask da applicare all'interfaccia.
Reimposta/Elimina
1.10, 1.11, 1.12, 1.13.0-1.13.2
anthos-cluster-operator loop di arresto anomalo durante la rimozione di un nodo del piano di controllo
Quando provi a rimuovere un nodo del piano di controllo rimuovendo l'indirizzo IP da Cluster.Spec, anthos-cluster-operator
entra in uno stato di loop di arresto anomalo che blocca tutte le altre operazioni.
Soluzione:
Il problema è stato risolto nelle versioni 1.13.3 e 1.14.0 e successive. Sono interessate tutte le altre versioni. Esegui l'upgrade a una delle versioni fisse.
IP_ADDRESS: l'indirizzo IP del nodo in stato di loop di arresto anomalo.
CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.
Installazione
1.13.1, 1.13.2 e 1.13.3
kubeadm join non riesce in cluster di grandi dimensioni a causa di una mancata corrispondenza del token
Quando installi Anthos clusters on 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:
Questo problema è stato risolto nei Anthos clusters on bare metal versione 1.13.4 e successive.
Se devi utilizzare una versione interessata, per prima cosa crea un cluster con meno di 20 nodi, quindi ridimensiona il cluster per 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 Anthos su cluster Edge bare metal, i limiti di CPU bassi per
metrics-server possono causare frequenti riavvii di
metrics-server. La scalabilità automatica pod orizzontale (HPA) non funziona
perché metrics-server è in stato non integro.
Se il limite di CPU di metrics-server è inferiore a 40m, i cluster potrebbero risentirne. Per controllare i limiti di CPU di metrics-server, controlla uno dei seguenti file:
Questo problema è stato risolto in Anthos clusters on 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 potrai eseguire l'upgrade dei cluster è aumentare manualmente i limiti di CPU per metrics-server come segue:
Rimuovi la riga --config-dir=/etc/config e aumenta i limiti di CPU, come mostrato nell'esempio seguente:
[...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- # Remove this line - --container=metrics-server - --cpu=50m><--- CPU,
[...] Increase 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
La connessione diretta NodePort 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 riguarda i servizi LoadBalancer se utilizzati con pod hostNetworked. Con più backend, può verificarsi un errore di connessione
sporadico.
Questo problema è causato da un bug nel programma eBPF.
Soluzione:
Quando utilizzi un servizio Nodeport, non scegliere come target il nodo su cui viene eseguito il pod di backend. Quando utilizzi il servizio LoadBalancer, assicurati che i pod hostNetworked non vengano eseguiti sui nodi LoadBalancer.
Upgrade e aggiornamenti
1.12.3, 1.13.0
I cluster di amministrazione 1.13.0 non possono gestire i cluster utente 1.12.3
I cluster di amministrazione che eseguono la versione 1.13.0 non possono gestire i cluster utente che eseguono la versione 1.12.3. Le operazioni su un cluster utente versione 1.12.3 non vanno a buon fine.
Soluzione:
Esegui l'upgrade del cluster di amministrazione alla versione 1.13.1 o esegui l'upgrade del cluster utente alla stessa versione del cluster di amministrazione.
Upgrade e aggiornamenti
1,12
L'upgrade a 1.13.x è bloccato per i cluster di amministrazione con pool di nodi worker
I cluster di amministrazione versione 1.13.0 e successive non possono contenere pool di nodi worker.
L'upgrade alla versione 1.13.0 o successiva per i cluster di amministrazione con pool di nodi worker è bloccato. Se l'upgrade del cluster di amministrazione è bloccato, puoi confermare
che i pool di nodi worker siano la causa controllando il seguente errore nel
file upgrade-cluster.log all'interno della cartella bmctl-workspace:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.
Soluzione:
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
Errori durante l'aggiornamento delle risorse utilizzando kubectl apply
Se aggiorni le 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 desiderate.
Ad esempio, potresti provare a modificare la risorsa personalizzata Stackdriver nel modo seguente recuperando prima la risorsa e poi applicando una versione aggiornata:
Abilitare le funzionalità o aggiornare la configurazione nel file YAML.
Applica di nuovo il file YAML aggiornato:
kubectl apply -f stackdriver.yaml
Il passaggio finale per kubectl apply potrebbe essere
legato a problemi.
Soluzione:
Non utilizzare kubectl apply per apportare modifiche alle risorse esistenti. Utilizza invece kubectl edit o kubectl patch come mostrato nei seguenti esempi:
Pezzi di backlog danneggiati causano stackdriver-log-forwarder
arresti anomali
stackdriver-log-forwarder si arresta in modo anomalo se tenta di elaborare un blocco di backlog danneggiato. Nei log dei container vengono mostrati i seguenti errori di esempio:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
Quando si verifica questo arresto anomalo, non puoi visualizzare i log in Cloud Logging.
Soluzione:
Per risolvere questi errori, completa i seguenti passaggi:
Identifica i blocchi 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/ è in errore. Ogni file *.flb con un controllo di 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 reti non pod
In cluster multi-nic, il riavvio di Dataplane V2 (anetd) può impedire l'associazione delle macchine virtuali alle reti. Nei log dei pod anetd potrebbe essere riscontrato un errore simile al seguente:
could not find an allocator to allocate the IP of the multi-nic endpoint
Soluzione:
Puoi risolvere rapidamente il problema della VM. Per evitare la ricorrenza del problema, esegui l'upgrade ad Anthos clusters on bare metal 1.14.1 o versioni successive.
Operazione
1.13, 1.14.0, 1.14.1
gke-metrics-agent non ha limiti di memoria nei 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 Anthos su cluster di profili perimetrali Bare Metal. I cluster di profilo predefiniti non sono interessati.
Soluzione:
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 della race
Quando crei cluster utilizzando kubectl, a causa delle
condizioni di gara il controllo preflight non può mai terminare. Di conseguenza, in alcuni casi la creazione del cluster
potrebbe non riuscire.
Il riconciliatore dei controlli preflight crea un SecretForwarder per copiare il secret ssh-key predefinito nello spazio dei nomi di destinazione.
In genere, il controllo preflight utilizza il riferimento del proprietario e riconcilia le modifiche una volta completato l'elemento SecretForwarder. Tuttavia, in rari casi, il riferimento proprietario del SecretForwarder potrebbe perdere il riferimento al controllo preflight, provocando il blocco del controllo preflight. Di conseguenza, la creazione del cluster non riesce. Per continuare la riconciliazione per il controllo preflight basato sul controller, elimina il pod cluster di operatori o elimina la risorsa di controllo preliminare. Quando elimini la risorsa di controllo preliminare, ne viene creata una nuova e continua la riconciliazione. In alternativa, puoi eseguire l'upgrade dei tuoi cluster esistenti, creati con una versione precedente, a una versione corretta.
Networking
1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Gli indirizzi IP riservati non vengono rilasciati quando si utilizza il plug-in Ovunque con la funzionalità multi-NIC
Nella funzionalità multi-nic, se utilizzi il plug-in per la ricerca delle informazioni CNI e utilizzi 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 degli indirizzi IP dei pod inutilizzati eseguendo il comando seguente:
kubectl get ippools -A --kubeconfig KUBECONFIG_PATH
Soluzione:
Elimina manualmente gli indirizzi IP (IPpool) non utilizzati.
Installazione
1.10, 1.11.0, 1.11.1, 1.11.2
Rilevatore di problemi dei nodi non riuscito nel cluster utente 1.10.4
Il rilevatore di problemi sui nodi potrebbe non riuscire nei cluster utente Anthos on bare metal 1.10.x, quando Anthos clusters on bare metal 1.11.0, 1.11.1 o 1.11.2 gestiscono i cluster utente 1.10.x. Se il rilevatore di problemi di nodo non funziona, il log viene aggiornato con il seguente messaggio di errore:
Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.
Soluzione
Per risolvere il problema, esegui l'upgrade del cluster di amministrazione alla versione 1.11.3.
Operazione
1,14
I nodi del cluster IPv4 in modalità isola 1.14 hanno una dimensione della maschera CIDR delle pod pari a 24
Nella versione 1.14, l'impostazione maxPodsPerNode non viene presa in considerazione per i cluster in modalità isola, quindi ai nodi viene assegnata una dimensione della maschera CIDR pod di 24 (256 indirizzi IP).Questo potrebbe causare l'esaurimento degli indirizzi IP dei pod prima del previsto. Ad esempio, se il cluster ha una dimensione della maschera CIDR dei pod di 22; a ogni nodo verrà assegnata una maschera CIDR dei pod di 24 e il cluster sarà in grado di supportare solo fino a 4 nodi. Il tuo cluster potrebbe anche riscontrare un'instabilità di rete in un periodo di alto tasso di abbandono dei pod, quando il valore di maxPodsPerNode è impostato su 129 o superiore e non esiste un overhead sufficiente nel CIDR del pod per ciascun nodo.
Se il cluster è interessato, il pod anetd segnala il seguente errore quando aggiungi un nuovo nodo al cluster e non è disponibile alcun elemento podCIDR:
error="required IPv4 PodCIDR not available"
Soluzione
Per risolvere il problema, procedi nel seguente modo:
Esegui l'upgrade alla versione 1.14.1 o a una versione successiva.
Rimuovi i nodi worker e aggiungili di nuovo.
Rimuovi i nodi del piano di controllo e aggiungili di nuovo, preferibilmente uno per uno per evitare tempi di inattività del cluster.
Upgrade e aggiornamenti
1.14.0, 1.14.1
Errore di rollback dell'upgrade del cluster
Un rollback di upgrade potrebbe non riuscire per Anthos clusters on bare metal da 1.14.0 a 1.14.1.
Se esegui l'upgrade di un cluster da 1.14.0 a 1.14.1 e quindi provi a eseguire il rollback a 1.14.0 utilizzando il comando bmctl restore cluster, potrebbe essere restituito un errore come il seguente esempio:
I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable
Soluzione:
Elimina tutte le risorse healthchecks.baremetal.cluster.gke.io
nello 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 healthchecks.baremetal.cluster.gke.io risorse elencate nel passaggio precedente:
Sostituisci HEALTHCHECK_RESOURCE_NAME con il nome delle risorse del controllo di integrità.
Esegui nuovamente il comando bmctl restore cluster.
Networking
1,12,0
L'indirizzo IP esterno del servizio non funziona in modalità semplice
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:
Nel ConfigMap di cilium-config, imposta enable-415 su "true", quindi riavvia i pod anetd.
Upgrade e aggiornamenti
1.13.0, 1.14
Gli upgrade in loco da 1.13.0 a 1.14.x non vengono mai completati
Quando tenti di 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 viene mai completato.
Un errore con l'operatore preflight-check fa sì che il cluster non pianifichi mai i controlli richiesti, il che significa che il controllo preflight non termina mai.
Soluzione:
Esegui l'upgrade alla versione 1.13.1 prima di eseguire l'upgrade alla versione 1.14.x. Un upgrade in loco da 1.13.0 a 1.13.1 dovrebbe funzionare. In alternativa, esegui l'upgrade da 1.13.0 a 1.14.x senza il flag --use-bootstrap=false.
Upgrade e aggiornamenti della sicurezza
1.13 e 1.14
I cluster aggiornati a 1.14.0 perdono le incompatibilità principali
I nodi del piano di controllo richiedono una delle due incompatibilità specifiche per impedire la pianificazione dei pod dei carichi di lavoro. Quando esegui l'upgrade della versione 1.13 dei cluster Anthos alla versione 1.14.0, i nodi del piano di controllo perdono le seguenti incompatibilità obbligatorie:
node-role.kubernetes.io/master:NoSchedule
node-role.kubernetes.io/master:PreferNoSchedule
Questo problema non causa errori di upgrade, ma i pod che non dovrebbero essere eseguiti sui nodi del piano di controllo potrebbero iniziare a farlo. Questi pod del carico di lavoro possono sovraccaricare i nodi del piano di controllo e portare all'instabilità del cluster.
Determinare se un problema ti riguarda
Trova i nodi del piano di controllo, utilizzando il seguente comando:
kubectl get node -l 'node-role.kubernetes.io/control-plane' \
-o name --kubeconfig KUBECONFIG_PATH
Per controllare l'elenco delle incompatibilità su un nodo, usa il seguente comando:
Se nessuna delle incompatibilità richieste è presente nell'elenco, significa che sei interessato.
Soluzione
Per ripristinare la funzione corretta, utilizza i passaggi seguenti per ciascun nodo del piano di controllo del cluster
versione 1.14.0 interessato. Questi passaggi sono per l'incompatibilità di node-role.kubernetes.io/master:NoSchedule e i pod correlati. Se vuoi che i nodi del piano di controllo utilizzino l'incompatibilità PreferNoSchedule, regola i passaggi di conseguenza.
Visualizza i passaggi per la soluzione alternativa
Trova i pod senza 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 non tollerati da
node-role.kubernetes.io/master:NoSchedule:
kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
Operazione, Anthos VM Runtime
1.11, 1.12, 1.13, 1.14, 1.15
Creazione VM non riuscita a causa di errori di caricamento
La creazione di una nuova macchina virtuale (VM) con il comando kubectl virt create vm non riesce raramente durante il caricamento dell'immagine. Questo problema si applica sia alle VM Linux che a quelle Windows. L'errore è simile all'esempio seguente:
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 eseguire il comando kubectl virt create vm per creare la tua VM.
Upgrade e aggiornamenti, Logging e monitoraggio
1.11
I componenti della raccolta gestita nei cluster 1.11 non vengono conservati negli upgrade alla versione 1.12
I componenti della raccolta gestita fanno parte di Managed Service per Prometheus.
Se hai eseguito il deployment manuale dei componenti di raccolta gestita nello spazio dei nomi gmp-system dei tuoi cluster Anthos versione 1.11, le risorse associate non vengono conservate quando esegui l'upgrade alla versione 1.12.
A partire dalla versione 1.12.0 di Anthos clusters on bare metal, 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. Il campo enableGMPForApplications viene impostato automaticamente su true, quindi se esegui manualmente il deployment dei componenti Managed Service per Prometheus nello spazio dei nomi prima dell'upgrade alla versione 1.12, le risorse vengono eliminate da stackdriver-operator.
Soluzione
Per conservare le risorse di raccolta gestite manualmente:
Esegui il backup di tutte le risorse personalizzate di PodMonitoring esistenti.
Esegui di nuovo il deployment delle risorse personalizzate di PodMonitoring sul tuo cluster aggiornato.
Upgrade e aggiornamenti
1,13
Non è possibile eseguire l'upgrade di alcuni cluster della versione 1.12 con il runtime del container Docker alla versione 1.13
Se in un cluster della 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 ti riguarda, bmctl scrive il seguente errore nel file upgrade-cluster.log all'interno della cartella bmctl-workspace:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.
Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.
Molto probabilmente questo avviene con i cluster Docker alla versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11, in quanto quest'ultimo non richiede l'annotazione per mantenere il runtime del container Docker. In questo caso, i cluster non hanno l'annotazione durante l'upgrade alla versione 1.13. Tieni presente che a partire dalla versione 1.13, containerd è l'unico runtime del container consentito.
Soluzione:
Se questo problema ti riguarda, aggiorna la risorsa del cluster con
l'annotazione mancante. Puoi aggiungere l'annotazione mentre è in esecuzione
o dopo l'annullamento e prima di riprovare.
Installazione
1.11
bmctl esci prima del completamento della creazione del cluster
La creazione del cluster potrebbe non riuscire per Anthos clusters on bare metal versione 1.11.0 (questo problema è stato risolto in Anthos clusters on bare metal release 1.11.1). In alcuni casi, il comando bmctl create cluster esce presto e scrive errori come il seguente 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 il problema ti riguarda, segui questi passaggi per ripulire gli artefatti e creare un cluster:
Visualizza i passaggi per la soluzione alternativa
Per eliminare gli artefatti del cluster e reimpostare la macchina nodo, esegui questo comando:
bmctl reset -c USER_CLUSTER_NAME
Per avviare l'operazione di creazione del cluster, esegui questo comando:
Il flag --keep-bootstrap-cluster è importante se questo comando non va a buon fine.
Se il comando di creazione del cluster ha esito positivo, puoi saltare i passaggi successivi. In caso contrario, continua.
Esegui questo comando per ottenere la versione per il cluster bootstrap:
Questo errore è innocuo e puoi ignorarlo in tutta sicurezza.
Installazione
1.10, 1.11, 1.12
Creazione del cluster non riuscita quando si utilizzano più NIC, containerd e proxy HTTPS
La creazione del cluster non riesce quando si ha 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, impostazione predefinita
per Anthos clusters on bare metal versione 1.11).
Il cluster è configurato per fornire più interfacce di rete
multi-NIC per i pod (clusterNetwork.multipleNetworkInterfaces
impostato su true nel file di configurazione del cluster).
Il cluster è configurato per utilizzare un proxy (spec.proxy.url è specificato nel file di configurazione del cluster). Anche se la creazione del cluster non va a buon fine, l'impostazione viene propagata quando si tenta di creare un cluster. Potresti vedere 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 nei sistemi con l'impostazione umask
restrittiva
La versione 1.10.0 di Anthos clusters on bare metal ha introdotto una funzionalità del piano di controllo rootless che esegue tutti i componenti del piano di controllo come utente non root. L'esecuzione di tutti i componenti come utente non root potrebbe causare errori di installazione o upgrade sui sistemi con un'impostazione 0077 più restrittiva di umask.
Soluzione
Reimposta i nodi del piano di controllo e cambia l'impostazione di umask in 0022 su tutte le macchine del piano di controllo. Dopo aver aggiornato le macchine, riprova a eseguire l'installazione.
In alternativa, puoi modificare le autorizzazioni della directory e dei file di /etc/kubernetes sui computer del piano di controllo per l'installazione o l'upgrade.
Rendi leggibili /etc/kubernetes e tutte le sue sottodirectory: chmod o+rx.
Rendere tutti i file di proprietà di root sotto la directory (ricorrenziale) /etc/kubernetes globali (chmod o+r). Escludi i file della chiave privata (.key) da queste modifiche perché sono già stati creati con proprietà e autorizzazioni corrette.
Rendi il mondo di /usr/local/etc/haproxy/haproxy.cfg leggibile.
Rendi /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml
il mondo leggibile.
Installazione
1.10, 1.11, 1.12, 1.13
Incompatibilità gruppo di controllo v2
Il
gruppo di controllo v2 (cgroup v2) non è supportato nelle versioni 1.13 e precedenti di Anthos clusters on 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 tuo sistema utilizza cgroup v2, esegui l'upgrade alla versione 1.14 di Anthos clusters on bare metal.
Installazione
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Controlli preflight e credenziali dell'account di servizio
Per le installazioni attivate da cluster di amministrazione o ibridi (in altre parole, cluster non creati con bmctl, come i cluster utente), il controllo preliminare non verifica le credenziali dell'account di servizio Google Cloud o le relative autorizzazioni.
Affinché l'ADC funzioni, devi puntare la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS a un file delle credenziali dell'account di servizio oppure eseguire gcloud auth application-default login.
Installazione
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Servizio Docker
Sulle macchine dei nodi del cluster, se l'eseguibile Docker è presente nella variabile di ambiente PATH, ma il servizio Docker non è attivo, il controllo preflight non andrà a buon fine e segnalerà Docker service
is not active.
Soluzione
Rimuovi Docker o abilita il servizio Docker.
Installazione
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Installazione su vSphere
Quando installi Anthos clusters on bare metal sulle VM vSphere, devi impostare i flag tx-udp_tnl-segmentation e tx-udp_tnl-csum-segmentation su Off. Questi flag sono correlati all'offload della segmentazione hardware eseguito dal driver vSphere VMXNET3 e non funzionano con il tunnel GENEVE dei Anthos clusters on bare metal.
Soluzione
Esegui questo comando su ciascun nodo per verificare i valori attuali per
i flag:
ethtool -k NET_INTFC | grep segm
Sostituisci NET_INTFC con l'interfaccia di rete associata all'indirizzo IP del nodo.
La risposta deve contenere voci come le seguenti:
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
In alcuni casi in RHEL 8.4, ethtool indica che le segnalazioni sono disattivate
mentre non lo sono. Per impostare esplicitamente questi flag su Off, attivali e disattivali tramite 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 al flag non viene preservata durante i riavvii. Configura gli script di avvio per impostare esplicitamente questi flag all'avvio del sistema.
Upgrade e aggiornamenti
1,1
bmctl non può creare, aggiornare o reimpostare i cluster utente con versione inferiore
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 della versione 1.N-1.Y, anche se il cluster di amministrazione è anche alla versione 1.N.X.
Se riscontri questo problema, dovresti visualizzare i log simili a quanto segue quando utilizzi bmctl:
[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:
* cluster version 1.8.1 is not supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported
Soluzione:
Utilizza kubectl per creare, modificare o eliminare la risorsa personalizzata del cluster utente all'interno del cluster di amministrazione.
La possibilità di eseguire l'upgrade dei cluster utente non è interessata.
Upgrade e aggiornamenti
1,12
Gli upgrade dei cluster alla versione 1.12.1 possono bloccare
L'upgrade dei cluster alla versione 1.12.1 a volte viene eseguito in quanto il server API non è più disponibile. Questo problema riguarda tutti i tipi di cluster e tutti i sistemi operativi supportati. Quando si verifica questo problema, il comando bmctl
upgrade cluster può non riuscire in più punti, anche durante la seconda fase dei controlli preflight.
Soluzione
Puoi controllare i log di upgrade per determinare se hai riscontrato questo problema. I log di upgrade si trovano in
/baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP per impostazione predefinita.
upgrade-cluster.log potrebbe contenere errori come i seguenti:
Failed to upgrade cluster: preflight checks failed: preflight check failed
Il log del computer potrebbe contenere errori come i seguenti (gli errori ripetuti indicano che il problema è interessato):
HAProxy e Keepalive devono essere in esecuzione su ciascun nodo del piano di controllo prima di riprovare a 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 Keepalive non è in esecuzione su un nodo, riavvia kubelet sul nodo:
systemctl restart kubelet
Upgrade e aggiornamenti, Anthos VM Runtime
1.11, 1.12
L'upgrade dei cluster alla versione 1.12.0 o successiva non riesce quando è abilitato Anthos VM Runtime
Nei Anthos clusters on bare metal versione 1.12.0, tutte le risorse relative ad Anthos VM Runtime vengono migrate allo spazio dei nomi vm-system per supportare meglio la release GA di Anthos VM Runtime. Se hai abilitato Anthos VM Runtime in un cluster 1.11.x o versioni precedenti, l'upgrade alla versione 1.12.0 o successiva non riesce se non disattivi prima Anthos VM Runtime. Se si verifica questo problema, l'operazione di upgrade segnala il seguente errore:
Failed to upgrade cluster: cluster is not 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 alle ore error during manifests operations
In alcune situazioni, gli upgrade dei 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 hai riscontrato questo problema e per correggerlo, controlla i log di anthos-cluster-operator e cerca errori simili alle seguenti voci:
controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
Queste voci sono un sintomo di una risorsa aggiornata in modo errato, dove
{RESOURCE_NAME} è il nome della risorsa problematica.
Soluzione
Se trovi 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 Anthos Network Gateway
Gli upgrade dei cluster da 1.10.x a 1.11.x non vanno a buon fine per i cluster che utilizzano il gateway NAT in uscita o il bilanciamento del carico in bundle con BGP. Entrambe le funzionalità utilizzano Anthos Network Gateway. Gli upgrade dei cluster si bloccano al messaggio della riga di comando Waiting for upgrade to complete... e gli errori dei log anthos-cluster-operator, come riportato di seguito:
apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...
Soluzione
Per sbloccare l'upgrade, esegui questi comandi sul cluster che stai eseguendo:
bmctl update non rimuove i blocchi di manutenzione
Il comando bmctl update non può rimuovere o modificare la sezione maintenanceBlocks dalla configurazione delle risorse del cluster.
Soluzione
Per ulteriori informazioni, incluse le istruzioni per la rimozione dei nodi dalla modalità di manutenzione, consulta la sezione Mettere i nodi in modalità di manutenzione.
Upgrade e aggiornamenti
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Lo svuotamento del nodo non può iniziare quando il nodo non è raggiungibile
Il processo di svuotamento dei nodi non si avvia se il nodo è fuori dalla portata dei Anthos clusters on bare metal. Ad esempio, se un nodo passa alla modalità offline durante un processo di upgrade del cluster, l'upgrade potrebbe smettere di rispondere. Si tratta di un'eventualità rara.
Soluzione
Per ridurre al minimo la probabilità che si verifichi questo problema, assicurati che i nodi funzionino correttamente prima di avviare un upgrade.
Upgrade e aggiornamenti
1,12
containerd 1.5.13 richiede libseccomp 2.5 o versioni successive
La versione 1.12.1 di Anthos clusters on bare metal viene fornita con
containerd versione 1.5.13 e questa versione di
containerd richiede libseccomp 2.5 o versioni successive.
Se nel tuo sistema non è installata la versione 2.5 o successive di libseccomp, esegui l'aggiornamento prima dell'upgrade dei cluster esistenti alla versione 1.12.1. In caso contrario, potresti visualizzare errori nei pod cplb-update per i nodi del bilanciatore del carico, come i seguenti:
runc did not terminate successfully: runc: symbol lookup error: runc: undefined
symbol: seccomp_notify_respond
Soluzione
Per installare la versione più recente di libseccomp in Ubuntu, esegui questo comando:
sudo apt-get install libseccomp-dev
Per installare la versione più recente di libseccomp in CentOS o RHEL, esegui il comando seguente:
sudo dnf -y install libseccomp-devel
Operazione
1.10, 1.11, 1.12
I nodi sono inaccessibili se non utilizzi la procedura della modalità di manutenzione
Se esegui Anthos clusters on bare metal versione 1.12.0 (anthosBareMetalVersion: 1.12.0) o versioni precedenti e utilizzi manualmente kubectl cordon su un nodo, Anthos clusters on bare metal potrebbe annullare l'esecuzione del nodo prima che sia tutto pronto per riconciliare lo stato previsto.
Soluzione
Per Anthos clusters on bare metal versione 1.12.0 e precedenti, utilizza la modalità di manutenzione per cordonare e svuotare i nodi in sicurezza.
Nella versione 1.12.1 (anthosBareMetalVersion: 1.12.1) o successive, i Anthos clusters on bare metal non sostituiscono i nodi in modo imprevisto quando utilizzi kubectl cordon.
Operazione
1.11
I cluster di amministrazione versione 11 che utilizzano un mirror del registry non possono gestire i cluster della versione 1.10
Se il tuo cluster di amministrazione utilizza la versione 1.11 e utilizza un mirror del Registro di sistema, non è possibile gestire i cluster utente che utilizzano una versione secondaria inferiore. Questo problema influisce sulle operazioni di reimpostazione, aggiornamento e upgrade sul cluster utente.
Per determinare se questo problema ti riguarda, controlla i log per le operazioni del cluster, come la creazione, l'upgrade o il ripristino. 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
Secret kubeconfig sovrascritto
Quando viene eseguito sui cluster utente, il comando bmctl check cluster sovrascrive il cluster utente kubeconfig Secret con il cluster di amministrazione kubeconfig. La sovrascrittura del file causa errori nelle operazioni standard del cluster, come l'aggiornamento e l'upgrade, per i cluster utente interessati. Questo problema si applica ai Anthos clusters on bare metal versioni 1.11.1 e precedenti.
Per determinare se questo problema riguarda un cluster utente, esegui questo comando:
ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
USER_CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi dei cluster Anthos clusters on bare metal sono i nomi dei cluster preceduti da cluster-. Ad esempio, se assegni al tuo cluster il nome test, lo spazio dei nomi predefinito è cluster-test.
USER_CLUSTER_NAME: il nome del cluster utente da controllare.
Se il nome del cluster nell'output (vedi
contexts.context.cluster nell'output di esempio seguente) è
il nome del cluster di amministrazione, è interessato il cluster utente specificato.
I seguenti passaggi ripristinano la funzione in un cluster utente interessato
(USER_CLUSTER_NAME):
Individua il file kubeconfig del cluster utente. Anthos clusters on bare metal
genera il file kubeconfig sulla workstation di amministrazione quando crei un
cluster. Per impostazione predefinita, il file si trova nella directory bmctl-workspace/USER_CLUSTER_NAME.
Verifica che kubeconfig sia il cluster utente corretto 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. Conferma che i nomi delle macchine sono corretti per il cluster.
Esegui il comando seguente per eliminare il file kubeconfig danneggiato nel cluster di amministrazione:
Acquisizione 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 PATH dell'utente.
In caso contrario, l'operazione non riuscirà e verrà restituito un errore crictl: command not found.
Se non hai eseguito l'accesso come utente root, sudo viene utilizzato per eseguire i comandi degli snapshot. Il PATH di sudo può essere diverso dal profilo root e non può contenere /usr/local/bin.
Soluzione
Aggiorna secure_path in /etc/sudoers in modo che includa /usr/local/bin. In alternativa, crea un link simbolico
per crictl in un'altra directory /bin.
Operazione, Anthos VM Runtime
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Anthos VM Runtime - Il riavvio di un pod fa sì che le VM nel pod
modifichino gli indirizzi IP o perdano del tutto il proprio indirizzo IP.
Se l'indirizzo IP di una VM cambia, questo non influisce sulla connettività delle applicazioni VM esposte come servizio Kubernetes.
Soluzione
Se perdi l'indirizzo IP, devi eseguire dhclient dalla
VM per acquisire un indirizzo IP per la VM.
Logging e monitoraggio
1,1
stackdriver-log-forwarder ha [parser:cri] invalid
time format log di avviso
Se l'analizzatore sintattico di runtime del container (CRI) utilizza un'espressione regolare errata per l'analisi del tempo, i log per il pod stackdriver-log-forwarder contengono errori e avvisi come riportato di seguito:
[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'
Soluzione:
Visualizza i passaggi per la soluzione alternativa
Esegui l'upgrade di Anthos clusters on bare metal alla versione 1.11.0 o successiva.
Se non riesci a eseguire l'upgrade dei tuoi cluster immediatamente, segui questi passaggi per aggiornare l'espressione regolare dell'analisi CRI:
Per evitare che le seguenti modifiche vengano annullate, 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
Riavvia i pod dello strumento di forwarding dei log:
Per i cluster Anthos sulle versioni bare metal 1.10 e successive, alcuni clienti hanno riscontrato una fatturazione inaspettatamente elevata per Metrics volume nella pagina Fatturazione. Questo problema riguarda solo le seguenti circostanze:
I pod dell'applicazione hanno l'annotazione prometheus.io/scrap=true
Per verificare se hai riscontrato questo problema, elenca le metriche definite dall'utente. Se visualizzi la fatturazione per le metriche indesiderate, questo problema si applica a te.
Soluzione
Se hai riscontrato questo problema, ti consigliamo di eseguire l'upgrade dei tuoi cluster alla versione 1.12 e di passare alla nuova soluzione per il monitoraggio delle applicazioni managed-service-for-prometheus che consenta di risolvere il problema:
Flag separati per controllare la raccolta di log delle applicazioni rispetto alle metriche delle applicazioni
Google Cloud Managed Service per Prometheus in bundle
Se non riesci a eseguire l'upgrade alla versione 1.12, procedi nel seguente modo:
Individua i pod e i servizi di origine provvisti di 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 servizio.
Logging e monitoraggio
1.11, 1.12, 1.13, 1.14, 1.15
Le modifiche a metrics-server-config non vengono mantenute
Un'elevata densità di pod può, in casi estremi, causare un overhead per il logging e il monitoraggio, che può causare l'arresto e il riavvio di Metrics Server. Puoi
modificare il ConfigMap di metrics-server-config per allocare
più risorse per mantenere in esecuzione Metrics Server. Tuttavia, a causa della riconciliazione,
le modifiche apportate a metrics-server-config possono
essere ripristinate al valore predefinito durante un'operazione di aggiornamento o upgrade del cluster.
Metrics Server non è interessato immediatamente, ma al successivo riavvio riprende il ConfigMap ripristinato ed è vulnerabile di nuovo a un overhead eccessivo.
Soluzione
Per 1.11.x, puoi creare uno script alla modifica del ConfigMap ed eseguirlo insieme ad aggiornamenti o upgrade al cluster. Per l'assistenza dalla 1.12 in poi, contatta l'assistenza.
Logging e monitoraggio
1.11, 1.12
Le metriche deprecate influiscono sulla dashboard di Cloud Monitoring
Diverse metriche Anthos sono state deprecate e, a partire dalla versione 1.11 di Anthos clusters on bare metal, non sono più raccolti dati per queste metriche deprecate. Se utilizzi queste metriche in uno qualsiasi dei criteri di avviso, non ci saranno dati per attivare la condizione di avviso.
La seguente tabella elenca le singole metriche che sono state ritirate e la metrica che le sostituisce.
Nei cluster Anthos su release 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 di node-cpu-usage-high.json è stato aggiornato
per le versioni 1.11.0 e successive.
Soluzione
Per eseguire la migrazione alle metriche di sostituzione:
Nella console Google Cloud, seleziona Monitoring o fai clic sul seguente pulsante: Vai a Monitoring
Nel riquadro di navigazione, seleziona Dashboard ed elimina la dashboard dello stato dei nodi del cluster Anthos.
Fai clic sulla scheda Libreria di esempio e reinstalla la dashboard dello stato dei nodi del cluster Anthos.
stackdriver-log-forwarder ha CrashloopBackOff
errori
In alcune situazioni, l'agente Logging fluent-bit può bloccare blocchi di elaborazione danneggiati. Quando l'agente Logging non è in grado di aggirare i blocchi danneggiati, potresti notare che stackdriver-log-forwarder continua ad arrestarsi in modo anomalo con un errore CrashloopBackOff. Se riscontri questo problema, i log contengono voci come le seguenti
[2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0 0x5590aa24bdd5
in validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1 0x5590aa24c502 in stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2 0x5590aa24e509 in cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3 0x5590aa19c0de in output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4 0x5590aa6889a6 in co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5 0xffffffffffffffff in ???() at ???:0
Soluzione:
Pulisci i blocchi di buffer per lo strumento di inoltro di Stackdriver.
Nota: nei comandi seguenti, sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.
Sebbene queste metriche del tipo di riepilogo siano nell'elenco delle metriche, al momento non sono supportate da gke-metrics-agent.
Logging e monitoraggio
1.10, 1.11
Interruzioni dell'esportazione delle metriche intermittenti
Anthos clusters on bare metal potrebbero riscontrare interruzioni nella normale esportazione continua delle metriche o metriche mancanti su alcuni nodi. Se questo problema riguarda i tuoi cluster, potresti notare lacune nei dati per le seguenti metriche (come minimo):
Il comando trova cpu: 50m se le modifiche sono state
applicate.
Networking
1,1
Più gateway predefiniti interrompono la connettività agli endpoint esterni
Avere più gateway predefiniti in un nodo può causare un'interruzione della connettività dall'interno di un pod a endpoint esterni, come google.com.
Per determinare se hai riscontrato questo problema, esegui il comando seguente sul nodo:
ip route show
Più istanze di default nella risposta indicano che ti riguarda.
Networking
1,12
Le modifiche alle risorse di rete personalizzate sui cluster utente vengono sovrascritte
La versione 1.12.x di Anthos clusters on bare metal non ti impedisce di modificare manualmente le risorse personalizzate di networking nel tuo cluster utente. Anthos clusters on bare metal riconcilia le risorse personalizzate nei cluster utente con le risorse personalizzate nel tuo 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 Anthos clusters on bare metal versione 1.12.x non applica questo requisito.
Puoi modificare 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 precedentemente menzionate in 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 mantenute. Anthos clusters on bare metal versioni 1.13.0 e successive impediscono la modifica diretta delle risorse personalizzate di networking sui cluster utente.
Networking
1.11, 1.12, 1.13, 1.14, 1.15
Errore NAT con troppe connessioni parallele
Per un determinato nodo nel tuo cluster, l'indirizzo IP del nodo fornisce la traduzione dell'indirizzo di rete (NAT) per i pacchetti instradati a un indirizzo esterno al cluster. Analogamente, quando i pacchetti in entrata entrano in un nodo di bilanciamento del carico configurato per l'utilizzo del bilanciamento del carico in bundle (spec.loadBalancer.mode:
bundled), Network Address Translation (SNAT) di origine instrada i pacchetti all'indirizzo IP del nodo prima di essere inoltrati a un pod di backend.
L'intervallo di porte per NAT utilizzato dai Anthos clusters on bare metal è compreso tra 32768 e 65535. Questo intervallo limita il numero di connessioni in contemporanea a 32.767 per protocollo su quel nodo. Ogni connessione deve avere una voce nella tabella di monitoraggio. Se hai troppe connessioni di breve durata, la tabella di connessione esaurisce le porte per NAT. Un raccoglitore di rifiuti pulisce le voci inattive, ma la pulizia non è immediata.
Quando il numero di connessioni sul tuo nodo si avvicina a 32,767, inizierai a vedere i cali dei pacchetti per le connessioni che richiedono NAT.
Puoi identificare questo problema eseguendo il comando seguente sul pod anetd sul nodo problematico:
Dovresti visualizzare gli errori del seguente modulo:
No mapping for NAT masquerade DROPPED
Soluzione
Ridistribuisci il traffico ad altri nodi.
Networking
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
IP di origine client con bilanciamento del carico di livello 2 in bundle
L'impostazione del
criterio del traffico esterno
su Local può causare errori di routing, come No route to
host per il bilanciamento del carico di livello 2 in bundle. Il criterio del traffico esterno è impostato su Cluster (externalTrafficPolicy:
Cluster) per impostazione predefinita. Con questa impostazione, Kubernetes gestisce il traffico a livello di cluster. I servizi di tipo LoadBalancer o
NodePort possono utilizzare externalTrafficPolicy: Local per
conservare l'indirizzo IP di origine del client. Con questa impostazione, tuttavia, Kubernetes gestisce solo il traffico locale dei nodi.
Soluzione
Se vuoi conservare l'indirizzo IP di origine del client, potrebbe essere necessaria una configurazione aggiuntiva per garantire che gli IP dei servizi siano raggiungibili. Per i dettagli della configurazione, consulta Preservazione dell'indirizzo IP di origine del client in Configura il bilanciamento del carico in bundle.
Networking
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
La modifica di firewalld comporterà la cancellazione delle catene di criteri utilizzabili di Cilium
Quando esegui Anthos clusters on bare metal con firewalld abilitato su CentOS o Red Had Enterprise Linux (RHEL), le modifiche a firewalld possono rimuovere le catene Cilium iptables sulla rete host. Le catene iptables vengono aggiunte dal pod anetd all'avvio. La perdita delle catene Cilium
iptables fa sì che il pod sul nodo perda la connettività
di rete all'esterno del nodo.
Le modifiche a firewalld che rimuoveranno
le catene di iptables includono, a titolo esemplificativo:
Riavvio di firewalld in corso, utilizzando systemctl
Ricaricamento di firewalld con il client a riga di comando
(firewall-cmd --reload)
Soluzione
Riavvia anetd sul nodo. Individua ed elimina il pod anetd con i comandi seguenti per riavviare anetd:
Quando utilizzi l'anteprima della funzionalità del
gateway NAT in uscita, puoi impostare le regole di selezione del traffico che specificano un indirizzo
egressSourceIP già in uso per un altro
oggetto EgressNATPolicy. Ciò potrebbe causare conflitti di routing del traffico in uscita.
Soluzione
Collabora con il tuo team di sviluppo per determinare quali indirizzi IP mobili sono disponibili prima di specificare l'indirizzo egressSourceIP nella risorsa personalizzata EgressNATPolicy.
Networking
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Errori di connettività dei pod e filtro del percorso inverso
Anthos clusters on 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 delle comunicazioni fuori nodo.
I filtri del percorso inverso sono impostati con file rp_filter nella cartella di configurazione IPv4 (net/ipv4/conf/all). Questo valore può anche essere sostituito da sysctl, che archivia le impostazioni del filtro del percorso inverso in un file di configurazione della sicurezza di rete, come /etc/sysctl.d/60-gce-network-security.conf.
Soluzione
Per ripristinare la connettività dei pod, imposta di nuovo net.ipv4.conf.all.rp_filter su 0 manualmente o riavvia il anetd pod per impostare di nuovo net.ipv4.conf.all.rp_filter su 0. Per riavviare il pod anetd, utilizza i comandi seguenti per individuare ed eliminare il pod anetd e al suo posto verrà avviato un nuovo pod anetd:
Indirizzi IP del cluster di avvio (tipo) e indirizzi IP del nodo del cluster che si sovrappongono
192.168.122.0/24 e 10.96.0.0/27 sono i CIDR dei pod e dei servizi predefiniti utilizzati dal cluster bootstrap (tipo).
I controlli preflight non andranno a buon fine se si sovrappongono a indirizzi IP di macchine del nodo del cluster.
Soluzione
Per evitare conflitti, puoi passare i flag
--bootstrap-cluster-pod-cidr e
--bootstrap-cluster-service-cidr a bmctl
per specificare valori diversi.
Sistema operativo
1.11
Incompatibilità con Ubuntu 18.04.6 sul kernel GA
Anthos clusters on bare metal versioni 1.11.0 e 1.11.1 non sono compatibili con Ubuntu 18.04.6 sul kernel GA (da 4.15.0-144-generic a 4.15.0-176-generic). L'incompatibilità fa sì che l'agente di networking non sia in grado di configurare la rete del cluster con un errore "Il programma BPF è troppo grande" nei log di anetd. Potresti
notare pod bloccati nello stato ContainerCreating con
un errore networkPlugin cni failed to set up pod nel log eventi dei pod. Questo problema non riguarda i kernel HWE (Ubuntu Hardware Enablement)
Soluzione
Ti consigliamo di ottenere il kernel HWE e di eseguirne l'upgrade all'ultima versione HWE supportata per Ubuntu 18.04.
Sistema operativo
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Creazione o upgrade del cluster non riuscito su CentOS
A dicembre 2020 la community di CentOS e Red Hat hanno annunciato il tramonto di CentOS. Il 31 gennaio 2022, CentOS 8 ha raggiunto la fine del suo ciclo di vita
(EOL). A causa dell'EOL, yum repository hanno smesso di funzionare per CentOS, causando errori nella creazione dei cluster e nelle operazioni di upgrade dei cluster. Si applica a tutte le versioni supportate di CentOS e influisce su tutte le versioni di Anthos clusters on bare metal.
Soluzione
Visualizza i passaggi per la soluzione alternativa
Per risolvere il problema, esegui i comandi seguenti per fare in modo che CentOS utilizzi un feed di archivio:
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
/etc/yum.repos.d/CentOS-Linux-*
Come soluzione a lungo termine, valuta la possibilità di eseguire la migrazione a un altro sistema operativo supportato.
Sistema operativo
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Limitazioni degli endpoint del sistema operativo
Su RHEL e CentOS, esiste un limite a livello di cluster di 100.000 endpoint. Servizio Kubernetes. Se 2 servizi fanno riferimento allo stesso insieme di pod, vengono conteggiati come 2 insiemi separati di endpoint. L'implementazione
nftable sottostante su RHEL e CentOS causa questa limitazione
e non è una limitazione intrinseca dei Anthos clusters on bare metal.
Sicurezza
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Il container non può scrivere in VOLUME definiti in Dockerfile con containerd e SELinux
Se utilizzi containerd come runtime del container e SELinux è abilitato per il tuo sistema operativo, il VOLUME definito nel
Dockerfile dell'applicazione potrebbe non essere scrivibile. Ad esempio, i container creati con il seguente Dockerfile non sono in grado di scrivere nella cartella /tmp.
FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp
Per verificare se questo problema ti riguarda, esegui il comando seguente
sul nodo che ospita il container problematico:
ausearch -m avc
Se si verifica questo problema, viene visualizzato un errore denied come il seguente:
Per risolvere il problema, apporta una delle seguenti modifiche:
Disattiva SELinux.
Non usare la funzionalità VOLUME all'interno di Dockerfile.
Sicurezza
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Errori SELinux durante la creazione del pod
A volte la creazione dei pod non riesce quando SELinux impedisce al runtime del container di impostare le etichette sui supporti tmpfs. Questo errore è raro, ma può verificarsi quando SELinux è in modalità Enforcing e in alcuni kernel.
Per verificare che SELinux sia la causa di errori di creazione dei pod, utilizza il comando seguente per verificare la presenza di errori nei log di kubelet:
journalctl -u kubelet
Se SELinux non riesce a creare un pod, la risposta di comando contiene un errore simile al seguente:
error setting label on mount source '/var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x': failed to set file label on /var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x: permission denied
Per verificare che questo problema sia correlato all'applicazione di SELinux, esegui il comando seguente
ausearch -m avc
Questo comando ricerca negli audit log gli errori di autorizzazione della cache vettore di accesso (AVC). Il avc: denied nella seguente risposta di esempio conferma che gli errori di creazione dei pod sono correlati all'applicazione di SELinux.
La causa principale di questo problema di creazione dei pod in SELinux è un bug del kernel trovato nelle seguenti immagini Linux:
Release di Red Hat Enterprise Linux (RHEL) precedenti alla 8.3
Rilasci CentOS precedenti alla 8.3
Soluzione
Il riavvio del computer consente di ripristinare il problema.
Per evitare errori di creazione di pod, utilizza RHEL 8.3 o versioni successive oppure CentOS 8.3 o versioni successive, perché tali versioni hanno corretto il bug del kernel.
Reimposta/Elimina
1.10, 1.11, 1.12
Eliminazione dello spazio dei nomi
L'eliminazione di uno spazio dei nomi impedirà la creazione di nuove risorse al suo interno, inclusi i job per reimpostare le macchine.
Soluzione
Quando elimini un cluster utente, devi prima eliminare l'oggetto cluster prima di eliminare lo spazio dei nomi. In caso contrario, non è possibile creare i job per reimpostare le macchine e il processo di eliminazione ignorerà il passaggio di pulizia delle macchine.
Reimposta/Elimina
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
servizio containerd
Il comando bmctl reset non elimina alcun file di configurazione o programmi binari containerd. Il servizio containerd systemd è in esecuzione. Il comando elimina i container che eseguono i pod pianificati per il nodo.
Upgrade e aggiornamenti
1.10, 1.11, 1.12
Il Rilevatore di problemi dei nodi non è abilitato per impostazione predefinita dopo gli upgrade dei cluster
Quando esegui l'upgrade Anthos clusters on bare metal, il Rilevatore di problemi dei nodi non è abilitato per impostazione predefinita. Questo problema è applicabile agli upgrade dalle versioni 1.10 alla 1.12.1 ed è stato risolto nella versione 1.12.2.
Soluzione:
Per abilitare il Rilevatore di problemi dei nodi:
Verifica se il servizio node-problem-detector systemd è in esecuzione sul nodo.
Usa il comando SSH e connettiti al nodo.
Verifica se il servizio node-problem-detector systemd è in esecuzione sul nodo:
systemctl is-active node-problem-detector
Se nel risultato del comando viene visualizzato inactive, il nodo-problem-detector non è in esecuzione sul nodo.
Per abilitare il Rilevatore di problemi dei nodi, utilizza il comando
kubectl edit e modifica il
ConfigMap di node-problem-detector-config. Per ulteriori
informazioni, consulta la pagina
Rilevamento
dei problemi dei nodi.
Operazione
1.9, 1.10
Il backup del cluster non riesce quando si utilizza un accesso non root
Il comando bmctl backup cluster non riesce se
nodeAccess.loginUser è impostato su un nome utente non root.]
Soluzione:
Questo problema si applica ai Anthos clusters on bare metal 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 del bilanciatore del carico non funzionano con i container sulla rete host del piano di controllo
A anetd è presente un bug per cui i pacchetti vengono ignorati per i servizi LoadBalancer se i pod di backend sono 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:
Le seguenti soluzioni alternative possono essere utili se utilizzi un servizio LoadBalancer supportato da pod hostNetwork:
Eseguili sui nodi worker (non sui nodi del piano di controllo).
Pod anphos-version-$version$ che non riesce a eseguire il pull dell'immagine
L'upgrade del cluster da 1.12.x a 1.13.x potrebbe notare un pod anthos-version-$version$ in errore con errore ImagePullBackOff.
Ciò si verifica a causa dell'upgrade della race condition di anthos-cluster-operator e non dovrebbe influire sulla normale funzionalità del cluster.
Il bug non è presente dopo la versione 1.13 o successive.
Soluzione:
Elimina il job del programma di installazione di versione dinamica entro il giorno kubectl delete job anthos-version-$version$ -n kube-system
Upgrade e aggiornamenti
1,13
L'upgrade dei cluster 1.12 dalla versione 1.11 non può essere eseguito alla versione 1.13.0
Non è possibile eseguire l'upgrade dei cluster della versione 1.12 dalla versione 1.11 alla versione 1.13.0. Questo problema di upgrade non si applica ai cluster creati alla versione 1.12.
Per determinare se ti riguarda, controlla i log del job di upgrade che contiene la stringa upgrade-first-no* nel cluster di amministrazione.
Se ricevi il seguente messaggio di errore, significa che ciò ti riguarda.
TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack is not a valid feature name.
...
Soluzione:
Per risolvere questo problema:
Esegui i comandi seguenti sulla tua workstation di amministrazione:
Dashboard ed elimina la dashboard dello stato dei nodi del cluster Anthos.