Questo documento ti aiuta a risolvere i problemi di osservabilità in Google Distributed Cloud. Se riscontri uno di questi problemi, consulta le correzioni e le soluzioni alternative suggerite.
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.
Gli audit log di Cloud non vengono raccolti
I log di audit di Cloud sono abilitati per impostazione predefinita, a meno che non sia impostato undisableCloudAuditLogging
flag nella sezione clusterOperations
della configurazione del cluster.
Se i log di audit di Cloud sono abilitati, le autorizzazioni sono il motivo più comune per cui i log non vengono raccolti. In questo scenario, i messaggi di errore di autorizzazione negata vengono visualizzati nel contenitore proxy di Cloud Audit Logs.
Il container proxy di Cloud Audit Logs viene eseguito come DaemonSet in tutti i cluster Google Distributed Cloud.Se visualizzi errori di autorizzazione, segui i passaggi per risolvere i problemi di autorizzazione.
Un'altra possibile causa è che il tuo progetto potrebbe aver raggiunto il limite di account di servizio supportati. Consulta Account di servizio dei log di controllo di Cloud divulgato.
Le metriche kube-state-metrics
non vengono raccolte
kube-state-metrics
(KSM) viene eseguito come deployment a singola replica nel cluster
e genera metriche su quasi tutte le risorse del cluster. Quando KSM e gke-metrics-agent
vengono eseguiti sullo stesso nodo, esiste un rischio maggiore di interruzione tra gli agenti delle metriche su tutti i nodi.
Le metriche KSM hanno nomi che seguono il pattern di kube_<ResourceKind>
, ad esempio
kube_pod_container_info
. Le metriche che iniziano con kube_onpremusercluster_
provengono dal controller del cluster on-premise, non da KSM.
Se le metriche KSM non sono presenti, esamina i seguenti passaggi per la risoluzione dei problemi:
- In Cloud Monitoring, controlla la CPU, la memoria e il conteggio dei riavvii di KSM utilizzando le metriche dell'API di riepilogo come
kubernetes.io/anthos/container/...
. Si tratta di una pipeline separata con KSM. Verifica che il pod KSM non sia limitato da risorse insufficienti.- Se queste metriche dell'API di riepilogo non sono disponibili per KSM,
gke-metrics-agent
sullo stesso nodo probabilmente si verifica lo stesso problema.
- Se queste metriche dell'API di riepilogo non sono disponibili per KSM,
- Nel cluster, controlla lo stato e i log del pod KSM e del
gke-metrics-agent
pod sullo stesso nodo con KSM.
kube-state-metrics
loop di arresti anomali
Sintomo
Cloud Monitoring non fornisce metriche di kube-state-metrics
(KSM).
Causa
Questo scenario è più probabile che si verifichi in cluster di grandi dimensioni o con grandi quantità di risorse. KSM viene eseguito come deployment con una singola replica ed elenca quasi tutte le risorse del cluster, come pod, deployment, DaemonSet, ConfigMap, secret e PersistentVolume. Le metriche vengono generate su ciascuno di questi oggetti risorsa. Se una delle risorse ha molti oggetti, ad esempio un cluster con più di 10.000 pod, KSM potrebbe esaurire la memoria.
Versioni interessate
Questo problema potrebbe verificarsi in qualsiasi versione di Google Distributed Cloud.
Il limite predefinito di CPU e memoria è stato aumentato nelle ultime versioni di Google Distributed Cloud, pertanto questi problemi relativi alle risorse dovrebbero essere meno comuni.
Correzione e soluzione alternativa
Per verificare se il problema è dovuto a un problema di esaurimento della memoria, esamina i seguenti passaggi:
- Utilizza
kubectl describe pod
okubectl get pod -o yaml
e controlla il messaggio di stato dell'errore. - Controlla la metrica di consumo e utilizzo della memoria per KSM e verifica se sta raggiungendo il limite prima del riavvio.
Se confermi che il problema è correlato alla mancanza di memoria, utilizza una delle seguenti soluzioni:
Aumenta la richiesta e il limite di memoria per KSM.
Per le versioni 1.16.0 o successive di Google Distributed Cloud, Google Cloud Observability gestisce KSM. Per aggiornare KSM, consulta Ignorare le richieste e i limiti di CPU e memoria predefiniti per un componente di Stackdriver.
Per le versioni precedenti alla 1.16.0, per regolare la CPU e la memoria di KSM, utilizza resourceOverride della risorsa personalizzata Stackdriver per
kube-state-metrics
.
Riduci il numero di metriche del KSM.
Per Google Distributed Cloud 1.13, KSM espone per impostazione predefinita solo un numero minore di metriche chiamate Metriche di base. Questo comportamento significa che l'utilizzo delle risorse è inferiore rispetto alle versioni precedenti, ma è possibile seguire la stessa procedura per ridurre ulteriormente il numero di metriche KSM.
Per le versioni di Google Distributed Cloud precedenti alla 1.13, KSM utilizza i flag predefiniti. Questa configurazione espone un numero elevato di metriche.
gke-metrics-agent
loop di arresti anomali
Se gke-metrics-agent
presenta problemi di esaurimento della memoria solo sul nodo in cui è presente kube-state-metrics
, la causa è un numero elevato di metriche kube-state-metrics
. Per ridurre il problema, riduci le dimensioni di stackdriver-operator
e modifica KSM in modo da esporre un piccolo insieme di metriche necessarie, come descritto nella sezione precedente.
Ricordati di eseguire il ridimensionamento verso il basso stackdriver-operator
dopo l'upgrade del cluster
a Google Distributed Cloud 1.13, in cui KSM per impostazione predefinita espone un numero minore di Core
Metric.
gke-metric-agent
. Puoi regolare la CPU e la memoria per tutti i gke-metrics-agent
pod aggiungendo il
campo resourceAttrOverride
alla risorsa personalizzata Stackdriver.
stackdriver-metadata-agent
loop di arresti anomali
Sintomo
Non è disponibile alcuna etichetta dei metadati di sistema per filtrare le metriche in Cloud Monitoring.
Causa
Il caso più comune di stackdriver-metadata-agent
crash looping è dovuto a eventi di esaurimento della memoria. Questo evento è simile a kube-state-metrics
. Anche se
stackdriver-metadata-agent
non elenca tutte le risorse, elenca comunque tutti
gli oggetti per i tipi di risorse pertinenti come Pod, Deployment e
NetworkPolicy. L'agente viene eseguito come deployment con una singola replica, il che aumenta il rischio di eventi di esaurimento della memoria se il numero di oggetti è troppo elevato.
Versione interessata
Questo problema potrebbe verificarsi in qualsiasi versione di Google Distributed Cloud.
Il limite predefinito di CPU e memoria è stato aumentato nelle ultime versioni di Google Distributed Cloud, pertanto questi problemi relativi alle risorse dovrebbero essere meno comuni.
Correzione e soluzione alternativa
Per verificare se il problema è dovuto a un problema di esaurimento della memoria, esamina i seguenti passaggi:
- Utilizza
kubectl describe pod
okubectl get pod -o yaml
e controlla il messaggio di stato dell'errore. - Controlla la metrica di consumo e utilizzo della memoria per
stackdriver-metadata-agent
e verifica se sta raggiungendo il limite prima di essere riavviata.
resourceAttrOverride
della risorsa personalizzata Stackdriver.
metrics-server
loop di arresti anomali
Sintomo
Horizontal Pod Autoscaler e kubectl top
non funzionano nel tuo cluster.
Causa e versioni interessate
Questo problema non è molto comune, ma è causato da errori di esaurimento della memoria in cluster di grandi dimensioni o in cluster con elevata densità di pod.
Questo problema potrebbe verificarsi in qualsiasi versione di Google Distributed Cloud.
Correzione e soluzione alternativa
Aumenta i limiti delle risorse del server delle metriche.
In Google Distributed Cloud versione 1.13 e successive, lo spazio dei nomi di metrics-server
e la relativa configurazione sono stati spostati da kube-system
a
gke-managed-metrics-server
.
metrics-server-operator
e modifica manualmente il pod metrics-server
.
Non tutte le risorse vengono rimosse durante l'eliminazione dell'account di servizio Cloud Audit Logs
Quando elimini un account di servizio utilizzato per gli audit log di Cloud, non tutte le risorse vengono eliminate. Google Cloud Se elimini e ricrei regolarmente gli account di servizio utilizzati per i log di controllo di Cloud, alla fine il logging di controllo inizia a non riuscire.
Sintomo
I messaggi di errore di autorizzazione negata vengono visualizzati nel contenitore proxy di Cloud Audit Logs.
Per verificare che l'errore del log di controllo sia causato da questo problema, esegui il seguente comando:
curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/global/features/cloudauditlogging
Sostituisci PROJECT_NUMBER
con il numero del tuo progetto.
La risposta restituisce tutti gli account di servizio utilizzati con i log di controllo di Cloud nel progetto, inclusi quelli eliminati.
Causa e versioni interessate
Non tutte le Google Cloud risorse vengono rimosse quando elimini un account di servizio utilizzato per i log di controllo di Cloud e raggiungi il limite di 1000 account di servizio per il progetto.
Questo problema potrebbe verificarsi in qualsiasi versione di Google Distributed Cloud.
Correzione e soluzione alternativa
Crea una variabile di ambiente contenente un elenco separato da virgole di tutti gli account di servizio che vuoi conservare. Racchiudi ogni indirizzo email dell'account di servizio tra virgolette singole e l'intero elenco tra virgolette doppie. Puoi utilizzare quanto segue come punto di partenza:
SERVICE_ACCOUNT_EMAILS="'SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com'"
Sostituisci quanto segue:
PROJECT_ID
: il tuo ID progetto.SERVICE_ACCOUNT_NAME
: il nome dell'account di servizio.
L'elenco completato dovrebbe essere simile all'esempio seguente:
"'sa_name1@example-project-12345.iam.gserviceaccount.com','sa_name2@example-project-12345.iam.gserviceaccount.com','sa_name3@example-project-12345.iam.gserviceaccount.com'"
Esegui il seguente comando per rimuovere la funzionalità Log di controllo cloud dal progetto:
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION /features/cloudauditlogging
Sostituisci quanto segue:
PROJECT_NUMBER
: il numero del progetto.FLEET_REGION
: la posizione del gruppo di veicoli per i tuoi cluster. Può trattarsi di una regione specifica, ad esempious-central1
oglobal
. Puoi eseguire il comandogcloud container fleet memberships list
per ottenere la posizione dell'abbonamento.
Questo comando elimina completamente tutti i service account.
Ricrea la funzionalità Audit log di Cloud solo con gli account di servizio che vuoi conservare:
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION/features?feature_id=cloudauditlogging \ -d '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":[$SERVICE_ACCOUNT_EMAILS]}}}'
Passaggi successivi
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.