Seleziona i tuoi cluster Anthos su versione Bare Metal:
Seleziona la categoria del problema:
In alternativa, cerca il problema:
Categoria
Versioni identificate
Problema e soluzione alternativa
Networking
1,12,0
L'indirizzo IP esterno del servizio non funziona in modalità piatta
In un cluster in cui flatIPv4 è impostato su true,
i servizi di tipo LoadBalancer non sono accessibili dai rispettivi
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 finiscono mai
Quando provi a eseguire un upgrade in loco da 1.13.0 a 1.14.x utilizzando bmctl 1.14.0 e il flag --use-bootstrap=false, l'upgrade non termina mai.
Un errore con l'operatore preflight-check fa sì che il cluster non pianifichi mai i controlli richiesti, il che significa che il controllo preflight non termina mai.
Soluzione:
Prima di eseguire l'upgrade a 1.14.x, esegui l'upgrade a 1.13.1. Dovrebbe funzionare un upgrade in loco da 1.13.0 a 1.13.1. In alternativa, esegui l'upgrade da 1.13.0 a 1.14.x senza il flag --use-bootstrap=false.
Upgrade e aggiornamenti, sicurezza
1.13 e 1.14
I cluster aggiornati a 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. Quando esegui l'upgrade della versione 1.14.0 dei cluster Anthos alla versione 1.14.0, i nodi del piano di controllo perderanno le seguenti incompatibilità:
node-role.kubernetes.io/master:NoSchedule
node-role.kubernetes.io/master:PreferNoSchedule
Questo problema non causa errori di upgrade, ma i pod che non devono essere eseguiti sui nodi del piano di controllo possono iniziare a farlo. Questi pod del carico di lavoro possono sovraccaricare i nodi del piano di controllo e portare all'instabilità del cluster.
Determina se il problema ti riguarda
Trova i nodi del piano di controllo, utilizzando il comando seguente:
kubectl get node -l 'node-role.kubernetes.io/control-plane' \
-o name --kubeconfig KUBECONFIG_PATH
Per controllare l'elenco di incompatibilità su un nodo, utilizza il seguente comando:
Se nessuna delle incompatibilità richieste è presente, il problema ti riguarda.
Soluzione
Per ripristinare la funzione corretta, segui i passaggi riportati di seguito per ogni nodo del piano di controllo del cluster nella versione 1.14.0 interessata. Questi passaggi sono relativi all'incompatibilità di node-role.kubernetes.io/master:NoSchedule e ai 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 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, Anthos VM Runtime
1.11, 1.12, 1.13 e 1.14
Creazione di VM non riuscita a intermittenza con 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 riguarda le VM Linux e 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 VM.
Upgrade e aggiornamenti, Logging e Monitoring
1.11
I componenti della raccolta gestita nei cluster 1.11 non vengono conservati negli upgrade a 1.12
I componenti della raccolta gestita fanno parte di Managed Service per Prometheus.
Se hai eseguito manualmente il deployment dei componenti raccolta gestita nello spazio dei nomi gmp-system dei tuoi cluster Anthos versione 1.11, le risorse associate non vengono mantenute quando esegui l'upgrade alla versione 1.12.
A partire dai cluster Anthos su Bare Metal 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. Il campo enableGMPForApplications
ha come valore predefinito true, quindi se esegui manualmente il deployment
dei componenti Managed Service per Prometheus nello spazio dei nomi prima di eseguire l'upgrade
alla versione 1.12, le risorse vengono eliminate da stackdriver-operator.
Soluzione
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 PodMonitoring nel cluster di cui è stato eseguito l'upgrade.
Upgrade e aggiornamenti
1,13
Impossibile eseguire l'upgrade alla versione 1.13 di alcuni cluster con versione 1.12 con il runtime del container Docker
Se a un cluster della versione 1.12 che utilizza il runtime del container Docker manca la seguente annotazione, non può eseguire l'upgrade alla versione 1.13:
Se riscontri 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 probabilmente questo si verifica con i cluster Docker della versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11, in quanto tale upgrade non richiede l'annotazione per mantenere il runtime del container Docker. In questo caso, i cluster non hanno l'annotazione durante l'upgrade alla versione 1.13. Tieni presente che a partire dalla versione 1.13, containerd è l'unico runtime del container consentito.
Soluzione:
Se si verifica questo problema, aggiorna la risorsa cluster con l'annotazione mancante. Puoi aggiungere l'annotazione mentre è in esecuzione o dopo l'annullamento e prima di riprovare.
Installazione
1.11
bmctl uscite prima del completamento della creazione del cluster
La creazione del cluster potrebbe non riuscire per Cluster Anthos on bare metal versione 1.11.0 (questo problema è stato risolto in Cluster Anthos on bare metal release 1.11.1). In alcuni casi, il comando bmctl create cluster esce in anticipo e scrive nei log errori come il seguente:
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 eseguire la pulizia degli artefatti e creare un cluster:
Visualizza i passaggi per la soluzione alternativa
Per eliminare gli artefatti del cluster e reimpostare la macchina nodo, esegui il comando seguente:
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 riesce.
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 bootstrap:
La creazione del cluster non riesce quando si utilizzano più proxy NIC, containerd e 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 i cluster Anthos su Bare Metal versione 1.14).
Il cluster è configurato per fornire più interfacce di rete,
più NIC, per i pod
(clusterNetwork.multipleNetworkInterfaces impostato su
true nel file di configurazione del cluster).
Il cluster è configurato per l'utilizzo di un proxy (spec.proxy.url è specificato nel file di configurazione del cluster). Anche se la creazione del cluster non riesce, questa impostazione viene propagata quando tenti di creare un cluster. Potresti visualizzare questa impostazione proxy come variabile di ambiente HTTPS_PROXY
o nella configurazione containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).
Soluzione
Aggiungi i CIDR dei servizi (clusterNetwork.services.cidrBlocks) alla variabile di ambiente NO_PROXY su tutte le macchine dei nodi.
Installazione
1.10, 1.11, 1.12
Errore nei sistemi con impostazione umask
restrittiva
La versione 1.10.0 di Cluster Anthos 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 nei sistemi con un'impostazione umask più restrittiva di 0077.
Soluzione
Reimposta i nodi del piano di controllo e cambia l'impostazione umask in 0022 su tutte le macchine del piano di controllo. Una volta aggiornate le macchine, prova a eseguire nuovamente l'installazione.
In alternativa, puoi modificare le autorizzazioni di directory e file di
/etc/kubernetes sulle macchine del piano di controllo per
eseguire l'installazione o l'upgrade.
Rendi leggibili /etc/kubernetes e tutte le relative sottodirectory: chmod o+rx.
Rendi tutti i file di proprietà di root utente
nella directory (ricorrentemente) /etc/kubernetes in tutto il mondo
(chmod o+r). Escludi i file della chiave privata (.key) da queste
modifiche perché sono già state create con proprietà e
autorizzazioni corrette.
Rendi il mondo di /usr/local/etc/haproxy/haproxy.cfg leggibile.
Rendi il mondo di /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml leggibile.
Installazione
1.10, 1.11, 1.12, 1.13
Incompatibilità del gruppo di controllo v2
Il gruppo di controllo v2 (cgroup v2) non è supportato nelle versioni 1.13 e precedenti di Cluster Anthos 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 Cluster Anthos on bare metal.
Installazione
1.10, 1.11, 1.12, 1.13, 1.14
Controlli preflight e credenziali dell'account di servizio
Per le installazioni attivate da cluster di amministrazione o cluster ibridi (in altre parole, cluster non creati con bmctl, come i cluster utente), il controllo preflight non verifica le credenziali dell'account di servizio Google Cloud o le autorizzazioni associate.
Affinché 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
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 avrà esito positivo e indicherà Docker service
is not active.
Soluzione
Rimuovi Docker o abilita il servizio Docker.
Installazione
1.10, 1.11, 1.12, 1.13, 1.14
Installazione su vSphere
Quando installi i cluster Anthos su 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 Anthos su Bare Metal.
Soluzione
Esegui il comando seguente su ciascun nodo per verificare i valori attuali di questi flag:
ethtool -k NET_INTFC |grep segm
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
Sostituisci NET_INTFC con l'interfaccia di rete associata all'indirizzo IP del nodo.
A volte in RHEL 8.4, ethtool mostra che questi flag sono disattivati
mentre non lo sono. Per impostare esplicitamente la disattivazione di questi flag, 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
Questo cambiamento di flag non viene mantenuto durante i riavvii. Configura gli script di avvio per impostare in modo esplicito questi flag all'avvio del sistema.
Upgrade e aggiornamenti
1,10
bmctl non può creare, aggiornare o reimpostare i cluster utente della versione inferiore
L'interfaccia a riga di comando di bmctl non può creare, aggiornare o reimpostare un cluster utente con una versione secondaria inferiore, a prescindere 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 con la versione
1.N.X.
Se si verifica questo problema, dovresti visualizzare i log simili ai seguenti quando utilizzi bmctl:
[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:
* cluster version 1.8.1 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 potrebbero bloccare
L'upgrade dei cluster alla versione 1.12.1 a volte si verifica a causa dell'indisponibilità del server API. 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ù momenti, 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 quelli riportati di seguito (gli errori ripetuti indicano che il problema è interessato):
HAProxy e Keepalive devono essere in esecuzione su ciascun nodo del piano di controllo prima di tentare 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 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 successive non riesce quando è abilitato Anthos VM Runtime
Nei cluster Anthos su Bare Metal release 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 il runtime VM di Anthos abilitato in un cluster versione 1.11.xo precedente, l'upgrade alla versione 1.12.0 o successiva non riesce, a meno che non disattivi prima il runtime VM di Anthos. 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 a error during manifests operations
In alcuni casi, gli upgrade del cluster non vengono completati e l'interfaccia a riga di comando di bmctl non risponde. Questo problema può essere causato da una risorsa aggiornata in modo errato. Per determinare se si è verificato questo problema e per correggerlo, controlla i log anthos-cluster-operator e cerca errori simili alle seguenti:
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, completa i seguenti passaggi:
Utilizza kubectl edit per rimuovere l'annotazione kubectl.kubernetes.io/last-applied-configuration dalla risorsa contenuta nel messaggio di log.
Salva e applica le modifiche alla risorsa.
Riprova a eseguire l'upgrade del cluster.
Upgrade e aggiornamenti
1.10, 1.11, 1.12
Gli upgrade sono bloccati per i cluster con funzionalità che utilizzano Anthos
Network Gateway
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. Entrambe queste funzionalità utilizzano Anthos Network Gateway. Gli upgrade dei cluster si bloccano nel messaggio della riga di comando Waiting for upgrade to complete... e negli 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 i comandi seguenti nel cluster di cui stai eseguendo l'upgrade:
Impossibile avviare lo svuotamento del nodo quando il nodo non è raggiungibile
Il processo di svuotamento dei nodi non si avvia se il nodo è fuori dalla portata dei cluster Anthos su Bare Metal. Ad esempio, se un nodo passa alla modalità offline durante un processo di upgrade del cluster, l'upgrade potrebbe non rispondere più. Si tratta di un'eventualità poco probabile.
Soluzione
Per ridurre al minimo la possibilità che si verifichi questo problema, assicurati che i nodi funzionino correttamente prima di iniziare un upgrade.
Upgrade e aggiornamenti
1,12
containerd 1.5.13 richiede libseccomp 2.5 o versioni successive
La versione 1.12.1 di Cluster Anthos on bare metal viene fornita con containerd versione 1.5.13 e questa versione di
containerd richiede libseccomp versione 2.5 o successiva.
Se nel sistema non è installata la versione 2.5 o successive di libseccomp, aggiornala prima di eseguire l'upgrade dei cluster esistenti alla versione 1.12.1. In caso contrario, potrebbero essere visualizzati errori nei pod cplb-update
per i nodi del bilanciatore del carico, ad esempio:
runc did not terminate successfully: runc: symbol lookup error: runc: undefined symbol: seccomp_notify_respond
Soluzione
Per installare l'ultima versione di libseccomp in Ubuntu, esegui il comando seguente:
sudo apt-get install libseccomp-dev
Per installare l'ultima versione 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 non sono contrassegnati se non utilizzi la procedura della modalità di manutenzione
Se esegui i cluster Anthos su Bare Metal versione 1.12.0 (anthosBareMetalVersion: 1.12.0) o inferiore e utilizzi manualmente kubectl cordon su un nodo, i cluster Anthos su Bare Metal potrebbero annullare l'eliminazione del nodo prima che sia tutto pronto per riconciliare lo stato previsto.
Soluzione
Per i cluster Anthos su Bare Metal versione 1.12.0 e precedenti, utilizza la modalità di manutenzione per contrassegnare i nodi e svuotarli in sicurezza.
Nella versione 1.12.1 (anthosBareMetalVersion: 1.12.1) o
successiva, Cluster Anthos on bare metal non annulla la distribuzione imprevista dei nodi 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 tuo cluster di amministrazione è in versione 1.11 e utilizza un mirroring del Registro di sistema, non può gestire i cluster utente che si trovano in una versione secondaria inferiore. Questo problema riguarda le operazioni di reimpostazione, aggiornamento e upgrade sul cluster utente.
Per determinare se questo problema riguarda te, controlla i log per le operazioni del cluster, come creazione, upgrade o reimpostazione. Per impostazione predefinita, questi log si trovano nella cartella bmctl-workspace/CLUSTER_NAME/. Se si verifica il tuo 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 su cluster utente, il comando bmctl check cluster sovrascrive il kubeconfig Secret del cluster utente 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 cluster Anthos su Bare Metal versione 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 su Bare Metal sono il nome del cluster preceduto 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 dal cluster utente specificato.
I seguenti passaggi ripristinano una funzione in un cluster utente interessato
(USER_CLUSTER_NAME):
Individua il file kubeconfig del cluster utente. Cluster Anthos 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. Verifica che i nomi delle macchine siano corretti per il cluster.
Esegui questo comando per eliminare il file kubeconfig danneggiato nel cluster di amministrazione:
Acquisizione di uno snapshot come utente di accesso non root
Se utilizzi containerd come runtime del container, l'esecuzione dello snapshot come utente non root richiede che /usr/local/bin sia presente nel PATH dell'utente. In caso contrario, l'operazione non andrà a buon fine e verrà visualizzato un errore crictl: command not found.
Se non hai eseguito l'accesso come utente root, sudo viene utilizzato per eseguire i comandi degli snapshot. Il sudo PERCORSO può differire dal
profilo principale e potrebbe non 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.
Operazione, Anthos VM Runtime
1.10, 1.11, 1.12, 1.13, 1.14
Anthos VM Runtime - Il riavvio di un pod fa sì che le VM nel pod
modifichino gli indirizzi IP o perdano completamente il proprio indirizzo IP.
Se l'indirizzo IP di una VM cambia, ciò non influisce sulla connettività delle applicazioni VM esposte come servizio Kubernetes.
Soluzione
Se l'indirizzo IP viene perso, devi eseguire dhclient dalla
VM per acquisire un indirizzo IP per la VM.
Logging e monitoraggio
1,10
stackdriver-log-forwarder ha [parser:cri] invalid
time format log di avviso
[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 Cluster Anthos on bare metal alla versione 1.11.0 o successiva.
Se non riesci a eseguire l'upgrade immediato dei cluster, segui questi passaggi per aggiornare l'espressione regolare di analisi CRI:
Per impedire il ripristino delle seguenti modifiche, fai 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_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L%z
Time_Keep off
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 i seguenti casi:
Il monitoraggio delle applicazioni è abilitato (enableStackdriverForApplications=true)
I pod dell'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 relativa alle metriche indesiderate, il problema ti riguarda.
Soluzione
Se si verifica 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 per risolvere il problema:
Separa i flag per controllare la raccolta dei log delle applicazioni rispetto alle metriche delle applicazioni
Servizi gestiti Google Cloud 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 a cui sono associati gli addebiti indesiderati
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
Le modifiche a metrics-server-config non vengono mantenute
Un'elevata densità di pod può, in casi estremi, creare un overhead di logging e monitoraggio eccessivo, che può causare l'arresto e il riavvio di Metrics Server.
Puoi modificare l'oggetto ConfigMap metrics-server-config per allocare
più risorse per mantenere Metrics Server in esecuzione. 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 nuovamente
all'overhead eccessivo.
Soluzione
Per 1.11.x, puoi creare uno script della modifica di ConfigMap ed eseguirla insieme ad aggiornamenti o upgrade al cluster. Per 1.12 e versioni successive, contatta
l'assistenza.
Logging e monitoraggio
1.11, 1.12
Le metriche deprecate influiscono sulla dashboard di Cloud Monitoring
Diverse metriche Anthos sono state deprecate e, a partire dai cluster Anthos su Bare Metal release 1.11, non vengono più raccolti dati per queste metriche deprecate. 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 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 pulsante seguente: 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 relativa allo stato dei nodi del cluster Anthos.
stackdriver-log-forwarder ha CrashloopBackOff
errori
In alcune situazioni, l'agente di logging di fluent-bit potrebbe bloccare blocchi 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 presentano 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:
Esegui la pulizia dei blocchi di buffer per lo strumento di forwarding di Stackdriver Log.
Nota: nei comandi seguenti, sostituisci
KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.
Anche se queste metriche del tipo di riepilogo sono nell'elenco delle metriche, al momento gke-metrics-agent non sono supportate.
Logging e monitoraggio
1.10, 1.11
Interruzioni dell'esportazione delle metriche intermittenti
I cluster Anthos su Bare Metal potrebbero subire interruzioni nella normale esportazione continua di metriche o in 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,10
Più gateway predefiniti bloccano la connettività agli endpoint esterni
Avere più gateway predefiniti in un nodo può causare
problemi di connettività all'interno di un pod a endpoint esterni, come
google.com.
Per determinare se hai riscontrato questo problema, esegui questo comando sul nodo:
ip route show
Più istanze di default nella risposta indicano che il problema ti riguarda.
Networking
1,12
Le modifiche alle risorse personalizzate di rete sui cluster utente vengono sovrascritte
La versione 1.12.x di Cluster Anthos on bare metal non ti impedisce di modificare manualmente le risorse personalizzate di networking nel tuo cluster utente. Cluster Anthos 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 per il networking devono essere modificate solo nel cluster di amministrazione, ma Cluster Anthos on bare metal versione 1.12.x non applica 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 qualsiasi delle risorse personalizzate precedentemente menzionate in un cluster utente, modifica le risorse personalizzate corrispondenti sul tuo cluster di amministrazione in modo che corrispondano prima di eseguire l'upgrade. Questo passaggio garantisce che le
modifiche alla configurazione vengano mantenute. I cluster Anthos su Bare Metal versioni 1.13.0 e successive impediscono di modificare direttamente le risorse personalizzate di networking nei cluster utente.
Networking
1.11, 1.12, 1.13, 1.14
Errore NAT con troppe connessioni parallele
Per un determinato nodo nel tuo cluster, l'indirizzo IP del nodo fornisce la Network Address Translation (NAT) per i pacchetti instradati a un indirizzo esterno al cluster. Analogamente, quando i pacchetti in entrata inseriscono un nodo di bilanciamento del carico configurato per l'utilizzo del bilanciamento del carico in bundle (spec.loadBalancer.mode:
bundled), la 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 cluster Anthos su Bare Metal è pari a 32768-65535. Questo intervallo limita il numero di connessioni in contemporanea a 32.767 per protocollo su quel nodo. Ogni connessione richiede una voce nella tabella conntrack. Se hai troppe connessioni di breve durata, la tabella conntrack esaurisce le porte per NAT. Un raccoglitore di rifiuti pulisce le voci inattive, ma la pulizia non è immediata.
Quando il numero di connessioni sul nodo è pari a 32.767, inizierai a vedere i cali di 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 nel seguente modulo:
No mapping for NAT masquerade DROPPED
Soluzione
Ridistribuisci il traffico su altri nodi.
Networking
1.10, 1.11, 1.12, 1.13, 1.14
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, ad esempio No route to
host per il bilanciamento del carico del 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 mantenere l'indirizzo IP dell'origine client. Con questa impostazione, tuttavia, Kubernetes gestisce solo il traffico locale dei nodi.
Soluzione
Se vuoi conservare l'indirizzo IP dell'origine client, potrebbe essere necessaria
una configurazione aggiuntiva per garantire che gli IP di servizio siano raggiungibili. Per maggiori dettagli sulla configurazione, consulta Preservazione dell'indirizzo IP dell'origine client in Configura il bilanciamento del carico in bundle.
Networking
1.10, 1.11, 1.12, 1.13, 1.14
La modifica di firewalld cancellerà le catene di criteri iptable
Quando esegui Cluster Anthos 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
iptables catene includono, a titolo esemplificativo:
Riavvio di firewalld in corso... utilizzando systemctl
Ricaricamento di firewalld con il client della riga di comando
(firewall-cmd --reload)
Soluzione
Riavvia anetd sul nodo. Individua ed elimina il pod anetd con i seguenti comandi per riavviare anetd:
Quando utilizzi l'anteprima della funzionalità
Gateway NAT in uscita, puoi impostare 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
Coordina il tuo team di sviluppo per determinare quali indirizzi IP mobili
sono disponibili per l'utilizzo prima di specificare l'indirizzo
egressSourceIP nella tua risorsa personalizzata
EgressNATPolicy.
Networking
1.10, 1.11, 1.12, 1.13, 1.14
Errori di connettività dei pod e filtri del percorso inverso
I cluster Anthos su Bare Metal configurano 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 non riusciranno a causa dei timeout delle comunicazioni fuori nodo.
Il filtro del percorso inverso viene impostato con i file rp_filter nella cartella di configurazione IPv4 (net/ipv4/conf/all). Questo valore può anche essere sostituito da sysctl, che archivia le impostazioni del filtro del percorso inverso in un file di configurazione della sicurezza di rete, ad esempio /etc/sysctl.d/60-gce-network-security.conf.
Soluzione
Per ripristinare la connettività dei pod, reimposta
net.ipv4.conf.all.rp_filter su 0 manualmente
o riavvia il pod anetd per impostare
nuovamente net.ipv4.conf.all.rp_filter su 0. Per riavviare il pod anetd, utilizza i comandi seguenti per individuare ed eliminare il pod anetd; si aprirà un nuovo pod anetd al suo posto:
Indirizzi IP del cluster di avvio (tipo) e indirizzi IP del cluster del cluster sovrapposti
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 avranno esito positivo se si sovrappongono agli indirizzi IP delle macchine dei nodi 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
I cluster Anthos su 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à causa la mancata configurazione dell'agente di networking per la rete del cluster con un errore "Il programma BPF è troppo grande" nei log anetd. Potresti
vedere i pod bloccati nello stato ContainerCreating con
un errore networkPlugin cni failed to set up pod nel log eventi
dei pod. Questo problema non si applica ai 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
Creazione o upgrade del cluster su CentOS non riuscito
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 ciclo di vita
(EOL). A causa della EOL, i repository yum hanno smesso di funzionare per CentOS, causando errori nelle operazioni di creazione e upgrade dei cluster. Si applica a tutte le versioni supportate di CentOS e influisce su tutte le versioni di Cluster Anthos on bare metal.
Soluzione
Visualizza i passaggi per la soluzione alternativa
Come soluzione alternativa, esegui i comandi seguenti per fare in modo che CentOS utilizzi un
feed di archivio:
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
/etc/yum.repos.d/CentOS-Linux-*
Come soluzione a lungo termine, valuta la possibilità di eseguire la migrazione a un altro
sistema operativo supportato.
Sistema operativo
1.10, 1.11, 1.12, 1.13, 1.14
Limiti degli endpoint del sistema operativo
Su RHEL e CentOS, esiste una limitazione 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 sottostante nftable su RHEL e CentOS causa questa limitazione; non è una limitazione intrinseca dei cluster Anthos su Bare Metal.
Sicurezza
1.10, 1.11, 1.12, 1.13, 1.14
Il container non può scrivere in VOLUME definito in Dockerfile con containerd e SELinux
Se utilizzi containerd come runtime del container e sul tuo sistema
operativo è abilitato SELinux, VOLUME non può essere definito
nel Dockerfile dell'applicazione. Ad esempio, i container creati con il Dockerfile seguente 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 che presenta problemi:
ausearch -m avc
Se si verifica questo problema, viene visualizzato un errore denied come il seguente:
Per ovviare a questo problema, apporta una delle seguenti modifiche:
Disattiva SELinux.
Non utilizzare la funzionalità VOLUME in Dockerfile.
Sicurezza
1.10, 1.11, 1.12, 1.13, 1.14
Errori SELinux durante la creazione del pod
A volte la creazione dei pod non riesce quando SELinux impedisce al runtime del container di impostare etichette sui montaggi di tmpfs. Questo errore è raro, ma può verificarsi quando SELinux è in modalità Enforcing e in alcuni kernel.
Per verificare che SELinux sia la causa degli errori di creazione dei pod, utilizza il comando seguente per verificare la presenza di errori nei log kubelet:
journalctl -u kubelet
Se SELinux causa l'esito negativo della creazione del 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 cerca negli audit log gli errori di autorizzazione della cache dei vettori di accesso (AVC). La avc: denied nella seguente risposta di esempio conferma che gli errori di creazione dei pod sono correlati all'applicazione SELinux.
La causa principale di questo problema di creazione dei pod con SELinux è un bug del kernel, che si trova nelle seguenti immagini Linux:
Release di Red Hat Enterprise Linux (RHEL) precedenti alla 8.3
Release di CentOS precedenti alla 8.3
Soluzione
Riavviare la macchina aiuta a risolvere il problema.
Per evitare errori di creazione dei pod, usa RHEL 8.3 o versioni successive oppure CentOS 8.3 o versioni successive, perché queste 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 del cluster
prima di eliminare il relativo spazio dei nomi. In caso contrario, i job per il ripristino delle macchine non possono essere creati e il processo di eliminazione ignorerà il passaggio di pulizia della macchina.
Reimposta/elimina
1.10, 1.11, 1.12, 1.13, 1.14
servizio containerd
Il comando bmctl reset non elimina i file di configurazione o i programmi binari di containerd. Il servizio
containerd systemd è attivo e in esecuzione. Il comando elimina i container che eseguono pod pianificati per il nodo.
Upgrade e aggiornamenti
1.10, 1.11, 1.12
La funzionalità di rilevamento dei problemi dei nodi non viene abilitata per impostazione predefinita dopo gli upgrade del cluster
Quando esegui l'upgrade dei cluster Anthos su Bare Metal, il rilevatore dei problemi dei nodi non è abilitato per impostazione predefinita. Questo problema è applicabile agli upgrade dalla versione 1.10 alla
1.12.1 ed è stato risolto nella release 1.12.2.
Soluzione:
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, il
nodo-problem-detecter 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 saperne di più, consulta la pagina Rilevamento dei problemi dei nodi.
Operazione
1,9, 1,10
Il backup del cluster non riesce quando si utilizza l'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 cluster Anthos su 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 in 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 nella specifica del container.
Il bug non è presente nella versione 1.13 o successive.
Soluzione:
Le seguenti soluzioni alternative possono essere utili se utilizzi un servizio LoadBalancer supportato da pod hostNetwork:
Eseguili sui nodi worker (non sui nodi del piano di controllo).
1,12 cluster aggiornati da 1.11 non possono eseguire l'upgrade a 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 questo è interessato, 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,
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 il problema:
Esegui i comandi seguenti sulla workstation di amministrazione:
Dashboard ed elimina la dashboard dello stato dei nodi del cluster Anthos.