Installazione e configurazione dell'operatore di monitoraggio Kubernetes
Cloud Insights offre la raccolta Kubernetes Monitoring Operator for Kubernetes. Navigare a Kubernetes > Collector > +Kubernetes Collector per implementare un nuovo operatore.
Prima di installare l'operatore di monitoraggio Kubernetes
Vedere "Prerequisiti" Documentazione prima di installare o aggiornare Kubernetes Monitoring Operator.
Installazione dell'operatore di monitoraggio Kubernetes
-
Immettere un nome cluster e uno spazio dei nomi univoci. Se lo sei aggiornamento in corso Da un operatore Kubernetes precedente, utilizzare lo stesso nome del cluster e lo stesso namespace.
-
Una volta immessi, è possibile copiare il frammento Download Command negli Appunti.
-
Incollare il frammento in una finestra bash ed eseguirlo. I file di installazione dell'operatore verranno scaricati. Tenere presente che il frammento ha una chiave univoca ed è valido per 24 ore.
-
Se si dispone di un repository personalizzato o privato, copiare il frammento Image Pull opzionale, incollarlo in una shell bash ed eseguirlo. Una volta estratte le immagini, copiarle nel repository privato. Assicurarsi di mantenere gli stessi tag e la stessa struttura di cartelle. Aggiornare i percorsi in operator-deployment.yaml e le impostazioni del repository di docker in operator-config.yaml.
-
Se lo si desidera, esaminare le opzioni di configurazione disponibili, ad esempio le impostazioni del proxy o del repository privato. Ulteriori informazioni su "opzioni di configurazione".
-
Quando sei pronto, implementa l'operatore copiando il frammento kubectl apply, scaricandolo ed eseguendolo.
-
L'installazione procede automaticamente. Una volta completata l'operazione, fare clic sul pulsante Avanti.
-
Al termine dell'installazione, fare clic sul pulsante Next. Assicurarsi inoltre di eliminare o memorizzare in modo sicuro il file operator-secrets.yaml.
Se si utilizza un proxy, leggere informazioni su configurazione del proxy.
Se si dispone di un repository personalizzato, leggere informazioni utilizzando un repository di docker personalizzato/privato.
Componenti di monitoring Kubernetes
Il monitoraggio Kubernetes Cloud Insights comprende quattro componenti di monitoraggio:
-
Metriche cluster
-
Mappa e prestazioni della rete (opzionale)
-
Registri eventi (opzionali)
-
Analisi delle modifiche (opzionale)
I componenti opzionali elencati in precedenza sono abilitati per impostazione predefinita per ogni collettore di Kubernetes; se si decide di non avere bisogno di un componente per un determinato collettore, è possibile disattivarlo accedendo a Kubernetes > Collectors e selezionando Modify Deployment dal menu "Three Dots" del collettore sulla destra dello schermo.
La schermata mostra lo stato corrente di ciascun componente e consente di disattivare o attivare i componenti per tale collettore, se necessario.
Aggiornamento in corso
Aggiornamento alla versione più recente di Kubernetes Monitoring Operator
Determinare se esiste una configurazione Agentcon l'operatore esistente (se lo spazio dei nomi non è il monitoraggio netapp predefinito, sostituire lo spazio dei nomi appropriato):
kubectl -n netapp-monitoring get agentconfiguration netapp-monitoring-configuration Se esiste una configurazione AgentConfiguration:
-
Installare L'operatore più recente rispetto all'operatore esistente.
-
Assicurati di sì estrarre le immagini container più recenti se si utilizza un repository personalizzato.
-
Se AgentConfiguration non esiste:
-
Prendere nota del nome del cluster riconosciuto da Cloud Insights (se lo spazio dei nomi non è il monitoraggio netapp predefinito, sostituire lo spazio dei nomi appropriato):
kubectl -n netapp-monitoring get agent -o jsonpath='{.items[0].spec.cluster-name}' * Creare un backup dell'operatore esistente (se lo spazio dei nomi non è il monitoraggio netapp predefinito, sostituire lo spazio dei nomi appropriato):
kubectl -n netapp-monitoring get agent -o yaml > agent_backup.yaml * <<to-remove-the-kubernetes-monitoring-operator,Disinstallare>> L'operatore esistente. * <<installing-the-kubernetes-monitoring-operator,Installare>> L'operatore più recente.
-
Utilizzare lo stesso nome del cluster.
-
Dopo aver scaricato i file YAML dell'operatore più recenti, portare le personalizzazioni trovate in Agent_backup.yaml nell'operator-config.yaml scaricato prima di eseguire la distribuzione.
-
Assicurati di sì estrarre le immagini container più recenti se si utilizza un repository personalizzato.
-
Arresto e avvio dell'operatore di monitoraggio Kubernetes
Per arrestare l'operatore di monitoraggio Kubernetes:
kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=0 Per avviare l'operatore di monitoraggio Kubernetes:
kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=1
Disinstallazione in corso
Per rimuovere l'operatore di monitoraggio Kubernetes
Si noti che il namespace predefinito per Kubernetes Monitoring Operator è "netapp-monitoring". Se è stato impostato uno spazio dei nomi personalizzato, sostituire tale spazio dei nomi in questi e in tutti i comandi e file successivi.
Le versioni più recenti dell'operatore di monitoraggio possono essere disinstallate con i seguenti comandi:
kubectl -n <NAMESPACE> delete agent -l installed-by=nkmo-<NAMESPACE> kubectl -n <NAMESPACE> delete clusterrole,clusterrolebinding,crd,svc,deploy,role,rolebinding,secret,sa -l installed-by=nkmo-<NAMESPACE>
Se l'operatore di monitoraggio è stato distribuito nel proprio spazio dei nomi dedicato, eliminare lo spazio dei nomi:
kubectl delete ns <NAMESPACE> Se il primo comando restituisce "Nessuna risorsa trovata", attenersi alle istruzioni riportate di seguito per disinstallare le versioni precedenti dell'operatore di monitoraggio.
Eseguire ciascuno dei seguenti comandi nell'ordine indicato. A seconda dell'installazione corrente, alcuni di questi comandi potrebbero restituire i messaggi ‘oggetto non trovato’. Questi messaggi possono essere ignorati in modo sicuro.
kubectl -n <NAMESPACE> delete agent agent-monitoring-netapp kubectl delete crd agents.monitoring.netapp.com kubectl -n <NAMESPACE> delete role agent-leader-election-role kubectl delete clusterrole agent-manager-role agent-proxy-role agent-metrics-reader <NAMESPACE>-agent-manager-role <NAMESPACE>-agent-proxy-role <NAMESPACE>-cluster-role-privileged kubectl delete clusterrolebinding agent-manager-rolebinding agent-proxy-rolebinding agent-cluster-admin-rolebinding <NAMESPACE>-agent-manager-rolebinding <NAMESPACE>-agent-proxy-rolebinding <NAMESPACE>-cluster-role-binding-privileged kubectl delete <NAMESPACE>-psp-nkmo kubectl delete ns <NAMESPACE>
Se in precedenza è stato creato un vincolo del contesto di protezione:
kubectl delete scc telegraf-hostaccess
A proposito di Kube-state-metrics
NetApp Kubernetes Monitoring Operator installa le proprie metriche di stato kube per evitare conflitti con altre istanze.
Per informazioni su Kube-state-Metrics, vedere "questa pagina".
Configurazione/personalizzazione dell'operatore
Queste sezioni contengono informazioni sulla personalizzazione della configurazione dell'operatore, sull'utilizzo di proxy, sull'utilizzo di un repository di docker personalizzato o privato o sull'utilizzo di OpenShift.
Opzioni di configurazione
Le impostazioni più comunemente modificate possono essere configurate nella risorsa personalizzata AgentConfiguration. È possibile modificare questa risorsa prima di implementare l'operatore modificando il file operator-config.yaml. Questo file include esempi di impostazioni commentate. Vedere l'elenco di "impostazioni disponibili" per la versione più recente dell'operatore.
È anche possibile modificare questa risorsa dopo che l'operatore è stato distribuito utilizzando il seguente comando:
kubectl -n netapp-monitoring edit AgentConfiguration Per determinare se la versione implementata dell'operatore supporta AgentConfiguration, eseguire il seguente comando:
kubectl get crd agentconfigurations.monitoring.netapp.com Se viene visualizzato il messaggio "Error from server (notfound)" (errore dal server (non trovato)), l'operatore deve essere aggiornato prima di poter utilizzare AgentConfiguration.
Configurazione del supporto proxy
Esistono due posizioni in cui è possibile utilizzare un proxy nell'ambiente per installare l'operatore di monitoraggio Kubernetes. Questi possono essere sistemi proxy identici o separati:
-
Proxy necessario durante l'esecuzione del frammento di codice di installazione (utilizzando "curl") per connettere il sistema in cui viene eseguito il frammento all'ambiente Cloud Insights
-
Proxy necessario dal cluster Kubernetes di destinazione per comunicare con l'ambiente Cloud Insights
Se si utilizza un proxy per uno o per entrambi, per installare il monitor operativo Kubernetes è necessario prima assicurarsi che il proxy sia configurato in modo da consentire una buona comunicazione con l'ambiente Cloud Insights. Se si dispone di un proxy e si può accedere a Cloud Insights dal server/VM da cui si desidera installare l'operatore, è probabile che il proxy sia configurato correttamente.
Per il proxy utilizzato per installare il monitor operativo Kubernetes, prima di installare l'operatore, impostare le variabili di ambiente http_proxy/https_proxy. Per alcuni ambienti proxy, potrebbe essere necessario impostare la variabile no_proxy environment.
Per impostare le variabili, eseguire i seguenti passaggi sul sistema prima di installare l'operatore di monitoraggio Kubernetes:
-
Impostare le variabili di ambiente https_proxy e/o http_proxy per l'utente corrente:
-
Se il proxy da configurare non dispone dell'autenticazione (nome utente/password), eseguire il seguente comando:
export https_proxy=<proxy_server>:<proxy_port> .. Se il proxy da configurare dispone dell'autenticazione (nome utente/password), eseguire questo comando:
export http_proxy=<proxy_username>:<proxy_password>@<proxy_server>:<proxy_port>
-
Per il proxy utilizzato per il cluster Kubernetes e comunicare con l'ambiente Cloud Insights, installare l'operatore di monitoraggio Kubernetes dopo aver letto tutte queste istruzioni.
Configurare la sezione proxy di AgentConfiguration in operator-config.yaml prima di distribuire l'operatore di monitoraggio Kubernetes.
agent: ... proxy: server: <server for proxy> port: <port for proxy> username: <username for proxy> password: <password for proxy> # In the noproxy section, enter a comma-separated list of # IP addresses and/or resolvable hostnames that should bypass # the proxy noproxy: <comma separated list> isTelegrafProxyEnabled: true isFluentbitProxyEnabled: <true or false> # true if Events Log enabled isCollectorsProxyEnabled: <true or false> # true if Network Performance and Map enabled isAuProxyEnabled: <true or false> # true if AU enabled ... ...
Utilizzando un repository di docker personalizzato o privato
Per impostazione predefinita, l'operatore di monitoraggio Kubernetes estrarrà le immagini dei container dal repository Cloud Insights. Se hai un cluster Kubernetes utilizzato come destinazione per il monitoring e tale cluster è configurato in modo da estrarre solo le immagini dei container da un repository Docker o da un registro dei container personalizzato o privato, devi configurare l'accesso ai container necessari da Kubernetes Monitoring Operator.
Eseguire il frammento Image Pull dalla sezione di installazione di NetApp Monitoring Operator. Questo comando effettua l'accesso al repository Cloud Insights, inserisce tutte le dipendenze dell'immagine per l'operatore e si disconnette dal repository Cloud Insights. Quando richiesto, inserire la password temporanea del repository fornita. Questo comando scarica tutte le immagini utilizzate dall'operatore, incluse le funzioni opzionali. Vedere di seguito per quali funzioni vengono utilizzate queste immagini.
Funzionalità principale dell'operatore e monitoraggio Kubernetes
-
monitoraggio netapp
-
ci-kube-rbac-proxy
-
ci-ksm
-
ci-telegraf
-
distroless-root-user
Registro eventi
-
ci-fluent-bit
-
ci-kukasub-esportatore-di-eventi
Mappa e performance di rete
-
ci-net-osservatore
Trasferire l'immagine del gestore nel repository del supporto privato/locale/aziendale in base alle policy aziendali. Assicurarsi che i tag delle immagini e i percorsi delle directory per queste immagini nel repository siano coerenti con quelli nel repository Cloud Insights.
Modificare l'implementazione dell'operatore di monitoraggio in operator-deployment.yaml e modificare tutti i riferimenti alle immagini per utilizzare il repository Docker privato.
image: <docker repo of the enterprise/corp docker repo>/kube-rbac-proxy:<ci-kube-rbac-proxy version> image: <docker repo of the enterprise/corp docker repo>/netapp-monitoring:<version>
Modificare la configurazione dell'agente in operator-config.yaml in modo che rifletta la nuova posizione del responsabile del docker. Crea un nuovo imagePullSecret per il tuo repository privato; per ulteriori dettagli, consulta https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
agent: ... # An optional docker registry where you want docker images to be pulled from as compared to CI's docker registry # Please see documentation link here: link:task_config_telegraf_agent_k8s.html#using-a-custom-or-private-docker-repository dockerRepo: your.docker.repo/long/path/to/test # Optional: A docker image pull secret that maybe needed for your private docker registry dockerImagePullSecret: docker-secret-name
Istruzioni per OpenShift
Se si utilizza OpenShift 4.6 o versione successiva, è necessario modificare la configurazione dell'agente in operator-config.yaml per attivare l'impostazione runPrivileged:
# Set runPrivileged to true SELinux is enabled on your kubernetes nodes runPrivileged: true
OpenShift potrebbe implementare un ulteriore livello di sicurezza che potrebbe bloccare l'accesso ad alcuni componenti di Kubernetes.
Una nota sui segreti
Per rimuovere l'autorizzazione per l'operatore di monitoraggio Kubernetes a visualizzare segreti a livello del cluster, eliminare le seguenti risorse dal file operatore-setup.yaml prima di eseguire l'installazione:
ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding
Se si tratta di un aggiornamento, eliminare anche le risorse dal cluster:
kubectl delete ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole kubectl delete ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding
Se l'analisi delle modifiche è attivata, modificare AgentConfiguration o operator-config.yaml per annullare il commento alla sezione di gestione delle modifiche e includere kindsToIgnoreFromWatch: '"secrets"' nella sezione di gestione delle modifiche. Notare la presenza e la posizione di virgolette singole e doppie in questa riga.
# change-management: ... # # A comma separated list of kinds to ignore from watching from the default set of kinds watched by the collector # # Each kind will have to be prefixed by its apigroup # # Example: '"networking.k8s.io.networkpolicies,batch.jobs", "authorization.k8s.io.subjectaccessreviews"' kindsToIgnoreFromWatch: '"secrets"' ...
Verifica dei checksum di Kubernetes
Il programma di installazione dell'agente Cloud Insights esegue controlli di integrità, ma alcuni utenti potrebbero voler eseguire le proprie verifiche prima di installare o applicare gli artefatti scaricati. Per eseguire un'operazione di solo download (invece del download e dell'installazione predefiniti), questi utenti possono modificare il comando di installazione dell'agente ottenuto dall'interfaccia utente e rimuovere l'opzione finale di "installazione".
Attenersi alla seguente procedura:
-
Copiare il frammento del programma di installazione dell'agente come indicato.
-
Invece di incollare il frammento in una finestra di comando, incollarlo in un editor di testo.
-
Rimuovere il file "--install" finale dal comando.
-
Copiare l'intero comando dall'editor di testo.
-
Incollarlo nella finestra di comando (in una directory di lavoro) ed eseguirlo.
-
Download e installazione (impostazione predefinita):
installerName=cloudinsights-rhel_centos.sh … && sudo -E -H ./$installerName --download –-install ** Solo download:
installerName=cloudinsights-rhel_centos.sh … && sudo -E -H ./$installerName --download
-
Il comando di solo download scaricherà tutti gli artefatti richiesti da Cloud Insights nella directory di lavoro. Gli artefatti includono, ma non possono essere limitati a:
-
uno script di installazione
-
un file di ambiente
-
File YAML
-
un file checksum firmato (sha256.signed)
-
Un file PEM (netapp_cert.pem) per la verifica della firma
Lo script di installazione, il file di ambiente e i file YAML possono essere verificati utilizzando l'ispezione visiva.
Il file PEM può essere verificato confermando che l'impronta digitale è la seguente:
1A918038E8E127BB5C87A202DF173B97A05B4996 In particolare,
openssl x509 -fingerprint -sha1 -noout -inform pem -in netapp_cert.pem Il file checksum firmato può essere verificato utilizzando il file PEM:
openssl smime -verify -in sha256.signed -CAfile netapp_cert.pem -purpose any Una volta verificati correttamente tutti gli artefatti, l'installazione dell'agente può essere avviata eseguendo:
sudo -E -H ./<installation_script_name> --install
Tolerazioni e contamini
I DaemonSet netapp-ci-telegraf-ds, netapp-ci-fluent-bit-ds e netapp-ci-net-observer-L4-ds devono pianificare un pod su ogni nodo del cluster per raccogliere correttamente i dati su tutti i nodi. L'operatore è stato configurato in modo da tollerare alcuni segni noti. Se sono stati configurati dei tipi di contamini personalizzati sui nodi, impedendo l'esecuzione dei pod su ogni nodo, è possibile creare una tolleranza per tali tipi di contamini "In AgentConfiguration". Se sono stati applicati dei tipi di manutenzione personalizzati a tutti i nodi del cluster, è necessario aggiungere anche le tolleranze necessarie all'implementazione dell'operatore per consentire la pianificazione e l'esecuzione del pod operatore.
Scopri di più su Kubernetes "Contamini e pedaggi".
Risoluzione dei problemi
Alcuni elementi da provare in caso di problemi durante la configurazione dell'operatore di monitoring Kubernetes:
Problema: | Prova: |
---|---|
Non viene visualizzato un collegamento ipertestuale/connessione tra il volume persistente Kubernetes e il dispositivo di storage back-end corrispondente. Il volume persistente Kubernetes viene configurato utilizzando il nome host del server di storage. |
Seguire la procedura per disinstallare l'agente Telegraf esistente, quindi reinstallare l'agente Telegraf più recente. È necessario utilizzare Telegraf versione 2.0 o successiva e lo storage del cluster Kubernetes deve essere monitorato attivamente da Cloud Insights. |
Nei registri vengono visualizzati messaggi simili a quelli riportati di seguito: |
Questi messaggi possono verificarsi se si utilizza kube-state-metrics versione 2.0.0 o superiore con versioni di Kubernetes inferiori alla 1.20. |
Vengono visualizzati messaggi di errore di Telegraf simili ai seguenti, ma Telegraf si avvia ed esegue: |
Si tratta di un problema noto. Fare riferimento a. "Questo articolo di GitHub" per ulteriori dettagli. Finché Telegraf è in funzione, gli utenti possono ignorare questi messaggi di errore. |
In Kubernetes, i pod Telegraf riportano il seguente errore: |
Se SELinux è abilitato e abilitato, probabilmente impedisce ai pod Telegraf di accedere al file /proc/1/mountstats sul nodo Kubernetes. Per superare questa restrizione, modificare la configurazione dell'agente e attivare l'impostazione runPrivileged. Per ulteriori informazioni, fare riferimento alla "Istruzioni per OpenShift". |
In Kubernetes, il pod Telegraf ReplicaSet riporta il seguente errore: |
Il pod ReplicaSet di Telegraf è destinato all'esecuzione su un nodo designato come master o etcd. Se il pod ReplicaSet non è in esecuzione su uno di questi nodi, si otterranno questi errori. Verificare se i nodi master/etcd presentano delle contaminazioni. In tal caso, aggiungere le tolleranze necessarie a Telegraf ReplicaSet, telegraf-rs. |
Ho un ambiente PSP/PSA. Questo influisce sul mio operatore di monitoraggio? |
Se il cluster Kubernetes è in esecuzione con Pod Security Policy (PSP) o Pod Security Admission (PSA), è necessario eseguire l'aggiornamento all'ultima versione di Kubernetes Monitoring Operator. Per eseguire l'aggiornamento all'operatore corrente con il supporto per PSP/PSA, procedere come segue: |
Ho riscontrato dei problemi durante la distribuzione dell'operatore e ho utilizzato PSP/PSA. |
1. Modificare l'agente utilizzando il seguente comando: |
grep -i psp (dovrebbe mostrare che non si trova nulla) |
Errori "ImagePullBackoff" rilevati |
Questi errori possono essere rilevati se si dispone di un repository di docker personalizzato o privato e non è ancora stato configurato l'operatore di monitoraggio Kubernetes in modo da riconoscerlo correttamente. Scopri di più informazioni sulla configurazione per repo personalizzato/privato. |
Si verifica un problema con l'implementazione dell'operatore di monitoraggio e la documentazione corrente non mi aiuta a risolverlo. |
Acquisire o annotare in altro modo l'output dei seguenti comandi e contattare il team di supporto tecnico. kubectl -n netapp-monitoring get all kubectl -n netapp-monitoring describe all kubectl -n netapp-monitoring logs <monitoring-operator-pod> --all-containers=true kubectl -n netapp-monitoring logs <telegraf-pod> --all-containers=true |
I pod Net-observer (mappa del carico di lavoro) nello spazio dei nomi Operator si trovano in CrashLoopBackOff |
Questi pod corrispondono al data collector Workload Map per l'osservabilità della rete. Provare a effettuare le seguenti operazioni: |
I pod vengono eseguiti in Operator namespace (predefinito: Monitoring netapp), ma non vengono visualizzati dati nell'interfaccia utente per la mappa dei carichi di lavoro o le metriche Kubernetes nelle query |
Controllare l'impostazione dell'ora sui nodi del cluster K8S. Per un controllo accurato e la creazione di report dei dati, si consiglia di sincronizzare l'ora sul computer dell'agente utilizzando il protocollo NTP (Network Time Protocol) o SNTP (Simple Network Time Protocol). |
Alcuni dei pod net-observer nello spazio dei nomi Operator sono in stato Pending |
NET-osservatore è un DemonSet che esegue un pod in ogni nodo del cluster k8s. |
Vedo quanto segue nei miei log subito dopo l'installazione dell'operatore di monitoraggio Kubernetes: |
Questo messaggio viene visualizzato in genere solo quando viene installato un nuovo operatore e il pod telegraf-rs è attivo prima che il pod ksm sia attivo. Questi messaggi dovrebbero interrompersi una volta che tutti i pod sono in esecuzione. |
Non vedo alcuna metrica raccolta per Kubernetes Cronjobs che esiste nel mio cluster. |
Verificare la versione di Kubernetes (ad es |
Dopo aver installato l'operatore, i pod telegraf-ds entrano in CrashLoopBackOff e i registri del pod indicano "su: Authentication failure" (su: Errore di autenticazione). |
Modificare la sezione telegraf in AgentConfiguration e impostare dockerMetricCollectionEnabled su false. Per ulteriori dettagli, fare riferimento al manuale dell'operatore "opzioni di configurazione". |
Nei registri di Telegraf vengono visualizzati messaggi di errore ricorrenti simili a quelli riportati di seguito: |
Modificare la sezione telegraf in AgentConfiguration e aumentare outputTimeout a 10s. Per ulteriori dettagli, fare riferimento al manuale dell'operatore "opzioni di configurazione". |
Mancano i dati involvedobject per alcuni registri eventi. |
Assicurarsi di aver seguito i passaggi descritti in "Permessi" sezione precedente. |
Perché vedo due pod operatore di monitoring in esecuzione, uno denominato netapp-ci-monitoring-operator-<pod> e l'altro denominato monitoring-operator-<pod>? |
A partire dal 12 ottobre 2023, Cloud Insights ha ridefinito l'operatore per servire meglio i nostri utenti; affinché tali modifiche siano completamente adottate, è necessario rimuovere il vecchio operatore e. installare il nuovo. |
I miei eventi kuowski hanno inaspettatamente smesso di segnalare a Cloud Insights. |
Recuperare il nome del pod dell'esportatore di eventi: `kubectl -n netapp-monitoring get pods |
grep event-exporter |
awk '{print $1}' |
sed 's/event-exporter./event-exporter/'` |
Sto vedendo i pod implementati dal crash dell'operatore di monitoring Kubernetes a causa di risorse insufficienti. |
Fare riferimento a Kubernetes Monitoring Operator "opzioni di configurazione" Per aumentare i limiti di CPU e/o memoria in base alle esigenze. |
Un'immagine mancante o una configurazione non valida ha causato il mancato avvio o la mancata preparazione dei pod di metriche a stato di netapp-ci-kube. Ora StatefulSet è bloccato e le modifiche della configurazione non vengono applicate ai pod di metriche stato netapp-ci-kube. |
StatefulSet si trova in un "rotto" stato. Dopo aver risolto eventuali problemi di configurazione, bounce i pod di metrica stato netapp-ci-kube. |
I pod con metriche a stato di netapp-ci-kube non si avviano dopo l'aggiornamento di un operatore Kubernetes, lanciando ErrImagePull (non riuscendo a estrarre l'immagine). |
Provare a reimpostare i pod manualmente. |
I messaggi "evento scartato come vecchio allora maxEventAgeSeconds" vengono osservati per il mio cluster Kubernetes in Log Analysis. |
Modificare l'operatore agentconfiguration e aumentare il event-exportant-maxEventAgeSeconds (cioè a 60s), il event-exportant-kubeQPS (cioè a 100) e il event-exportant-kubeBurst (cioè a 500). Per ulteriori informazioni su queste opzioni di configurazione, consultare la "opzioni di configurazione" pagina. |
Telegraf avverte di, o si blocca a causa di, memoria bloccabile insufficiente. |
Provare ad aumentare il limite di memoria bloccabile per Telegraf nel sistema operativo/nodo sottostante. Se l'aumento del limite non è un'opzione, modificare la configurazione dell'agente NKMO e impostare non protetto su true. In questo modo, Telegraf non tenterà di riservare pagine di memoria bloccate. Sebbene ciò possa rappresentare un rischio per la sicurezza poiché i segreti decrittografati potrebbero essere scambiati sul disco, consente l'esecuzione in ambienti in cui non è possibile riservare la memoria bloccata. Per ulteriori informazioni sulle opzioni di configurazione non protetto, fare riferimento alla "opzioni di configurazione" pagina. |
Per ulteriori informazioni, consultare "Supporto" o in "Matrice di supporto Data Collector".