web-dev-qa-db-fra.com

stackdriver-metadata-agent-cluster-level obtient OOMKilled

J'ai mis à jour un cluster GKE de 1.13 à 1.15.9-gke.12. Au cours du processus, je suis passé de la journalisation héritée à Stackdriver Kubernetes Engine Monitoring. Maintenant, j'ai le problème que le stackdriver-metadata-agent-cluster-level pod continue de redémarrer car il obtient OOMKilled.

La mémoire semble bien cependant. enter image description here

Les journaux semblent également très bien (identiques aux journaux d'un cluster nouvellement créé):

I0305 08:32:33.436613       1 log_spam.go:42] Command line arguments:
I0305 08:32:33.436726       1 log_spam.go:44]  argv[0]: '/k8s_metadata'
I0305 08:32:33.436753       1 log_spam.go:44]  argv[1]: '-logtostderr'
I0305 08:32:33.436779       1 log_spam.go:44]  argv[2]: '-v=1'
I0305 08:32:33.436818       1 log_spam.go:46] Process id 1
I0305 08:32:33.436859       1 log_spam.go:50] Current working directory /
I0305 08:32:33.436901       1 log_spam.go:52] Built on Jun 27 20:15:21 (1561666521)
 at [email protected]:/google/src/files/255462966/depot/branches/gcm_k8s_metadata_release_branch/255450506.1/OVERLAY_READONLY/google3
 as //cloud/monitoring/agents/k8s_metadata:k8s_metadata
 with gc go1.12.5 for linux/AMD64
 from changelist 255462966 with baseline 255450506 in a mint client based on //depot/branches/gcm_k8s_metadata_release_branch/255450506.1/google3
Build label: gcm_k8s_metadata_20190627a_RC00
Build tool: Blaze, release blaze-2019.06.17-2 (mainline @253503028)
Build target: //cloud/monitoring/agents/k8s_metadata:k8s_metadata
I0305 08:32:33.437188       1 trace.go:784] Starting tracingd dapper tracing
I0305 08:32:33.437315       1 trace.go:898] Failed loading config; disabling tracing: open /export/hda3/trace_data/trace_config.proto: no such file or directory
W0305 08:32:33.536093       1 client_config.go:549] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0305 08:32:33.936066       1 main.go:134] Initiating watch for { v1 nodes} resources
I0305 08:32:33.936169       1 main.go:134] Initiating watch for { v1 pods} resources
I0305 08:32:33.936231       1 main.go:134] Initiating watch for {batch v1beta1 cronjobs} resources
I0305 08:32:33.936297       1 main.go:134] Initiating watch for {apps v1 daemonsets} resources
I0305 08:32:33.936361       1 main.go:134] Initiating watch for {extensions v1beta1 daemonsets} resources
I0305 08:32:33.936420       1 main.go:134] Initiating watch for {apps v1 deployments} resources
I0305 08:32:33.936489       1 main.go:134] Initiating watch for {extensions v1beta1 deployments} resources
I0305 08:32:33.936552       1 main.go:134] Initiating watch for { v1 endpoints} resources
I0305 08:32:33.936627       1 main.go:134] Initiating watch for {extensions v1beta1 ingresses} resources
I0305 08:32:33.936698       1 main.go:134] Initiating watch for {batch v1 jobs} resources
I0305 08:32:33.936777       1 main.go:134] Initiating watch for { v1 namespaces} resources
I0305 08:32:33.936841       1 main.go:134] Initiating watch for {apps v1 replicasets} resources
I0305 08:32:33.936897       1 main.go:134] Initiating watch for {extensions v1beta1 replicasets} resources
I0305 08:32:33.936986       1 main.go:134] Initiating watch for { v1 replicationcontrollers} resources
I0305 08:32:33.937067       1 main.go:134] Initiating watch for { v1 services} resources
I0305 08:32:33.937135       1 main.go:134] Initiating watch for {apps v1 statefulsets} resources
I0305 08:32:33.937157       1 main.go:142] All resources are being watched, agent has started successfully
I0305 08:32:33.937168       1 main.go:145] No statusz port provided; not starting a server
I0305 08:32:37.134913       1 binarylog.go:95] Starting disk-based binary logging
I0305 08:32:37.134965       1 binarylog.go:265] rpc: flushed binary log to ""

J'ai déjà essayé de désactiver la journalisation et de la réactiver sans succès. Il redémarre tout le temps (plus ou moins toutes les minutes).

Quelqu'un a-t-il la même expérience?

loggingkubernetesgoogle-kubernetes-enginestackdriver
10
peterfication

J'étais sur le point d'ouvrir un ticket d'assistance avec GCP, mais ils ont cet avis:

Description Nous rencontrons un problème avec Fluentd crashlooping dans Google Kubernetes Engine où la version principale est 1.14 ou 1.15, lorsque gVisor est activé. Le correctif est prévu pour une version qui devrait débuter le 17 avril 2020. Nous fournirons plus de mises à jour à mesure que la date se rapproche. Nous fournirons une mise à jour d'ici le jeudi, 2020-04-09 14:30 États-Unis/Pacifique avec les détails actuels. Nous nous excusons auprès de tous ceux qui sont touchés par la perturbation.

Heure de début 2 avril 2020 à 10:58:24 AM GMT-7

Heure de fin Les étapes pour reproduire les crashloops Fluentd dans les clusters GKE peuvent entraîner des journaux manquants.

Solution de contournement Mettez à niveau les maîtres de cluster Google Kubernetes Engine vers la version 1.16+.

Produits concernés Autre

1
Jean-Martin Archer