stackdriver-метаданные-агент-кластер-уровень получает OOMKilled - PullRequest
Новая
       64

stackdriver-метаданные-агент-кластер-уровень получает OOMKilled

8 голосов
/ 05 марта 2020

Я обновил кластер GKE с 1.13 до 1.15.9-gke.12. В процессе я переключился с устаревшей регистрации на Stackdriver Kubernetes Engine Monitoring. Теперь у меня проблема с тем, что модуль stackdriver-metadata-agent-cluster-level продолжает перезагружаться, потому что он получает OOMKilled.

Хотя память кажется просто хорошей. enter image description here

Журналы также выглядят отлично (так же, как журналы недавно созданного кластера): 

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 gcm-agent-dev-releaser@ikle14.prod.google.com:/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 ""

Я уже пытался отключить ведение журнала и снова включить его безуспешно. Он все время перезапускается (более или менее каждую минуту).

У кого-нибудь есть такой же опыт?

Ответы [ 2 ]

23 голосов
/ 05 марта 2020

Эта проблема возникает из-за того, что значение LIMIT, установленное для развертывания metadata-agent, слишком мало для ресурсов, поэтому POD уничтожается (OOM kill), поскольку POD требуется больше памяти для правильной работы.

Там это обходной путь для этой проблемы, пока она не будет устранена.

Вы можете перезаписать базовые ресурсы в файле конфигурации metadata-agent с помощью:

kubectl edit cm -n kube-system metadata-agent-config

Установка baseMemory: 50Mi должна быть достаточной, если она не работает, используйте более высокое значение 100Mi или 200Mi.

Так что metadata-agent-config configmap должен выглядеть примерно так: 

apiVersion: v1
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    baseMemory: 50Mi
kind: ConfigMap

Обратите внимание, что вам необходимо перезапустить развертывание, так как карта конфигурации не выбирается автоматически:

kubectl delete deployment -n kube-system stackdriver-metadata-agent-cluster-level

Для получения более подробной информации смотрите addon-resizer Документация .

1 голос
/ 04 апреля 2020

Я собирался открыть заявку в службу поддержки с GCP, но у них есть это уведомление:

Описание Мы столкнулись с проблемой сбоя Fluentd в Google Kubernetes Engine, где главная версия 1.14 или 1.15, когда gVisor включен. Исправление предназначено для выпуска, который должен начаться 17 апреля 2020 года. Мы будем предоставлять больше обновлений по мере приближения даты. Мы предоставим обновление до четверга, 2020-04-09 14:30 США / Pacifi c с текущими подробностями. Мы приносим свои извинения всем, кто пострадал в результате сбоя.

Время начала 2 апреля 2020 года в 10:58:24 GMT-7

Время окончания Действия по воспроизведению аварийных циклов Fluentd в кластерах GKE могут приводят к отсутствию журналов.

Обходной путь Обновите мастера кластера Google Kubernetes Engine до версии 1.16 +.

Затрагиваемые продукты Прочее

...