Questo documento ti aiuta a risolvere i problemi di osservabilità in Google Distributed Cloud. Se riscontri uno di questi problemi, esamina le correzioni e le soluzioni alternative suggerite.
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:
- Requisiti per l'apertura di una richiesta di assistenza.
- Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
- Componenti supportati.
Cloud Audit Logs non vengono raccolti
Cloud Audit Logs sono abilitati per impostazione predefinita, a meno che non sia impostato un flagdisableCloudAuditLogging
nella sezione clusterOperations
della configurazione del cluster.
Se i log di controllo 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 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 di Cloud Audit Logs compromesso.
Le metriche kube-state-metrics
non vengono raccolte
kube-state-metrics
(KSM) viene eseguito come deployment a replica singola nel cluster
e genera metriche su quasi tutte le risorse del cluster. Quando KSM e
gke-metrics-agent
vengono eseguiti sullo stesso nodo, il rischio di interruzione
tra gli agenti delle metriche su tutti i nodi è maggiore.
Le metriche KSM hanno nomi che seguono il pattern 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 mancano le metriche KSM, 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 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
probabilmente anche lo stesso nodo presenta 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
pod
gke-metrics-agent
sullo stesso nodo di KSM.
kube-state-metrics
loop di arresto anomalo
Sintomo
Nessuna metrica di kube-state-metrics
(KSM) è disponibile da
Cloud Monitoring.
Causa
Questo scenario è più probabile che si verifichi in cluster di grandi dimensioni o in cluster con grandi quantità di risorse. KSM viene eseguito come Deployment con una sola replica ed elenca quasi tutte le risorse nel 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 oltre 10.000 pod, KSM potrebbe esaurire la memoria.
Versioni interessate
Questo problema può essere riscontrato in qualsiasi versione di Google Distributed Cloud.
Il limite predefinito di CPU e memoria è stato aumentato nelle ultime versioni di Google Distributed Cloud, quindi questi problemi di risorse dovrebbero essere meno comuni.
Correzione e soluzione alternativa
Per verificare se il problema è dovuto a problemi di memoria insufficiente, segui i seguenti passaggi:
- Utilizza
kubectl describe pod
okubectl get pod -o yaml
e controlla il messaggio di stato di 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 è dovuto a memoria insufficiente, utilizza una delle seguenti soluzioni:
Aumenta la richiesta e il limite di memoria per KSM.
Per Google Distributed Cloud versione 1.16.0 o successive, Google Cloud Observability gestisce KSM. Per aggiornare KSM, consulta la sezione Override delle richieste e dei limiti predefiniti di CPU e memoria per un componente Stackdriver.
Per le versioni precedenti alla 1.16.0, per regolare la CPU e la memoria di KSM utilizza resourceOverride per
kube-state-metrics
nella risorsa personalizzata Stackdriver.
Riduci il numero di metriche di KSM.
Per Google Distributed Cloud 1.13, KSM espone solo un numero inferiore di metriche chiamate Metriche principali per impostazione predefinita. 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 arresto anomalo
Se gke-metrics-agent
riscontra problemi di memoria insufficiente solo sul nodo in cui
esiste kube-state-metrics
, la causa è un numero elevato di metriche kube-state-metrics
. Per risolvere il problema, fare lo scale down di stackdriver-operator
e modifica
KSM per esporre un piccolo insieme di metriche necessarie, come descritto nella sezione precedente.
Ricordati di eseguire lo scale up di stackdriver-operator
dopo l'upgrade del cluster
a Google Distributed Cloud 1.13, in cui KSM espone per impostazione predefinita un numero inferiore di metriche
principali.
gke-metric-agent
. Puoi regolare CPU e memoria per tutti i pod gke-metrics-agent
aggiungendo il campo resourceAttrOverride
alla risorsa personalizzata Stackdriver.
stackdriver-metadata-agent
loop di arresto anomalo
Sintomo
Nessuna etichetta di metadati di sistema è disponibile durante il filtraggio delle metriche in Cloud Monitoring.
Causa
Il caso più comune di loop di arresto anomalo di stackdriver-metadata-agent
è dovuto a
eventi di esaurimento della memoria. Questo evento è simile a kube-state-metrics
. Sebbene
stackdriver-metadata-agent
non elenchi 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 di 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 può essere riscontrato in qualsiasi versione di Google Distributed Cloud.
Il limite predefinito di CPU e memoria è stato aumentato nelle ultime versioni di Google Distributed Cloud, quindi questi problemi di risorse dovrebbero essere meno comuni.
Correzione e soluzione alternativa
Per verificare se il problema è dovuto a problemi di memoria insufficiente, segui i seguenti passaggi:
- Utilizza
kubectl describe pod
okubectl get pod -o yaml
e controlla il messaggio di stato di errore. - Controlla la metrica relativa al consumo e all'utilizzo della memoria per
stackdriver-metadata-agent
e verifica se sta raggiungendo il limite prima di essere riavviato.
resourceAttrOverride
della risorsa personalizzata Stackdriver.
metrics-server
loop di arresto anomalo
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 un'elevata densità di pod.
Questo problema può essere riscontrato 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 metrics-server
pod.
Non tutte le risorse vengono rimosse durante l'eliminazione dell'account di servizio Cloud Audit Logs
Quando elimini un account di servizio utilizzato per Cloud Audit Logs, non tutte le risorse Google Cloud vengono eliminate. Se elimini e ricrei regolarmente gli account di servizio utilizzati per Cloud Audit Logs, alla fine il logging di controllo inizia a non funzionare.
Sintomo
I messaggi di errore di autorizzazione negata vengono visualizzati nel container proxy di Cloud Audit Logs.
Per verificare che l'errore del log di controllo sia causato da questo problema, esegui questo 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 i service account utilizzati con Cloud Audit Logs nel progetto, inclusi quelli eliminati.
Causa e versioni interessate
Non tutte le risorse Google Cloud vengono rimosse quando elimini un account di servizio utilizzato per Cloud Audit Logs e alla fine raggiungi il limite di 1000 account di servizio per il progetto.
Questo problema può essere riscontrato in qualsiasi versione di Google Distributed Cloud.
Correzione e soluzione alternativa
Crea una variabile di ambiente contenente un elenco separato da virgole di tutti i service account che vuoi conservare. Raccolgono ogni 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 questo comando per rimuovere la funzionalità Cloud Audit Logs 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 di progetto.FLEET_REGION
: la posizione dell'appartenenza al parco per i tuoi cluster. Può trattarsi di una regione specifica comeus-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à Cloud Audit Logs solo con i service account 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. Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:
- Requisiti per l'apertura di una richiesta di assistenza.
- Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
- Componenti supportati.